История изменений
Исправление sotlef, (текущая версия) :
Какой-то сюр теоретический пишете. Есть приложение, которое написал я. Я знаю, что не использую mmap-инг, количество загруженных библиотек от версии к версии разрабатываемого ПО одинаково и имеют одни и те же версии. Приложение в штатной работе предполагает, что будет запрашивать в куче на сервере в продакшене определенный объем данных. Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее. Т.е. на страницы кода мы вообще не обращаем внимание, так как их относительный размер мизерный - так что shared libraries тут мимо!
Итак: на одной машине у нас запущена много-много дней старая версия ПО, потребляет 16Гб VRAM и 2Гб RSS. На другой машине эта же модель сразу после запуска ПО потребляет 16Гб VRAM и 16Гб RSS. Девопс пишет, почему новая версия потребляет 16Гб RSS, а старая - только 2Гб RSS?
И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти на старой системе со старой версией ПО были слиты в своп (который забит на 14Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.
Когда речь идет об оценке выделения динамической памяти под данные, RSS тут вообще ничего не показывает - даже если процесс ничего не делает, он сейчас будет занимать 16Гб в RSS, а через 5 минут от работы другого процесса будет занимать 2Гб в RSS. Хотя VM дает адекватно понять расход
Исправление sotlef, :
Какой-то сюр теоретический пишете. Есть приложение, которое написал я. Я знаю, что не использую mmap-инг, количество загруженных библиотек от версии к версии разрабатываемого ПО одинаково и имеют одни и те же версии. Приложение в штатной работе предполагает, что будет запрашивать в куче на сервере в продакшене определенный объем данных. Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее. Т.е. на страницы кода мы вообще не обращаем внимание, так как их относительный размер мизерный - так что shared libraries тут мимо!
Итак: на одной машине у нас запущена много-много дней старая версия ПО, потребляет 16Гб VRAM и 2Гб RSS. На другой машине эта же модель сразу после запуска ПО потребляет 16Гб VRAM и 16Гб RSS. Девопс пишет, почему новая версия потребляет 16Гб RSS, а старая - только 2Гб RSS?
И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти в старой версии ПО были слиты в своп (который забит на 14Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.
Когда речь идет об оценке выделения динамической памяти под данные, RSS тут вообще ничего не показывает - даже если процесс ничего не делает, он сейчас будет занимать 16Гб в RSS, а через 5 минут от работы другого процесса будет занимать 2Гб в RSS. Хотя VM дает адекватно понять расход
Исправление sotlef, :
Какой-то сюр теоретический пишете. Есть приложение, которое написал я. Я знаю, что не использую mmap-инг, количество загруженных библиотек от версии к версии разрабатываемого ПО одинаково и имеют одни и те же версии. Приложение в штатной работе предполагает, что будет запрашивать в куче на сервере в продакшене определенный объем данных. Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее. Т.е. на страницы кода мы вообще не обращаем внимание - так что shared libraries тут мимо!
Итак: на одной машине у нас запущена много-много дней старая версия ПО, потребляет 16Гб VRAM и 2Гб RSS. На другой машине эта же модель сразу после запуска ПО потребляет 16Гб VRAM и 16Гб RSS. Девопс пишет, почему новая версия потребляет 16Гб RSS, а старая - только 2Гб RSS?
И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти в старой версии ПО были слиты в своп (который забит на 14Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.
Когда речь идет об оценке выделения динамической памяти под данные, RSS тут вообще ничего не показывает - даже если процесс ничего не делает, он сейчас будет занимать 16Гб в RSS, а через 5 минут от работы другого процесса будет занимать 2Гб в RSS. Хотя VM дает адекватно понять расход
Исходная версия sotlef, :
Какой-то сюр теоретический пишете. Есть приложение, которое написал я. Я знаю, что не использую mmap-инг, количество загруженных библиотек от версии к версии разрабатываемого ПО одинаково и имеют одни и те же версии. Приложение в штатной работе предполагает, что будет запрашивать в куче на сервере в продакшене определенный объем данных. Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее. Т.е. на страницы кода мы вообще не обращаем внимание - так что shared libraries тут мимо!
Итак: на одной машине у нас запущена много-много дней старая версия ПО, потребляет 19Гб VRAM и 2Гб RSS. На другой машине сразу после запуска ПО потребляет 19Гб VRAM и 19Гб RSS. Девопс пишет, почему новая версия потребляет 19Гб RSS, а старая - только 2Гб RSS?
И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти в старой версии ПО были слиты в своп (который забит на 17Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.
Когда речь идет об оценке выделения динамической памяти под данные, RSS тут вообще ничего не показывает - даже если процесс ничего не делает, он сейчас будет занимать 19Гб в RSS, а через 5 минут от работы другого процесса будет занимать 2Гб в RSS. Хотя VM дает адекватно понять расход