Проблема с SWAP?

Question

[serious911]

После переноса нескольких сайтов на новый сервер с Ubuntu 16.04 LTS, большим объемом оперативной памяти (1 Гб) и PHP7 возникла проблема с использованием RAM / swap.

На сервере установлен LEMP-стек и несколько простых сайтов с общей посещаемостью максимум 3-4k уникальных пользователей в сутки. Все приложения (MySQL, Nginx, PHP-FPM, PHP 7 и т.п.) занимают 300-400 МБ (30-40%), но swap используется на 100%.

KiB Mem: 1012720 total, 14172 free, 302536 used, 696012 buff/cache 
KiB Swap: 262140 total, 0 free, 262140 used. 
629520 avail Mem

node:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:            988         292         135          38         561         617
Swap:           255         255           0

График использование памяти из Munin:


Я знаю о параметре vm.swappiness и он равен 10 в моем случае:

node:~$ cat /proc/sys/vm/swappiness 
10

С учетом параметра vm.swappiness SWAP должен использоваться, если RAM занята за 90% или хотя бы не забиваться на 100%. Поскольку на сервере свободно 40-50% оперативной памяти, а SWAP занят на 100%, то vm.swappiness не работает должным образом или что-то неправильно настроено.

Возможно что-то не так с конфигурацией сервера. Вот пример /etc/sysctl.conf:

kernel.panic=10
vm.panic_on_oom=1
vm.swappiness=10
vm.dirty_background_ratio=5
vm.dirty_ratio=10
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.forwarding=0
net.ipv6.conf.all.forwarding=0
net.ipv4.conf.default.forwarding=0
net.ipv6.conf.default.forwarding=0
net.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_source_route=0
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.proxy_arp=0
net.ipv4.ip_local_port_range=1024 65535
net.core.somaxconn=65536
net.core.netdev_max_backlog=30000
fs.file-max=2097152
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_max_tw_buckets=1440000
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_rfc1337=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_mem=50576 64768 98152
net.ipv4.tcp_rmem=4096 524288 11960320
net.core.rmem_max=11960320
net.ipv4.tcp_wmem=4096 524288 11960320
net.core.wmem_max=11960320
net.core.optmem_max=65535
net.ipv4.tcp_max_orphans=65535
net.ipv4.tcp_orphan_retries=0
net.ipv4.tcp_keepalive_time=1800
net.ipv4.tcp_keepalive_intvl=25
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_synack_retries=3
net.ipv4.tcp_max_syn_backlog=3240000

Могу также показать настройки MySQL, PHP-FPM, Nginx и т.п.

Помогите, пожалуйста, разобраться в чем дело.

Спасибо.

Comments

[serious911]

Пользователь: ?

Answer 1

[Михаил Конюхов]

Вот в вашем выводе free видно:

total        used        free      shared  buff/cache   available
Mem:            988         292         135          38         561         617

Что имеются всякие кеши и они отъели место. Скорее всего FS на сервере ext4 и она умеет кешировать и делает это.
Если после
# echo 3 > /proc/sys/vm/drop_caches
У вас освободится памяти раза в 2 больше чем свопа, то можно будет сделать вот так:
# swapoff -a && swapon -a
И если в итоге все прокатило - значит дело ровно в том что у Вас много мелких файлов которые файловая система кеширует.
Оптимизировать в данном случае нужно php (обычно беды из за него), включить и настроить opcache например...

Comments

[serious911]

Файловая система ext4. После запуска echo 3 > /proc/sys/vm/drop_caches освободилась память из buff/cache в несколько раз, но потом сразу начала заполняться.
Before:
total used free shared buff/cache available
Mem: 988 290 63 54 634 600
Swap: 255 230 25

After:
total used free shared buff/cache available
Mem: 988 292 577 54 119 598
Swap: 255 230 25

Сделал также вывод статистики использования swap через smem:
User Count Swap USS PSS RSS
systemd-timesync 1 0.07% 0.02% 0.02% 0.09%
messagebus 1 0.09% 0.07% 0.07% 0.14%
syslog 1 0.18% 0.09% 0.09% 0.17%
postfix 3 0.00% 0.36% 0.44% 0.84%
user 4 0.12% 0.60% 0.88% 1.68%
www-data 4 50.90% 3.94% 4.56% 6.28%
root 20 5.57% 4.28% 4.83% 7.29%
mysql 1 33.92% 16.92% 16.92% 17.01%

По процесcам:
Overall swap used: 465491 kB
========================================
kB pid name
========================================
247884 3647 nginx
177840 3563 mysqld
13104 3591 munin-node
4575 3600 php-fpm7.0
3994 2878 php-fpm7.0
3994 26625 php-fpm7.0
3040 25277 php-fpm7.0
1724 3646 nginx
1488 2068 systemd-udevd
1360 3397 dhclient
1224 3553 sshd
1008 3476 rsyslogd

Большую часть swap занимает nginx, потом mysql, php-fpm.

[serious911]

Opcache вроде включен с стандартными настройками: imgur.com/a/7GNbq

[Михаил Конюхов]

Супер, значит файлы трогает не php. Нужно искать какой процесс постоянно шерстит fs. Это может быть rsync, git и подобное, что управляет тучами файлов. Может быть свертка .tar.gz в бекапы (но маловероятно).
Так же стоит поанализировать вывод lsof и если лесть глубже то strace (но боюсь что объяснить в комментах будет сложновато)

Суть такого поведения fs, когда кеши и буферы загоняют память процессов в swap в большом числе мелких операций (stat или подобные)

[serious911]

Спасибо за ответ. Git не установлен, бекапы только по крону в определенное время (1 раз в сутки), rsync явно не используется (ps ax | grep rsync пусто) и репликации БД тоже нет.

Возможно проблема в том, что некоторые файлы раздает не Nginx, а PHP скрипт следующим образом?

$fd = fopen ($filePath, "r")
while(!feof($fd)) {
$buffer = fread($fd, 2048);
echo $buffer;
}
fclose ($fd);

Раньше с этим проблем не было + нагрузка на сайт небольшая. Проблемы начались после переноса на новый сервер с Ubuntu 16.04 LTS.

[Михаил Конюхов]

serious911: да, это скорее всего так. Эта проблема с большим количеством файлов и их дерганьем связана именно с ext4. По сути - она компенсирует затраты IO в пользу использования RAM

Answer 2

[Владимир]

Что использует свап?
top со свапом- в студию
cat /proc/*/status для процесса, который занимает больше всего свапа

Comments

[serious911]

> Что использует свап?
в этом я и хочу разобраться
> top со свапом- в студию
https://pastebin.com/18HHNXXb

[Владимир]

В топе можно увидеть потребление свапа отдельными процессами.
Что-то вроде f p
Добавится столбик swap

[serious911]

как посмотреть потребление свапа через top так и не нашел, но сделал это через smem:
User Count Swap USS PSS RSS
systemd-timesync 1 0.07% 0.02% 0.02% 0.09%
messagebus 1 0.09% 0.07% 0.07% 0.14%
syslog 1 0.18% 0.09% 0.09% 0.17%
postfix 3 0.00% 0.36% 0.44% 0.84%
user 4 0.12% 0.60% 0.88% 1.68%
www-data 4 50.90% 3.94% 4.56% 6.28%
root 20 5.57% 4.28% 4.83% 7.29%
mysql 1 33.92% 16.92% 16.92% 17.01%

Запустил еще другой скрипт по процесcам:
Overall swap used: 465491 kB
========================================
kB pid name
========================================
247884 3647 nginx
177840 3563 mysqld
13104 3591 munin-node
4575 3600 php-fpm7.0
3994 2878 php-fpm7.0
3994 26625 php-fpm7.0
3040 25277 php-fpm7.0
1724 3646 nginx
1488 2068 systemd-udevd
1360 3397 dhclient
1224 3553 sshd
1008 3476 rsyslogd