Это нормальное явление, когда один процесс pitchfork берёт на себя основную нагрузку — другие процессы задействуются только тогда, когда первый занят. Также нормально, что потребление памяти со временем растёт. Хотя в конечном итоге оно должно выйти на плато, как только всё, включая кэши и ruby-JIT, будет «прогрето».
Вот график из одного из наших производственных кластеров за 7-дневный период. Он отслеживает процесс с максимальным потреблением памяти. Зелёные пунктирные линии указывают на деплой (то есть на перезапуск pitchfork с нуля):
Как видно, потребление памяти действительно растёт после первоначального запуска, но затем стабилизируется чуть ниже отметки в 1,4 ГБ. Этот кластер обслуживает сотни сайтов, поэтому, возможно, он не лучший ориентир с точки зрения конкретных цифр… но, надеюсь, визуализация роста окажется полезной.
Смотреть только на значения RSS для каждого процесса — значит не видеть полной картины. Pitchfork — это «форкающий веб-сервер». Он запускает «образцовый» (mold) процесс, а затем все воркеры создаются из него через механизм копирования при записи (copy-on-write). Поэтому, если RSS показывает 500 МБ для worker[0], примерно 200 МБ из них являются общими для образцового процесса и всех остальных воркеров.
В обозримом будущем мы надеемся включить функцию “reforking” в Pitchfork. Она периодически завершает работу воркеров и повторно форкает их из уже прогретого воркера, чтобы со временем они делили как можно больше памяти. Однако для этого нужно убедиться, что весь наш код совместим с таким подходом 