A
У меня буквально на днях, пуме поплохело, я зашел смотреть метрики, 28 гигов съедено пумой из 32 свободных.
Size: a a a
2020 March 05
MS
У меня тоже сложилось впечатление что процесс пумы “видит” какой-то конечный объем RAM. Это догадки на основе наблюдений за поведением приложения.
MS
Тут еще такой момент: приложение несколько лет жило на более скромном сервере и всего ему хватало. Переехало с ростом пользовательской базы на новую машину и начались проблемы =)
MS
т.е. изменений на уровне кода приложения не было, но поменялось железо и ОС
A
Ну так больше пользователей, больше трафик, больше аллокаций, больше размер кучи, больше проблем с фрагментацией.
MS
Трафик пока не возрос, обкатываем сетап
EM
Вообще мысль про фраг ентацию памяти годная. Я то же предполагаю, что это может быть GC. В какой-то момент пытается почистить и ты получаешь полное понимание пумы, а потом у него действительно куча не равномерно распределенных мест...
EM
Понимание = повисание.
A
Вообще, во времена юникорна, я помню что была такая техника, прибивать воркера, когда он съедал памяти больше определенного лимита.
EM
Да, есть даже gem unicorn-worker-killer 🤗
A
С пумой, может быть тоже можно как-то так поступить, у нее же есть кластер моуд, или как он там называется, когда стартует несколько процессов в контексте которых уже запускаются треды.
A
Но вообще, это все конечно страшные костыли:)
m
а что со свапом?
а то вот это подтормаживание после того как занято 60% памяти выглядит как дефолтный swappiness 60 - и тормозит из-за свапа
(хотя это конечно не решит проблему с утекающей памятью)
/proc/sys/vm/swappinessа то вот это подтормаживание после того как занято 60% памяти выглядит как дефолтный swappiness 60 - и тормозит из-за свапа
(хотя это конечно не решит проблему с утекающей памятью)
A
я своп обычно отключаю:))
?
С пумой, может быть тоже можно как-то так поступить, у нее же есть кластер моуд, или как он там называется, когда стартует несколько процессов в контексте которых уже запускаются треды.
Пума воркер киллер собственно и да это костыльная но нормальная практика в свое время была
A
угу
АФ
Вообще мысль про фраг ентацию памяти годная. Я то же предполагаю, что это может быть GC. В какой-то момент пытается почистить и ты получаешь полное понимание пумы, а потом у него действительно куча не равномерно распределенных мест...
Могу еще посоветовать понаблюдать в мониторнге за спайками по CPU usage в момент, когда начинаются тормоза, поскольку если есть подозрение на GC, то он начинает резко потреблять CPU. Нельзя, конечно, ссылаться по аналогии, но в JVM как раз такая ситуация, что если GC настроен некорректно, и начинают работать stop-the-world паузы, CPU usage резко поднимается
?
MALLOC_ARENA_MAX еще можно поиграться
A
вряд ли виноват именно GС, потому что (в моем случае) производительность стабильно деградирует, нет флюктуаций, всплесков по CPU тоже нет
MS
а что со свапом?
а то вот это подтормаживание после того как занято 60% памяти выглядит как дефолтный swappiness 60 - и тормозит из-за свапа
(хотя это конечно не решит проблему с утекающей памятью)
/proc/sys/vm/swappinessа то вот это подтормаживание после того как занято 60% памяти выглядит как дефолтный swappiness 60 - и тормозит из-за свапа
(хотя это конечно не решит проблему с утекающей памятью)
вот это мне кажется годное направление для проверки