Здравствуйте, korvin_, Вы писали:
_>Может и криворукой, но что делается в Windows в таких случаях?
В Windows заранее резервируется нужное количество памяти. Если зарезервировать не удаётся, то процесс получает отказ. У Винды в принципе нет такой проблемы, как "я пообещала ста процессам по гигабайту рамы, а теперь они все за ней пришли, а на диске места нет".
_>Какая процедура дорогостоящая? Перезапуск к Кубернетесе стоит секунды простоя. Добавление memory request/limits -- считанные минуты. При этом, это может коснуться только одного пода, остальные продолжат работать, если у них нет проблем. Тогда для пользователя никакого простоя не будет.
Хм. Я, наверное, чего-то не понимаю. Вы подразумеваете, что кубер автоматически добавит памяти в контейнер, который упал из-за OOM?
_>Я уж не говорю о том, что ваш graceful shutdown при OOM это никак не решает. Памяти всё равно не хватило. О каких 24/7 вы говорили вообще?
Я повторно намекаю, что "всё равно не хватило" — это не единственный возможный сценарий ООМ. Если у нас там память течёт, то перезапуск контейнера с увеличенной памятью просто сделает чуть дольше ожидание следующего OOM.
_>И долго вы будете гадать на кофейной OOM-гуще, сколько памяти вам надо? А если другой поток/процесс потребует столько же памяти? Если вы хотите буфер 10G, может, вам изначально стоило озаботиться наличием необходимой памяти?
Ну вот я и пытаюсь ей изначально озаботиться — пробую выделить 10G. И меня очень разочарует паника и перезапуск в случае, если 10G нет. Хотелось бы чего-то более конструктивного.
_>Нет, в любой нормальной системе типов Optional Optional -- это Optional Optional, также как List of List of T -- это List of List of T, а не List of T. А если они у вас автоматически схлопываются, у вас дерьмовая система типов.
Tastes differ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.