Во время обновления наибольшая нагрузка на память (ОЗУ + swap) приходится на процесс ‘ember’. Мне кажется, что с каждым обновлением он становится всё больше, и уже приближается к тому моменту, когда не сможет запускаться на компьютерах с минимально рекомендуемой конфигурацией.
Стоит разобраться в этом до того, как возникнет сбой. (Надеюсь, что по соображениям стоимости ответом не станет увеличение минимально рекомендуемых требований. Увеличение swap-пространства помогло бы, если позволяет место на диске. В принципе, можно временно перейти на более дорогой экземпляр с большим объёмом ОЗУ.)
Я запускаю два форума небольшого размера на небольших экземплярах — оба, насколько я знаю, соответствуют минимальным рекомендуемым требованиям. В обоих случаях ОЗУ + swap = 3 ГБ. В одном случае это экземпляр Digital Ocean с 1 ГБ ОЗУ и 2 ГБ swap, в другом — экземпляр Hetzner с 2 ГБ ОЗУ и 1 ГБ swap.
Вот три снимка процесса ember на машине DO, полученные с помощью команды ps auxc:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 87.7 65.1 32930460 657936 ? Rl 16:57 2:23 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 84.9 60.7 43572204 612668 ? Rl 16:57 2:57 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 81.2 55.2 43405220 557128 ? Rl 16:57 3:40 ember
Очевидно, что размер процесса в 43 ГБ не полностью присутствует в виртуальной памяти, так как у нас доступно только 3 ГБ. Использование 65% размера ОЗУ для RSS впечатляет, но само по себе не является проблемой. Количество свободной памяти и свободного swap показывает, что машина находится на грани состояния нехватки памяти (OOM), что, скорее всего, приведёт к завершению работы какого-либо процесса и некорректному завершению обновления.
Вот вывод команды free в виде моментального снимка:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Чтобы попытаться зафиксировать ситуацию в момент, максимально близкий к сбою, я использовал команду vmstat 5:
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 1392140 61200 11632 76432 41 32 117 93 0 1 2 1 97 0 0
1 1 1467220 63416 324 67284 8786 20499 13178 20567 2539 8924 77 13 0 10 0
0 2 1593340 57916 1096 53832 24262 46868 29986 46889 5377 18534 44 22 0 34 0
4 0 1155632 120680 2772 86280 39111 35424 54768 37824 6987 25174 38 27 0 35 0
3 0 1102988 74096 2852 85276 11261 246 12610 271 1879 6365 86 6 0 8 0
Вы заметите множество переключений контекста (cs), большую активность диска (bi, bo) и высокую активность swap (si, so), но самое важное — это использование swap до 1,6 ГБ при свободной памяти, упавшей до 60 МБ, и использовании буферов всего 54 МБ. Это означает, что из доступных 3 ГБ виртуальной памяти занято около 2,6 ГБ. Это 87% от ёмкости. (Ситуация может быть даже хуже, так как мы делаем выборку только каждые 5 секунд.)
Обратите внимание, что ситуация вызывала беспокойство (при использовании около 2 ГБ, то есть не так близко к критическому состоянию, как сегодня) ещё в августе, когда я обновлялся:
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 700404 62740 1956 48748 35 29 108 92 3 8 2 1 96 0 1
1 0 741000 65996 1880 44360 3708 11190 3982 11191 643 1437 92 4 0 3 1
1 0 834836 70452 1480 53856 528 18969 4274 18974 532 1575 93 6 0 1 0
4 1 1010144 82192 4644 44400 30065 38803 35455 39946 4432 19267 28 26 0 39 7
1 0 644116 307764 1644 55348 24406 21154 27724 21945 2551 8672 52 22 0 21 6
