AP
да, оверкоммит чисто по лимитам
Size: a a a
2020 September 21
AP
диск nvme в рейд 0, да и приложуха относительно медленная, там какие-то жалкие мегабайты пишутся
AP
даже не десятки
VZ
ребят, а посоветуйте чего глянуть, не совсем про докер, а про контейнеры в общем. есть у меня сервак, на котором гоняются контейнеры с батч-задачами. головному контейнеру выделена виртуально вся память сервака. понадобилось добить туда еще полезной нагрузки вторым контейнером с другим сервачком, пошел по пути оверкоммита памяти, так как фактическое использование даже в пике нагрузки ну может 30% от объема. и где-то в этом интервале батчи стали падать с невнятными ошибками типа process unstable, OOM и т.п. могла ли такая фигня каким-то образом возникнуть из-за оверкоммита?
ну если почитать про OOM в рамках psql
VZ
GG
короче, деталей мало
AP
нет, я в принципе понимаю почему OOM может быть, батч задача внутри еще со своими нестед-лимитам запускается, что-то типа 4 гига на задачу
AP
просто раньше хватало, а вдруг перестало
VZ
еще есть earlyoom - но я чет да же не помню зачем оно
AP
при том что разрабы в голос что ничего не меняли
VZ
нет, я в принципе понимаю почему OOM может быть, батч задача внутри еще со своими нестед-лимитам запускается, что-то типа 4 гига на задачу
ну стоит посмотреть настройки ядра +) и oom killer в том числе
AP
максимум что крутил вот
AP
vm.swappiness = 1
vm.max_map_count = 262144
vm.overcommit_memory = 1
AP
надо будет своп вообще выпилить
GG
не поможет
GG
секрет есть
GG
линух без свопа работает хуевей, чем со свопом
N
линух без свопа работает хуевей, чем со свопом
а я думал тока я так думаю :D
N
а то любую конфу открываешь и первое вырубайте свап нахер.
AP
я б не выпиливал, но кубер не хочет свопа