Comments 13
самый критический путь всей библиотеки. Она вызывается для всех событий «запись лога в файл»Т.е. простое отключение логирования помогло? Значит ошибка была не столько в ядре linux, сколько в сторонняя библиотека логирования под названием glog?
нет. Ошибка не библиотеке glog. А просто неудачное стечение обстоятельств, когда возникала внезапная конкуренция за ресурсы ядра.
Условный контр-пример. Представьте себе, что Вы — пользователь IaaS/PaaS. И Вам нужно развернуть отказоустойчивый кластер hadoop. Вы нарезаете виртуалки, ставите ОСь, устанавливаете софт hadoop. И выясняется, что кластер-то нифига не отказоустойчивый. В чем дело? Ведь и IaaS по паспорту обеспечивает отказоустойчивость (живая миграция ВМ в случае отказа ноды и пр.) и вроде бы hadoop тоже сам по себе отказоустойчивый (он спецом разрабатывался, чтобы быть запущенным на дешевом хламе, которое все время отказывает). А оказывается, что нужно еще выставить виртуалкам правильно antiaffinity, чтобы гипервизор их расталкивал по ВМкам в правильном порядке. При этом не IaaS — плохая и не Хадуп — плохой. А «любая абстракция рано или поздно течет» и приходится разбираться со всем стеком снизу вверх (или сверху вниз).
Вот такая же история с ядром. Никто заранее не объяснил границы применимости той или иной технологии и получили протекшую абстракцию.
Условный контр-пример. Представьте себе, что Вы — пользователь IaaS/PaaS. И Вам нужно развернуть отказоустойчивый кластер hadoop. Вы нарезаете виртуалки, ставите ОСь, устанавливаете софт hadoop. И выясняется, что кластер-то нифига не отказоустойчивый. В чем дело? Ведь и IaaS по паспорту обеспечивает отказоустойчивость (живая миграция ВМ в случае отказа ноды и пр.) и вроде бы hadoop тоже сам по себе отказоустойчивый (он спецом разрабатывался, чтобы быть запущенным на дешевом хламе, которое все время отказывает). А оказывается, что нужно еще выставить виртуалкам правильно antiaffinity, чтобы гипервизор их расталкивал по ВМкам в правильном порядке. При этом не IaaS — плохая и не Хадуп — плохой. А «любая абстракция рано или поздно течет» и приходится разбираться со всем стеком снизу вверх (или сверху вниз).
Вот такая же история с ядром. Никто заранее не объяснил границы применимости той или иной технологии и получили протекшую абстракцию.
UFO just landed and posted this here
Тут упор на то, что люди начали использовать контейнеры для CI/CD. У нас в инфраструктуре для этого используются динамически создаваемые виртуалки в openstack, и в подобной ситуации такой проблемы бы не было. Контейнеры мы тоже используем, но только в пределах одной задачи (например, быстрый прогон тестов бэкапов) — между задачами ядро ОС не шарится (а если и шарится, то без привлечения контейнеров, просто на уровне процессов).
Люди попытались использовать контейнеры, но пришлось допиливать, т.к. изоляция не полная.
Люди попытались использовать контейнеры, но пришлось допиливать, т.к. изоляция не полная.
amarao ну, Вы говорите так, будто VM не конкурируют за ресурсы — CPU time там, IOPS'ы всякие. Причем с ними тоже часть проблем решается. Можно зашейпить IOPS'ы те же. Но! Это, во-первых, не спасет от context switching и вымывания L2/L3 кэшей на процессорах (камни обычно оверселлятся на ура). А, во-вторых, если настроена live миграция виртуалок, то там запросто тоже быстродействие может просесть на ура в случае, если ВМки пошли мигрировать между нодами.
Я просто оставлю это здесь.
12 факторов — не панацея. В частности, например, некоторые джава-программисты пишут такие программы, которые в лог кидают СЛИШКОМ много всего. Понятно, что всегда можно отфильтровать… но такое себе. А на ходу (без перезапусука сервиса) переключить уровень логирования не всегда возможно.
Еще момент — когда берешь уже готовый контейнер с тем же airflow. Там фактически внутри получается несколько служб/скриптов и из лога получается мешанина, причем которую разбить нельзя. Вот и приходится костылись логирование в файл или во внешний сервис типа эластика. Естественно, уходим от этого, но не все сразу.
тоже спорно. А если все-таки нужен multiline? Выход — паковать сообщение в json или типа того?
Еще момент — когда берешь уже готовый контейнер с тем же airflow. Там фактически внутри получается несколько служб/скриптов и из лога получается мешанина, причем которую разбить нельзя. Вот и приходится костылись логирование в файл или во внешний сервис типа эластика. Естественно, уходим от этого, но не все сразу.
Журнал в своём сыром виде обычно представлен текстовым форматом с одним событием на строчку
тоже спорно. А если все-таки нужен multiline? Выход — паковать сообщение в json или типа того?
Лучше в Tree: https://m.habr.com/post/248147/
Буквально на прошлой неделе я сумел устроить OOM на сервере с 8 контейнерами. Каждый контейнер потреблял несколько мегабайт, на сервере было 8Гб (виртуалка). Догадайтесь, сколько kmalloc памяти съедал каждый контейнер? Нет, оно не аккаунтилось cgroup'ами, оно просто прибивало что попало по OOM, в т.ч. за пределами контейнеров.
И я только тронул волшебный вопрос «kernel memory» на всякие объекты.
Контейнеры — коммуналка. Если кто-то решит часто ходить в туалет, остальные будут ждать.
И я только тронул волшебный вопрос «kernel memory» на всякие объекты.
Контейнеры — коммуналка. Если кто-то решит часто ходить в туалет, остальные будут ждать.
Можно тест кейс описать полностью? Хочу повторить.
Я не уверен, что это не CVE. Хочу дотестировать в имитации продакшен-среды. Но суть одна и так же — начинаете есть ресурсы ядра из контейнеров, и ядро память ест, а userspace в контейнере — нет.
fd, ip-адреса, mount'ы, namespace'ы, интерфейсы, pid'ы, сокеты, pipe'ы, etc.
fd, ip-адреса, mount'ы, namespace'ы, интерфейсы, pid'ы, сокеты, pipe'ы, etc.
Т.е. это вопрос accounting'а ресурсов, которые контейнеры тратят в ядре (и не учитываются в статистике)?
Ага. Причём, иногда может быть, что очень сложно понять, куда относить ресурсы. В принципе, мы можем понять, что в конкретную cgroup'у, но иногда не понятно, через что. Например, вложенные namespace'ы — как их аккаунтить по памяти? Это память процесса? Нет. А память всегда на процесы выделяется. А в tmpfs? А в /sys? А память conntrack'а?
Sign up to leave a comment.
Еще одна причина, почему тормозят Docker контейнеры