Из-за чего повышенное потребление памяти на VPS?

Question

[rivalsm]

Добрый день, сложилась некоторая проблема на используемом VPS, может кто-то подскажет наиболее верное решение.
Есть скрипт загрузки пользователями изображений (предполагается до 10Мб), загрузка происходит
через AJAX фоном по 1 файлу. До этого момента все работает хорошо и красиво. После аплода делается кроп изображений, создание миниатюр и наложение вотермарка с использованием
расширения Imagick и график потребления памяти в панели хостинга растет ступенеобразно, было даже два падения VPS с ошибками в логе типа: Cannot allocate memory: fork: Unable to fork new process и PHP Fatal error: Out of memory (allocated 262144) (tried to allocate 261900 bytes) in Unknown on line 0. В этот момент тарифный план включал в себя 512 Mb (1024 Mb burst). Сервак падал при достижении гигабайта. Также периодически операция аплода для немаленьких файлов 5-7 Мб заканчивалась POST-ошибкой в консоль браузера.
По совету хостера был произведен апгрейд на 1024 Mb (2048 Mb burst) и файлы стали аплодиться и обрабатываться без ошибок, но память по-прежнему растет после каждой сессии загрузки файлов (5-7 штук) и не снижается впоследствии. Складывается ощущение, что рано или поздно она достигнет предела и все рухнет. Это при том условии, что не было еще релиза проекта и файлы аплодит 1 человек.
Собственно вопрос: в чем может быть проблема?
В использовании imagick или конфигах? Есть вариант поковырять конфиги, но не очень понятно пока что конкретно. Думаю о maxrequestsperprocess, maxprocesses и установке ulimit -s 1024. Или искать альтернативу imagick?
Заранее благодарен всем откликнувшимся.

Answer 1

[Влад Животнев]

У вас openvz с некорректно настроенными лимитами на память. Просто переехайте на любую Xen/KVM виртуалку - digitalocean, flops, например.
Найти openvz-хостера с корректными лимитами на память посложнее будет.

Comments

[Пума Тайланд]

Чем они не корректные, человек купил 512мб с бёрстом до гига, гиг выжрал и система не дает ему памяти. Все так о должно работать. И почему вы считаете купив гиг оперативы на том де дигиталокеане он будет выдавать больше гига?

[Влад Животнев]

@opium
Человек купил 512мб хуй пойми чего, а не физической RAM. По другому я здесь выразиться не могу.
Linux работает с памятью очень правильно и красиво - с одной стороны стремиться занять всю доступную память (хотя бы даже page-кэшом или как dirty-pages). С другой стороны, ситуация, когда форку приложения нельзя выделить память означает следующее:
- у системы нечего переложить в swap (или его вообще нет).
- у системы нечего выгрузить (вся память ушла в kmem или в активные процессы в состоянии R).
- у системы нет свободного мегабайта памяти на то, чтобы сделать форк (а именно столько физической памяти нужно для форка примерно любого процесса, из-за особенностей его реализации). Оно, конечно, могло бы потом прибиться OOM-ом или сразу в swap уйти, но форкнуться ему бы ядро дало.

Из чего можно сделать 2 вывода:
1) хостер некорректно считает память (например, считает т.н. виртуальную память, которой для форка php нужно действительно мегабайт 200). При том, что в случае нормальной работы ядра (на физической машине, внутри KVM, в openvz с vswap и корректными лимитами) можно сделать allocate на несколько петабайт памяти (или сколько там позволяет 64-битная архитектура) и вам за это ничего не будет, кроме места, которое в памяти займёт указание на allocate. Грубо говоря, ядро хостера вместо подсчета памяти для виртуалки просто складывает одно из значений занятой памяти (RSS или VIRT, если совсем не повезло) для всех её процессов. При том, что и RSS, и VIRT не имеют никакого отношения к реальному потреблению "железной" памяти. И даже математика с применением SHR не поможет.
2) у хостера стоит низкий лимит на какую-то из крутилок в openvz. Наиболее популярные - kmemsize ("пиздец апачу") и tcpsockets ("пиздец всем приложения, работающим с сетью").

И да. Всё это сделано на основе фразы "сервак падал" и 5 лет ковыряния с разными системами виртуализации - OOM разнесет всю машину в клочья, но она будет пинговаться и по ssh отвечать, если памяти не будет. Но падать она никуда не соберется.

[Пума Тайланд]

Человек пишет что он смотрит мониторинг загрузки памяти и крашится у него процесс только когда заполняется гиг памяти.

[Влад Животнев]

@opium было бы странным, если бы график хостера показывал незанятую память, а у человека было бы "ааа, у меня памяти нет!". Хостеру пришлось бы чинить такое поведение. Повторюсь - проблема в некорректной работе с памятью. Система думает, что у неё ещё есть память (физическая), но по факту при попытке аллоцировать память ядро хостера говорит гостевой системе "иди в жопу, ты своё скушала". При том, что гостевая система всё равно не осознаёт, что памяти нет и продолжает глупые попытки аллоцировать ещё. И, само собой, не высвобождает память под новые процессы, так как считает, что у неё ещё дохрена памяти.

Работа с памятью в KVM/Xen выглядит по-другому. Системе говорят "на тебе одну плашку физической памяти на гигабайт и разбирайся сама". В этом случае гостевая система способна корректно работать с памятью, освобождать её вовремя, аллоцировать те самые петабайты. Но, если придти и шаловливыми ручками ограничить процесс виртуалки на 512 мегабайт в dom0-системе (а виртуалка продолжит думать, что у неё гигабайт, как написано в конфиге гипервизора) - то будут те же cannot fork, когда машина упрется в реально занятые 512 памяти.

Простой вам пример для сравнения. К Вам приходят и говорят - держи миллион долларов и трать на что хочешь. Покупаешь квартиру, подписываешь договор. И тут вдруг врываются дяди с автоматами и укладывают тебя спать. Оказывается, что на жильё из них ты можешь потратить только 5% (пресловутый kmemsize, критичный при форке). Вот примерно тоже самое в данной ситуации и происходит.

Answer 2

[rivalsm]

Спасибо за ответ, в данный момент все лежит на IntoVPS, который был выбран после некоторого количества прочтенных положительных отзывов. Выбирал между им и Hetzner'ом. Проще уехать, чем разобраться и договориться с хостером и его настройками?

Comments

[Sergey]

Скорее всего из-за одного клиента хостер не станет менять настройки на серверах.

[Пума Тайланд]

Лечите приложение, а не впс. Если вы потребили лимит памяти который купили и система вам больше не выдает то все верно. К какому хостеру не переезжай везде так будет, никто не продает гиг оперативы и позволяет использовать десять гигов.

[rivalsm]

Я купил уже два, и за несколько закачек файлов приложение съело и два гига. Разница в ест и не ест лишь в 3-4-х строках с использованием Imagick. Вот они:
$photo = new Imagick($_SERVER['DOCUMENT_ROOT'].'/aphotos/'.CURRENT_CITY_ABBR.'/'.$year_dir.'/'.$orig_path.'/'.$img_name);
$geo=$photo->getImageGeometry();
...
$photo->cropThumbnailImage(900, 675);
$photo->writeImage($_SERVER['DOCUMENT_ROOT'].'/aphotos/'.CURRENT_CITY_ABBR.'/'.$year_dir.'/'.$day_dir.'/fullsize/'.$img_name);
$photo->destroy();

Answer 3

[rivalsm]

Небольшой отчет по тестам на Digitalocean. Взял 512MB и залил скрипты. Произвожу аналогичные действия — картинка аплодится, после чего скрипт делает кроп и создание двух миниатюр с использованием расширения Imagick. Гляжу память известным мне способом через free -m.
Состояние памяти до работы скрипта:
total used free shared buffers cached
Mem: 495 218 276 0 2 127
-/+ buffers/cache: 89 406
Swap: 0 0 0

После чего закидываю файл на загрузку и иду снова в шелл и начинаю усердно задрачивать free -m.
В момент загрузки файла особо ничего не меняется, после загрузки, очевидно начинают работать мои кропы и рисайзы, память резко подскакивает до пикового значения в 486 Мб.

used free shared buffers cached
495 490 5 0 2 263
224 271
0 0 0

И также резко опускается вниз. В данный момент спустя некоторое время работы скрипта уровень памяти вот такой.

total used free shared buffers cached
495 103 392 0 0 18
84 411
0 0 0

У Digitalocean нет графиков для памяти, поэтому похвастаться красивой картинкой не могу, но ситуация с памятью мне видится иной, чем на IntoVPS.

Comments

[Sergey]

@rivalsm
aptitude/yum install munin
и будут тебе красивые картинки

[rivalsm]

спасибо) monitorix поставил уже

Answer 4

[Пума Тайланд]

Сделайте профайлинг приложения по потреблению памяти и увидите кто или что её скушало.

Answer 5

[rivalsm]

Несколькими сессиями загрузки файлов скушал и 2 Гб в течение часа вчера вечером.
На графике видно. Потребление памяти до сих пор на этом уровне.

Answer 6

[Влад Животнев]

@rivalsm
Прочитайте мой ответ к Повышенное потребление памяти на VPS
Ваше приложение может некорректно работать с памятью (не высвобождать её или ещё как-то некорректно себя вести), но Linux давно уже способен самостоятельно справляться с подобными ситуациями. В крайнем случае - всегда есть OOM, который сделает kill -9 части процессов и память снова появится. Cannot allocate memory означает то, что ваша виртуалка на самом деле не имеет указанного количества _физической_ памяти.
Сначала переезжайте на kvm, потом продолжайте копаться с приложением.

Ситуация "вся память занята" - абсолютно нормальна, и это не повод к "Cannot allocate memory" при форке.

Comments

[rivalsm]

@inkvizitor68sl, спасибо за разъяснения. Уже поставил lamp и залил контент на digitalocean.com по вашему совету, буду тестировать. У них вроде бы нет графика для использования памяти, пока смотрю в командной строке free -m. Других способов отмониторить память не знаю, в силу не сильной грамотности в администрировании.

[rivalsm]

И, кстати, саппорт IntoVPS ответил, что у них не наблюдается никаких проблем и посоветовал почитать мануалы по оптимизации апача. И что, в общем-то, сложившаяся проблема их не касается они отвечают с полной уверенностью.

[Пума Тайланд]

Ну тесты в студию

[Sergey]

@rivalsm установи munin или monitorix.

Answer 7

[rivalsm]

Результаты работы с памятью из мониторикса. В месте, где виден продолжительный подъем производились последовательные аплоды в течение некоторого промежутка времени.
В общем и целом из free видно, что уровень свободной памяти за вычетом бкферов и кэшей
остается на примерно одинаковом уровне в 390-400 мегабайт, из чего можно предположить,
что проблема была у хостера IntoVPS. По всей видимости, Влад @inkvizitor68sl оказался прав, за что ему огромное спасибо, а то я уже начал рвать волосы на голове и собирался идти к гадалке за выяснением причин возникновения проблемы.

Comments

[Влад Животнев]

Не за что.
Включите, кстати, swap там небольшой, на 128 мегабайт, например - это сильно облегчит машине логику работы с памятью. Не добавит 128 мегабайт памяти, но даст ядру некоторую "свободу действий". mydebianblog.blogspot.ru/2010/05/swap-swap-linux.html как-то так.
Сильно много тоже не нужно, чтобы система в swap не уходила. А вот возможность переложить пару мегабайт на диск в случае ахтунга - может когда-нибудь выручить =)

[rivalsm]

Хорошо, постараюсь осилить) Если получится, сделаю в IntoVPS манибэк и возьму на digitalocean 2 гига памяти чтоб быть уверенным. Кстати, это нормально, что сейчас при работе скрипта память кушается почти целиком, хоть и на очень краткий промежуток времени? Будет ли так при любом объеме памяти?

Answer 8

[ValdikSS]

У вас, похоже, OpenVZ.
А сделайте-ка ulimit -s 1024 и перезапустите все демоны.

Comments

[rivalsm]

Спасибо, вроде уже разобрался. Пришлось уехать на KVM.