D
postgres внутри виртуалки жрет 12 ГБ всего. выше привел вывод free
Size: a a a
2019 December 23
D
т.е. не в ней проблема. память куда-то утекает и не возвращается
TF
красавчик значит он, но у него указан потолочное значение по озу?
TF
ну блять, потуши постгрес, обнови ядро, ребутни виртуалку
D
красавчик значит он, но у него указан потолочное значение по озу?
да. в любом случае
TF
может у тебя ядро сливает
D
может у тебя ядро сливает
на 3-х других аналогичных такой траблы нет
TF
она ж не может просто так взять и уехать, а потом оом приходит
TF
на 3-х других аналогичных такой траблы нет
а у меня на ноуте винда, а ваш линукс говно
D
и проблема появилась недавно
D
работало примерно 4 месяца безперебойно
TF
тогда тебе не в квм
TF
а в постгрес
D
тогда тебе не в квм
спасибо, но я лучше подожду тех, кто читает вопросы
D
суть вопроса: с гипервизора видно, что процесс kvm-виртуалки ест 157 гб. Внутри самой виртуалки, с буферами можно насчитать только 52 гб. Вопрос: где могут быть оставшиеся 100 гб озу
D
и почему приходит оом, если на ноде нет оверсела по памяти, но она, тем не менее заканчивается. и убивается всегда одна и та же виртуалка
DB
kvm может течь? их баг трекер не смотрел?
D
kvm может течь? их баг трекер не смотрел?
еще нет, посмотрю этот вариант, конечно. но он кажется очень маловероятным, т.к. все ставилось пакетно на одинаковые узлы и с тех пор не обновлялось
SV
и почему приходит оом, если на ноде нет оверсела по памяти, но она, тем не менее заканчивается. и убивается всегда одна и та же виртуалка
Убивается, скорее всего, самый толстый процесс, а OOM может приходить из-за фрагментации памяти и невозможности найти блок с order > 0; тут стоит посмотреть сообщения ядра про этот OOM
D
Убивается, скорее всего, самый толстый процесс, а OOM может приходить из-за фрагментации памяти и невозможности найти блок с order > 0; тут стоит посмотреть сообщения ядра про этот OOM
спасибо, проверю этот вариант. а есть идеи, почему показания внутри виртуалки и с гипервизора по памяти так разнятся?