Чтобы потом к начальнику департамента облачной инфраструктуры пришли тимлиды проектов и начали сраться на тему того, кто же сожрал ресурсы при переподписке?
Лично мне это не надо. Я не считаю необходимым срать себе под дверью и класть сверху коврик.
Я считаю, что надо проектировать систему так, чтобы подобных ситуаций не было.
ram^2 это анахронизм времен, когда на проде жили на unstripped ядре, чтобы постмортем сделать, на 1tb ram baremetal машине достаточно ram/64 swap (причем без партиции/lv, достаточно mkswap /swap) + vm.swapiness=10 и мониторингом free/cached/buffered/paged
>ядро свопирует прежде всего давно не использованные страницы памяти.
Да, безусловно. Поэтому ядро свопит страницы памяти с .DATA для очереди на accept, и в итоге сервис в ядре открывает http-соединение, а GET/POST проходит чрез 10 секунд. При этом в приложении всё висит в вызове accept. Хотя epoll сказал, что этот дескриптор активный.
Знаете, я не готов обсуждать, что это говно лучше того, что процесс умрёт по ООМ.
потому что переподписывает ресурсы, если задать лимиты, то swap не будет создан, вся дискуссия выше это "у меня есть точные лимиты на все" vs "мы не уверены в их точности"
чем больше swappiness, тем более заранее свопируются давно не использованные страницы памяти, а значит тем больше памяти свободно на случай, когда внезапно понадобится много памяти
Переподписка нужна только для мошенников типа клаудмаус. Если у вас своё облако, то перепаодписка == преступлению. Виртуализация нужна не затем, чтобы в 32 гб всунуть 64 машины по 4 Гб. Она нужна затем, чтобы отказустойчивость обеспечивать и простоту миграции и изменения конфигурации