Использование команды `top` показывает, что процессы PHP FPM используют больше памяти, чем доступно

Question

я прочелэтот ответ о пониманииtop, а также man top, но я думаю, что у меня все еще возникают проблемы с преобразованием представленных данных topв фактическую информацию.

Я вошел в экземпляр Amazon EC2, который является частью группы с балансировкой нагрузки. Он работает под управлением PHP FPM, и я отфильтровал, topчтобы показать только php-fpmпроцессы:

top - 11:27:43 up 18:59,  2 users,  load average: 0.59, 0.79, 0.74
Tasks: 171 total,   1 running, 125 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  9.1 sy,  0.0 ni, 90.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   1935.6 total,    177.7 free,    692.3 used,   1065.7 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1052.0 avail Mem

  PID USER            PR    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                   
 1566 root            20  356.2m  30.5m  23.5m S        1.6   0:02.14 php-fpm: master process (/etc/php-fpm.conf)
 2188 webapp          20  442.2m  51.3m  31.8m S        2.7   2:18.47 php-fpm: pool www
 2189 webapp          20  442.1m  50.8m  30.4m S        2.6   2:19.21 php-fpm: pool www
 2190 webapp          20  444.2m  52.6m  30.4m S        2.7   2:20.14 php-fpm: pool www
 2191 webapp          20  442.1m  51.1m  31.3m S        2.6   2:22.69 php-fpm: pool www
 2192 webapp          20  442.2m  50.8m  31.6m S        2.6   2:19.64 php-fpm: pool www
 2193 webapp          20  436.3m  46.5m  32.0m S        2.4   2:17.29 php-fpm: pool www
 2194 webapp          20  452.2m  60.6m  30.4m S        3.1   2:19.82 php-fpm: pool www
 2195 webapp          20  438.1m  48.0m  31.6m S        2.5   2:17.78 php-fpm: pool www
 2197 webapp          20  442.2m  50.9m  30.6m S        2.6   2:18.28 php-fpm: pool www
12626 webapp          20  443.6m  50.4m  28.4m S        2.6   0:37.02 php-fpm: pool www
12627 webapp          20  443.5m  50.3m  28.6m S        2.6   0:35.68 php-fpm: pool www
12628 webapp          20  438.0m  45.1m  29.1m S        2.3   0:36.28 php-fpm: pool www
12629 webapp          20  443.9m  51.4m  29.3m S        2.7   0:35.26 php-fpm: pool www
12630 webapp          20  441.6m  48.9m  29.5m S        2.5   0:34.90 php-fpm: pool www
12631 webapp          20  443.6m  50.5m  28.7m S        2.6   0:34.93 php-fpm: pool www
12632 webapp          20  436.0m  43.2m  29.1m S        2.2   0:36.01 php-fpm: pool www
12635 webapp          20  441.6m  48.1m  28.3m S        2.5   0:34.56 php-fpm: pool www
12636 webapp          20  446.1m  55.0m  30.8m S        2.8   0:37.10 php-fpm: pool www
12637 webapp          20  441.9m  48.8m  29.0m S        2.5   0:35.16 php-fpm: pool www
12639 webapp          20  443.6m  50.3m  28.5m S        2.6   0:34.23 php-fpm: pool www
12640 webapp          20  438.0m  44.7m  28.9m S        2.3   0:36.33 php-fpm: pool www
12641 webapp          20  442.8m  49.5m  28.4m S        2.6   0:35.51 php-fpm: pool www
12642 webapp          20  443.8m  50.8m  29.1m S        2.6   0:36.22 php-fpm: pool www
12643 webapp          20  438.0m  44.2m  29.2m S        2.3   0:33.49 php-fpm: pool www
12644 webapp          20  440.0m  47.4m  29.3m S        2.5   0:36.44 php-fpm: pool www
12645 webapp          20  441.6m  48.7m  29.0m S        2.5   0:34.38 php-fpm: pool www
12646 webapp          20  441.6m  48.5m  28.8m S        2.5   0:34.53 php-fpm: pool www
12647 webapp          20  437.6m  44.5m  28.5m S        2.3   0:34.73 php-fpm: pool www
12648 webapp          20  437.7m  44.4m  28.6m S        2.3   0:33.64 php-fpm: pool www
12649 webapp          20  440.0m  46.9m  29.0m S        2.4   0:35.81 php-fpm: pool www
12651 webapp          20  444.1m  51.1m  29.0m S        2.6   0:34.77 php-fpm: pool www
12652 webapp          20  439.8m  47.0m  29.1m S        2.4   0:35.02 php-fpm: pool www
12657 webapp          20  443.9m  51.7m  29.9m S        2.7   0:35.35 php-fpm: pool www
12658 webapp          20  438.0m  45.5m  29.3m S        2.3   0:34.81 php-fpm: pool www
12667 webapp          20  441.9m  49.6m  29.6m S        2.6   0:34.21 php-fpm: pool www

Вот чего я не понимаю:

1. Что VIRTотображает столбец?на самом деле? Я понимаю, что это виртуальная память, но в строке 2 сводки по памяти я вижу, что там есть 1052.0 avail Mem, в то время как процессы в VIRTстолбце в сумме дают гораздо больше.
2. Как определяется 1052.0доступная память подкачки/виртуальная память, если ее 0.0общая память есть?
3. Как там 692.3используется только память, когда сумма столбца %MEM? 88.6%Разве она не должна быть не менее 1935 * 0.886 = 1714? Похоже, я приближаюсь к этому числу, если добавляю к 1065.7 buff/cacheтем 692.3, но в чем причина этого?
4. Почему главный процесс спит (как указано в Sстолбце)? По крайней мере не долженэтобежать?

Моя главная забота

Настройка memory_limitв PHP ini установлена ​​на 256M. Это должно означать, что каждый дочерний процесс, порожденный FPM, может использовать до этого объема памяти, верно? Если это так и у меня 35 дочерних процессов (как в настоящее время показано top), то теоретически они могут использовать (или пытаться использовать) до 35 * 256 = 8960Mпамяти. Это намного больше, чем 1935Mу меня есть в общей сложности.

Также общая сумма памяти в RESстолбце составляет 1749.6. Другими словами, используемая память составляет 1749/1935 = 90.38%. Но это когда все процессы находятся в состоянии сна! Если происходит всплеск трафика и потребление памяти внезапно увеличивается, это звучит катастрофически.

Я думаю о том, чтобы уменьшить разрешенную память с 256Mдо 128Mи уменьшить pm.max_childrenс дефолтного 50до, скажем, 12. Таким образом, общее возможное потребление памяти PHP FPM будет 12 * 128 = 1536M, что будет в пределах фактической доступной памяти в системе. Имеет ли это смысл?

Answer 1

Несколько вещей, которые следует учесть. Во-первых, вы видите 692.3 used, но вам также нужно учесть 1065.7 buff/cache. Если вы просуммируете RESстолбец, он должен совпасть с итогом usedи buff/cache. Это связано с тем, что buff/cacheпредставляет данные, используемые для этих процессов, и хотя они не доступны немедленно, они должны быть доступны в ближайшее время.

Что касается memory_limitи pm.max_children: Вы можете запустить наиболее ресурсоемкий скрипт в своем приложении и измерить его использование памяти с помощьюmemory_get_peak_usage().

Возьмите это значение, добавьте немного емкости для роста вашего набора данных, и теперь у вас есть реалистичный максимальный объем памяти, необходимый для скрипта. С этой цифрой вы можете оценить, сколько pm.max_childrenможет обработать ваш сервер. Уменьшите эту цифру, чтобы учесть другие процессы на вашем сервере.

Теперь вы также можете задать более точное значение memory_limit, но имейте в виду, что нарушение этого значения приведет к остановке вашего скрипта. Я обнаружил, что это часто работает лучше всего в качестве контроля, чтобы не дать неконтролируемым скриптам убить ваш сервис, и установил его выше, чем у моих самых требовательных к памяти скриптов, чтобы обеспечить будущие, более сложные задания.

Вам также следует проверить переменные fpm (pm.*) и скорректировать их соответствующим образом.