virtio решает проблему обработки системных вызовов, но не решает проблему файлового формата

а какой версии кему был?

qed же в новом qcow2 есть ну они там странно сделали, на новых версиях гипервизоров больше фичь на qcow2 примерно как zfs on linux

по логике да, но по сути qed все равно быстрее чем новый qcow2

хотя я бы не рискнул его в проде использовать

а на seepdog вы смотрели?

спашотики + raw и кластер с отказоустойчивостью

кто-то недавно мне говорил про петерянные 60теров на гавкающей овце

а какой версии кему был?

# /usr/bin/kvm --version QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2003-2008 Fabrice Bellard

ну я бы вам привел цифры, но как уже сказал не могу. можете погуглить, даже на чистых ssd производительность у qcow2 почти никакая

а какой шедулер использовался?

ну не древний

кто-то недавно мне говорил про петерянные 60теров на гавкающей овце

тут же версия важна, ее релизной негде нет в бинарных пакетах

а он не издох еще?

спашотики + raw и кластер с отказоустойчивостью

и при потере локального диска виснут использующие его виртуалки

а он не издох еще?

релизнулся прод реади пару месяцев назад

кто-то недавно мне говорил про петерянные 60теров на гавкающей овце

гавкающая офца – это gluster?

шипдог

а гластер - это глистфс

мерзость - это мезоссфера

и тп

а гластер - это глистфс

питоноболь)

как скучно я живу

и при потере локального диска виснут использующие его виртуалки

ну это логично, оно же на локальном диске по сути живет там нужно рейды на нодах во избежании

а на seepdog вы смотрели?

интересно, надо будет попробовать

пока в планах тока люстра стояла в экзотической конфигурации с failover'ом :)

пока в планах тока люстра стояла в экзотической конфигурации с failover'ом :)

люстра это страшная штука, даже в документации написано что ты не хочешь ее использовать)

интересно, надо будет попробовать

напишите если что то интересное будет рассказать)

ну люстра - это мир суперкомпьютеров со своими приколами

я уже попробовал, люстра классная, только отказоустйочивости никакой, нужно все самому допиливать

ну люстра - это мир суперкомпьютеров со своими приколами

beegfs кстати оттудаже

ну она наследие одного проекта околоакадемиеского из европы

и при потере локального диска виснут использующие его виртуалки

оно тоже не умеет high availability?

проблема люстры - это еще то что она только центоси работает, благо хоть патченного ядра больше не требует

напишите если что то интересное будет рассказать)

обязательно)

Ало, гараж. Это чат кубера а не хостинга

Валите в https://t.me/pro_hosting

Как определить сколько памяти и цпу ставить контейнеру?

Где-то читал что нужно давать нагрузку и смотреть при какой величине перестает справляться

Для меня это сейчас слишком трудоемкий способ (нет столько времени)

а как определить сколько памяти и цпу кушает приложение?

Как вообще определить производительность приложения?

Либо имперически через агрузочное тестирование

Либо пальцем в небо

Мне кажется есть какие-то эвристики

Какие-то приложения требуют больше памяти, какие-то больше цпу

O_o

а откуда это известно?

Какие-то приложения требуют больше памяти, какие-то больше цпу

Л - Логика

ну можно тыкать пальцем в небо, постепенно увеличивая, вместе с нагрузкой =))

Скажу по секрету, все данные по потребляемым ресурсам либо имперические, либо наугад

если рестартуется по OOM - значит памяти не хватает

Я понял

если рестартуется по OOM - значит памяти не хватает

Если OOM вышел на тропу войны, пиши пропало...

Докер и кубер не убивают процес по ООМ, они его убивают по достижению лимита памяти

по превышению cgroup разве не тот же механизм работает?

Нет

Тогда представим что есть кластер из Н разнородных контейнеров, на которых как-то расставлены лимиты (пальцем в небо)

Ну как бы убивается так же через term 1 и term 9

Как улучшить лимиты в этом случае?

Не будешь же каждый контейнер в отдельности гонять

только OOM это конретно вычислятор использования памяти роцессорами, и функция ядра, врубающаяся при не хватки виртуальной памяти

Не будешь же каждый контейнер в отдельности гонять

А есть другой способ?

Ну как бы убивается так же через term 1 и term 9

чет по dmesg это выглядело как oom

Я думаю нужно найти ботлнек

Его под крутить и тд

чет по dmesg это выглядело как oom

OOM = out of memory... так что выглядитеь это может да и должно одинакого. Главное принцип использования В Случая OOM я слышу OOM Killer ядра, который работает иначе. В кубере идёт cgroup limit (которая на убийство может вызывать теже функции ООП же)

cgroups это механим ядра

cgroups это механим ядра

Ага, миханизм лимитов....Которому ни кто не запрещает использовать те же функции на убийство процесса, что раньше были написаны и используются в OOM Killer, который достаёт топор при отсутсвии виртуальой памяти...

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

ммм ?

Докер и кубер не убивают процес по ООМ, они его убивают по достижению лимита памяти

вообще кубер не убивает процесс по оом. это делает ядро

оки контейнера вообще нет. Есть Namespace приложения и cgroup лимиты

В норм системе идёт вычесления веса и правильности использования памяти, этим можно управлять, заставляя ООМ не уюивать критически важны, но текущие процессы

В случае контейнера, при достижени лимита памяти он будет перезапущен, и ни как иначе

Норм система, система без виртуализации и контейнеризации

Ало, гараж. Это чат кубера а не хостинга

А ваш кубер в качестве стореджа использует эфир? Причем тут чатик про хостинг если сторедж обсуждался?

кубер убивает только в одной ситуации - когда видет что ресурсов вообще не хватает больше на машине, используя свой механизм eviction manager, если были настроены пороги для eviction https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#hard-eviction-thresholds который нацелен на то чтобы избежать исчерпания ресурсов глобально и запуска oom killer. покрайней мере я знаю только этот вариант убийства подов самовольно со стороны кубелета.

В случае контейнера, при достижени лимита памяти он будет перезапущен, и ни как иначе

да, но это будет выглядеть не как "кубер увидел что память перешагнула порог и перезапустил" это будет ядро, убившее процесс и кубелет, увидевший что контейнер упал и значит нужно какое то действие совершить

кубер убивает только в одной ситуации - когда видет что ресурсов вообще не хватает больше на машине, используя свой механизм eviction manager, если были настроены пороги для eviction https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#hard-eviction-thresholds который нацелен на то чтобы избежать исчерпания ресурсов глобально и запуска oom killer. покрайней мере я знаю только этот вариант убийства подов самовольно со стороны кубелета.

Короче. Спора нет, ты про фому я про ерёму. Ты про то что контейнеры убивают через вызов oom_killer, я про то что oom_killer вызывается не как мера, по высвобождению вирт памяти хоста.

При Работе OOM_killer В рамках хоста, учитывается множе ство факторов

я прост надеялся еще может чего нового узнать смогу, вдруг есть еще кейсы по убийству подов

А именно

Считаем RSS процесса Добавляем RSS всех дочерних процессов Если процесс долго живёт, то значение уменьшается Если у процесса niceness больше 0, то значение увеличивается. Если есть флаги CAP_SYS_ADMIN или CAP_SYS_RAWIO, результат уменьшается Смотрится знаечение /proc/<pid>/oom_adj, которое может задавать пользователь, чтобы повышаться сопротивляемость OOM Killer'у. Вроде как это уже deprecated и нужно использовать oomscore_adj.

У бивается лидер

В случае с cgroup убивается по достижению лимита и без вариантов

Кстати делается это именно для того , что бы системный OOM не вышел на тропу войны, и не грохнул slice и docker....со всеми контейнерами на борту, без возможности их рестарта

Это кстати к вопросу об "хорошем тоне, писать лимиты для подов"

да, в этом плане очень круто задать requests = limits в resources, получится что твой контейнер имеет guaranteed qos и -998 oom_score_adj =)

да, в этом плане очень круто задать requests = limits в resources, получится что твой контейнер имеет guaranteed qos и -998 oom_score_adj =)

а вот этого я не знал-)

https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior

там же minimum reclaim можно настроить для eviction manager

в общем очень хороший механизм, с одной стороны

еще кстати много тут про capacity \ reserved\ allocatable https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/node-allocatable.md

У меня несколько ip на сервере. Могу я заставить под слушать 0.0.0.0 (hostNetwork: true)?

не получается?