https://edu.slurm.io/courses/slurm-base-school/unit/136
;) кстати. Вадик, передай коллеге
держать собственный форк kubespray, в первых минутах вебинара фактически объясняя что kubespray УМЕР =)
и никому кроме автора вебинара не интересен, это ОЧЕНЬ СМЕЛЫЙ и честный поступок! респект

virtual - это сколько процесс попросил и линукс сказал "да,да, конечно, вот!". с реальностью не соотносится.
rss - это сколько процесс реально сейчас занимает в памяти (минус то, что ушло в своп)
shared - память, которую используют несколько процессов (файлы tmpfs, файлы, открытые через mmap или старый добры shmget())
как в clickhouse идет определение code и dataandstack и к чему это относится - без понятия.

virtual - это сколько процесс попросил и линукс сказал "да,да, конечно, вот!". с реальностью не соотносится.
rss - это сколько процесс реально сейчас занимает в памяти (минус то, что ушло в своп)
shared - память, которую используют несколько процессов (файлы tmpfs, файлы, открытые через mmap или старый добры shmget())
как в clickhouse идет определение code и dataandstack и к чему это относится - без понятия.

Не помню, чтобы это было описано гдето в виде статьи, на которую все ссылаются
Но информация о virt/rss/shr/etc есть много где :)
Вот это выглядит неплохо: https://elinux.org/Runtime_Memory_Measurement

https://edu.slurm.io/courses/slurm-base-school/unit/136
;) кстати. Вадик, передай коллеге
держать собственный форк kubespray, в первых минутах вебинара фактически объясняя что kubespray УМЕР =)
и никому кроме автора вебинара не интересен, это ОЧЕНЬ СМЕЛЫЙ и честный поступок! респект

А в чем проблема с Кубспреем?
https://github.com/kubernetes-sigs/kubespray/graphs/contributors
Коммитов и контрибуторов примерно столько, сколько и было несколько лет назад. Другие решения выросли сильно быстрее, имхо, но о смерти кубспрея это совсем не говорит

народ, а есть какой то нормальный УРЛ

который бы рассказывал чем RSS от Shared, Virtual, Code, DataAndStack отличается?

кроме
http://man7.org/linux/man-pages/man5/proc.5.html

на kernel.org что-то одна вода гуглится ...

мне надо как то нормальное описение вот этого найти
https://github.com/ClickHouse/ClickHouse/blob/f98ffdbc4ca7ff32350c4b2fd5f672d70168cb2d/src/Interpreters/AsynchronousMetrics.cpp#L144

ну вот опять развалилось в сопли
load average 20

короче походу это clickhouse начинает где то отжирает память
и вот почему ООМ начинает убивать kube-scheduler и controller manager а не clickhouse-server это загадка, никаких приоритетов и limits/requests не выставлял конечно...

спасибо докер живой остался, помогло
docker stop $(docker ps | grep clickhouse-server | cut -d " " -f 1)

вам спасибо за помощь, навели на мысли, Status: running в describe был
до reason я не добрался...

я вот только не понимаю, почему оно load average 20 сделало

писали в интернетах, что если программа оптимальна ине использует своп, но своп нужен для housekeeping , а без swap уборку не отложить .
не, не писали или я не так прочитал?