Кто-нибудь ещё это видит? Форум по размеру и трафику довольно скромный. У нас запущено четыре рабочих процесса pitchfork, и похоже, что один из них обрабатывает подавляющее большинство входящих запросов и потребляет больше памяти, чем остальные. Сейчас активно используется swap, и если намеренно перезапустить pitchfork, это заметно снижается. Поэтому я делаю вывод, что в процессах pitchfork сейчас много «холодных» страниц, которые выгружены в swap.
Это после 20 дней работы на машине с 4 ГБ ОЗУ и 4 ГБ swap.
Было бы плохо, если бы swap закончился. Также было бы плохо, если бы весь этот swap начал возвращаться в память, что, возможно, произойдёт, когда pitchfork в конце концов выполнит сборку мусора (garbage collect).
Кто-нибудь ещё наблюдает что-то подобное? Пожалуйста, поделитесь конфигурацией вашего оборудования!
Вывод vmstat показывает, что сейчас нет никакого давления на память — отсутствует активность пейджинга. Меня беспокоит не то, что моя установка сейчас работает плохо, а то, что существует опасность.
Мне было бы интересно увидеть статистику с более загруженного форума. Похоже, что накопленное количество запросов имеет значение, а мой форум отнюдь не является очень загруженным.
Да, различия в использовании RSS относительно невелики, но диапазон от 300 МБ до 500 МБ — это довольно большая разница в процентном отношении.
Ещё более показательным является использование swap. Прежде чем хвататься за вилы, я вижу:
# free
total used free shared buff/cache available
Mem: 3904968 1888140 77308 679004 1939520 1147220
Swap: 4194288 1226344 2967944
а после:
# free
total used free shared buff/cache available
Mem: 3904968 1486412 1422380 640744 996176 1587908
Swap: 4194288 309892 3884396
Похоже, что благодаря пересборке было освобождено 1300 МБ (разница между used и swap).
Я не уверен, что видел такое большое использование swap при работе с unicorn: отсюда и название темы.
Как я уже сказал, мне было бы интересно увидеть цифры с других инстансов.
Это нормальное явление, когда один процесс pitchfork берёт на себя основную нагрузку — другие процессы задействуются только тогда, когда первый занят. Также нормально, что потребление памяти со временем растёт. Хотя в конечном итоге оно должно выйти на плато, как только всё, включая кэши и ruby-JIT, будет «прогрето».
Вот график из одного из наших производственных кластеров за 7-дневный период. Он отслеживает процесс с максимальным потреблением памяти. Зелёные пунктирные линии указывают на деплой (то есть на перезапуск pitchfork с нуля):
Как видно, потребление памяти действительно растёт после первоначального запуска, но затем стабилизируется чуть ниже отметки в 1,4 ГБ. Этот кластер обслуживает сотни сайтов, поэтому, возможно, он не лучший ориентир с точки зрения конкретных цифр… но, надеюсь, визуализация роста окажется полезной.
Смотреть только на значения RSS для каждого процесса — значит не видеть полной картины. Pitchfork — это «форкающий веб-сервер». Он запускает «образцовый» (mold) процесс, а затем все воркеры создаются из него через механизм копирования при записи (copy-on-write). Поэтому, если RSS показывает 500 МБ для worker[0], примерно 200 МБ из них являются общими для образцового процесса и всех остальных воркеров.
В обозримом будущем мы надеемся включить функцию “reforking” в Pitchfork. Она периодически завершает работу воркеров и повторно форкает их из уже прогретого воркера, чтобы со временем они делили как можно больше памяти. Однако для этого нужно убедиться, что весь наш код совместим с таким подходом
Полезная визуализация, спасибо. Я бы не сказал, что всё стабилизировалось, но темп роста не такой высокий, как раньше.
Периодический рефорк звучит как отличная идея для этого — если получится, пожалуйста, отметьте здесь, когда это будет реализовано.
Можете ли вы что-нибудь сказать о зелёных линиях? Меня интересует, когда (если вообще) питфорки выполняют сборку мусора, что это вызывает и каков эффект во время её выполнения.
Зелёные линии — это моменты, когда мы разворачиваем обновления. По сути, это: ./launcher rebuild app.
Ruby (и JS, который мы запускаем внутри процессов Ruby через MiniRacer/v8) постоянно выполняет сборку мусора во время работы и в ответ на сигналы от операционной системы. Поэтому я не думаю, что от какого-либо ручного вмешательства можно получить значительную пользу.
Спасибо. Мне было бы интересно посмотреть, как всё сложится в долгосрочной перспективе — на сервере, который обновляется относительно часто, это будет не так очевидно. В моём случае прошло 20 дней, а потом я решил использовать pitchfork для перезапуска, что дало мне кое-какую информацию, но также обнулило отсчёт.
