Андрей, а вы, как ярый противник свопа, слышали что-нибудь о disk trashing в момент нехватки памяти в Linux?

+1

Слышал, и что?

Если потребовалось много памяти, а ее нет, система встанет колом. Своп - способ предотвратить становлением колом в критичный момент. Чем больше резерва, тем лучше. Начать можно с zram, а у дискового свопа делать приоритет меньше. Но он должен быть.
К сожалению, текущие реалии memory management в ядре именно таковы.

Это очевидная чепуха.

Я могу ещё раз повторить без мата. Использование свопа в 2021-м году - самая плохая практика из возможных.

Падение по OOM предпочтительнее, чем непредсказуемые тормоза непредсказуемых сервисов. Процессы-камикадзе лучше, чем процессы-слоупоки.

Потому что упавший сервис будет переподнят, а сервис, который намертво залочен в ядре на ожидании страницы ни жив и ни мёртв.

Резерв вида "мы вам дадим скорость ответа в 1000000 раз медленнее чем средняя" — это не резерв, а отказ от обслуживания. Просто вместо аварии и падения процесса мы заметаем под ковёр все проблемы и веруем в то, что раз подобные всплески не видит мониторинг, то и ОК.

Но это нихрена не ОК. Это - второй Авито, который постоянно последние 3 года срёт 500-тыми. А на Хабре там победные реляции, что все микросервисы работают.

Если бы все было настолько красиво, как вы думаете, а oom killer бы агрессивно убивал. Но нет, ОС будет до последнего пытаться выжить, по акту часто вставая колом или почти колом, освобождая память по-немногу, выгружая какую-то библиотеку и загружая ее обратно. Есть патч le9p, он повышает агрессивность oom killer, но полностью проблему не решает.
Своп должен быть, я считаю, но использоваться по возможности не должен.

Либо хотя бы userspace oomd-подобный демон

У меня процесс почтового сервера просто умирает по превышению лимита, и на этом всё.

У меня нет турдукена из десятка сервисов на одной виртуалке. У меня есть виртуалка под конкретный сервис и контракт о поставке ресурсов с департаментом виртуальной инфраструктуры.

Авито работает в k8s, а k8s в свою очередь в pre-run check смотрит, не включен ли swap :)

Если у вас сумма верхних границ лимитов всех работающих процессов меньше или равно объему свободной памяти, то да. можно говорить о ненужности свопа, но не забывать уточнять о наличии таких продуманных лимитов. А обобщать - это не по-инженерному )

Если что-то  падает по ООМ, я принимаю меры. Если оно бы лезло в своп, я бы эти меры принять не мог. Хотя бы потому, что я не лажу по виртуалкам; мне больше делать нечего, как заходить на сервера.

не всегда такое возможно, например, идет видеоконференция, а кусок bigbluebutton потек в памяти, да, можно завершить конференцию, люди перезайдут и их отправит на другой сервер, но лучше пусть что-то посвопиться, а конференция выживет

Таки я прекрасно понимаю, что по-инженерному это прицепить своп, начитавшись чепухи про его необходимость.
Кстати, не подскажете, а сколько свопа надо на сервер с 1 Тб памяти? Вроде, рекомендуют 2 объёма оперативки. 2Тб хватит? Говорят, при kernel panic в свопе можно найти копию всего мира...

Конференция выживет - очнется через N минут? И очнется ли?
Тут же и говорят, fail fast приоритетнее и прогнозируемее. Своп допустим в каких-то нанокейсах повел бы себя чуть лучше - но требует слишком много внимания и зависит от слишком большой стохастики.

Да, и что будет со скоростью ответа ноды, которая сидит в свопе на 10%? Ну, всего 100 Гб диска прочитать, какие мелочи.

Или надо меньше свопа? Ну вот если терабайт уже скушали, насколько нас спасёт 32 Гб свопа? Минут 10 есть у нас? Или 10 минут мы будем ждать пока sshd вернётся с диска в богоспасаемый RAM? Я не очень в курсе, так как не смотрел его исходники, делает ли он  mlock?

зависит от того, что работает на сервере и как оно жрет память. Если там работает нечто, умудряется выжрать терабайт целиком , то, наверное, лучше подумать, как переделать это что-то, а если там крутятся виртуалки, сумма выделенной памяти под которыес запасом меньше терабайта, то я бы сделал несколько ГБ свопа и посмотрел бы, не будет ли ядро слишком часто и много туда свопировать, когда как свободная память есть, если не будет, то оставил бы.

mlock не панацея, очередь процессора перегружена disk trashing

ядро свопирует прежде всего давно не использованные страницы памяти. Прибивать конференцию в рандомный момент - это перебор. Лучше реагировать по факту превышения пороговых значений /proc/loadavg и/или /proc/pressure/*