а какой версии кему был?
# /usr/bin/kvm --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2003-2008 Fabrice Bellard
𝚔𝚟𝚊𝚙𝚜
Vlad
Sergey
ну не древний
Anonymous
кто-то недавно мне говорил про петерянные 60теров на гавкающей овце
тут же версия важна, ее релизной негде нет в бинарных пакетах
Sergey
а он не издох еще?
Vlad
спашотики + raw и кластер с отказоустойчивостью
и при потере локального диска виснут использующие его виртуалки
Logan
кто-то недавно мне говорил про петерянные 60теров на гавкающей овце
гавкающая офца – это gluster?
Sergey
шипдог
Sergey
а гластер - это глистфс
Sergey
мерзость - это мезоссфера
Sergey
и тп
Logan
как скучно я живу
Anonymous
и при потере локального диска виснут использующие его виртуалки
ну это логично, оно же на локальном диске по сути живет
там нужно рейды на нодах во избежании
𝚔𝚟𝚊𝚙𝚜
пока в планах тока люстра стояла в экзотической конфигурации с failover'ом :)
Anonymous
пока в планах тока люстра стояла в экзотической конфигурации с failover'ом :)
люстра это страшная штука, даже в документации написано что ты не хочешь ее использовать)
Sergey
ну люстра - это мир суперкомпьютеров со своими приколами
𝚔𝚟𝚊𝚙𝚜
я уже попробовал, люстра классная, только отказоустйочивости никакой, нужно все самому допиливать
Sergey
ну она наследие одного проекта околоакадемиеского из европы
𝚔𝚟𝚊𝚙𝚜
и при потере локального диска виснут использующие его виртуалки
оно тоже не умеет high availability?
𝚔𝚟𝚊𝚙𝚜
проблема люстры - это еще то что она только центоси работает, благо хоть патченного ядра больше не требует
Oleg
Ало, гараж. Это чат кубера а не хостинга
Oleg
Валите в https://t.me/pro_hosting
Anonymous
Как определить сколько памяти и цпу ставить контейнеру?
Anonymous
Где-то читал что нужно давать нагрузку и смотреть при какой величине перестает справляться
Anonymous
Для меня это сейчас слишком трудоемкий способ (нет столько времени)
Maksim
а как определить сколько памяти и цпу кушает приложение?
Maksim
Как вообще определить производительность приложения?
Maksim
Либо имперически через агрузочное тестирование
Maksim
Либо пальцем в небо
Anonymous
Мне кажется есть какие-то эвристики
Anonymous
Какие-то приложения требуют больше памяти, какие-то больше цпу
Pavel
O_o
Maksim
а откуда это известно?
Anton
ну можно тыкать пальцем в небо, постепенно увеличивая, вместе с нагрузкой =))
Maksim
Скажу по секрету, все данные по потребляемым ресурсам либо имперические, либо наугад
Anton
если рестартуется по OOM - значит памяти не хватает
Anonymous
Я понял
Maksim
если рестартуется по OOM - значит памяти не хватает
Если OOM вышел на тропу войны, пиши пропало...
Maksim
Докер и кубер не убивают процес по ООМ, они его убивают по достижению лимита памяти
Anton
по превышению cgroup разве не тот же механизм работает?
Maksim
Нет
Anonymous
Тогда представим что есть кластер из Н разнородных контейнеров, на которых как-то расставлены лимиты (пальцем в небо)
Maksim
Ну как бы убивается так же через term 1 и term 9
Anonymous
Как улучшить лимиты в этом случае?
Anonymous
Не будешь же каждый контейнер в отдельности гонять
Maksim
только OOM это конретно вычислятор использования памяти роцессорами, и функция ядра, врубающаяся при не хватки виртуальной памяти
Anonymous
Я думаю нужно найти ботлнек
Anonymous
Его под крутить и тд
Maksim
чет по dmesg это выглядело как oom
OOM = out of memory... так что выглядитеь это может да и должно одинакого. Главное принцип использования
В Случая OOM я слышу OOM Killer ядра, который работает иначе. В кубере идёт cgroup limit (которая на убийство может вызывать теже функции ООП же)
Anton
cgroups это механим ядра
Maksim
cgroups это механим ядра
Ага, миханизм лимитов....Которому ни кто не запрещает использовать те же функции на убийство процесса, что раньше были написаны и используются в OOM Killer, который достаёт топор при отсутсвии виртуальой памяти...
Anton
memory.oom_control
contains a flag (0 or 1) that enables or disables the Out of Memory killer for a cgroup. If enabled (0), tasks that attempt to consume more memory than they are allowed are immediately killed by the OOM killer. The OOM killer is enabled by default in every cgroup using the memory subsystem; to disable it, write 1 to the memory.oom_control file:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-memory
Maksim
ммм ?
Anton
Докер и кубер не убивают процес по ООМ, они его убивают по достижению лимита памяти
вообще кубер не убивает процесс по оом. это делает ядро
Maksim
оки контейнера вообще нет. Есть Namespace приложения и cgroup лимиты
Maksim
В норм системе идёт вычесления веса и правильности использования памяти, этим можно управлять, заставляя ООМ не уюивать критически важны, но текущие процессы
Maksim
В случае контейнера, при достижени лимита памяти он будет перезапущен, и ни как иначе
Maksim
Норм система, система без виртуализации и контейнеризации
Anonymous
Ало, гараж. Это чат кубера а не хостинга
А ваш кубер в качестве стореджа использует эфир?
Причем тут чатик про хостинг если сторедж обсуждался?
Anton
кубер убивает только в одной ситуации - когда видет что ресурсов вообще не хватает больше на машине, используя свой механизм eviction manager, если были настроены пороги для eviction
https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#hard-eviction-thresholds
который нацелен на то чтобы избежать исчерпания ресурсов глобально и запуска oom killer.
покрайней мере я знаю только этот вариант убийства подов самовольно со стороны кубелета.
Anton
В случае контейнера, при достижени лимита памяти он будет перезапущен, и ни как иначе
да, но это будет выглядеть не как "кубер увидел что память перешагнула порог и перезапустил"
это будет ядро, убившее процесс и кубелет, увидевший что контейнер упал и значит нужно какое то действие совершить
Maksim
кубер убивает только в одной ситуации - когда видет что ресурсов вообще не хватает больше на машине, используя свой механизм eviction manager, если были настроены пороги для eviction
https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#hard-eviction-thresholds
который нацелен на то чтобы избежать исчерпания ресурсов глобально и запуска oom killer.
покрайней мере я знаю только этот вариант убийства подов самовольно со стороны кубелета.
Короче. Спора нет, ты про фому я про ерёму. Ты про то что контейнеры убивают через вызов oom_killer, я про то что oom_killer вызывается не как мера, по высвобождению вирт памяти хоста.
Maksim
При Работе OOM_killer В рамках хоста, учитывается множе ство факторов
Anton
я прост надеялся еще может чего нового узнать смогу, вдруг есть еще кейсы по убийству подов
Maksim
А именно
Maksim
Считаем RSS процесса
Добавляем RSS всех дочерних процессов
Если процесс долго живёт, то значение уменьшается
Если у процесса niceness больше 0, то значение увеличивается.
Если есть флаги CAP_SYS_ADMIN или CAP_SYS_RAWIO, результат уменьшается
Смотрится знаечение /proc/<pid>/oom_adj, которое может задавать пользователь, чтобы повышаться сопротивляемость OOM Killer'у. Вроде как это уже deprecated и нужно использовать oomscore_adj.
Maksim
У бивается лидер
Maksim
В случае с cgroup убивается по достижению лимита и без вариантов
Maksim
Кстати делается это именно для того , что бы системный OOM не вышел на тропу войны, и не грохнул slice и docker....со всеми контейнерами на борту, без возможности их рестарта
Maksim
Это кстати к вопросу об "хорошем тоне, писать лимиты для подов"
Anton
да, в этом плане очень круто задать requests = limits в resources, получится что твой контейнер имеет guaranteed qos и -998 oom_score_adj =)