Linux

Объём ресурсов, потребляемый контейнером, учитывается на уровне cgroup, к которой он относится. Контейнер состоит из одного или более процессов, а процесс — из одного или более тредов. Абстракцию можно углубить, разбивая тред на «зелёные потоки», в зависимости от рантайма это могут быть горутины (Golang), корутины (Kotlin/Python), виртуальные треды (Java) и другие. Но о «зелёных» потоках Linux не знает, для него единицей планирования является тред (в терминах ядра — task_struct). Именно он планируется, выполняется и вытесняется другими тредами для выполнения на CPU....

Разработчики провели нагрузочные тесты и выявили значительные задержки при записи данных в Kafka, что приводило к накоплению лага. Я подключился к анализу причин низкой производительности. Сильно упрощенный флоу: приложение пишет в Kafka (кластер на виртуальных машинах); Kafka работает в режиме acks=all и не поспевает за потоком событий; на приложении копится очередь на запись. Прежде чем детально разбираться с Kafka, я бегло проверил сетевые ресурсы и состояние машин. Аномалий выявлено не было....

Или как траблшутить контейнеры когда нечем.

Протестировал работу TCP Congestion Control в Linux в различных по качеству окружениях, поделюсь результатами.

Изучая возможности контрольных групп в linux наткнулся на параметр memory.soft_limit_in_bytes: When the system detects memory contention or low memory, control groups are pushed back to their soft limits. If the soft limit of each control group is very high, they are pushed back as much as possible to make sure that one control group does not starve the others of memory. Аналог в cgroup2 - memory.low Звучит интересно! Сделаем несколько тестов для понимания как это все работает....