#varfs #ceph #fs

We implemented VarFS based on Ceph and for random writes it achieves significantly better throughput and latency than Ceph by 50 times.

#varfs #ceph #fs

Китайские товарищи описали FS которая работает поверх ceph и дает хороший прирост производительности на рандомной записи.
Иплементаций я не нашел, к сожалению.

#la #psi #linux #perfomance #monitoring

Знали ли вы что LA давным-давно уже не модно?
Теперь модно Pressure Stall Information (PSI), метрики, которые доступны начиная с 4.20 ядра.
Показывают отдельно страдания процессов по CPU/MEM/IO.
Если у вас cgroupsv2, то покажут еще данную информацию по контейнерам.

Очень понятно что это за метрики рассказано тут.
Эти метрики уже есть в новых версиях atop (строка PSI).

Если есть кратко, в каждом из файлов (/proc/pressure/[cpu|memory|io]) есть две строчки:
- some - сколько процентов времени один или больше процессов испытывали проблемы с ресурсом.
- full - сколько процентов времени все процессы в системе испытывали проблемы с ресурсом.

(Для cpu строчка full оставлена только для совместимости)

Ну то есть если у вас в файле io в строчке full написано 50 на avg300, то это означает что 150 секунд все процессы в системе ждали IO.
Есть еще параметр total: растущий счетчик в микросекундах.

Более длинно можно почитать еще и тут

#gpu #monitoring

Dynolog: Open source system observability

GPU вычисления в последнее время как вы все знаете очень горячая тема.
Наверное в каждой крупной компании сейчас стоят или скоро будут стоять вычислительные кластера забитые A100/H100 картами.
И встает тема как мониторить их производительность на стыке CPU-GPU/GPU-GPU/IO.

Да уже есть инструменты которые делают это по отдельности, но вот в фейсбуке подумали, что хорошо бы была система, которая делает это сразу в одном месте. Подумали и написали, а потом и выложили в опенсорс.

Dynolog умеет мониторить весь стек, который может влиять на производительность ML вычислений и поддерживает трейсинг по запросу, что по-моему, очень полезная фича.

Проекту на гитхабе уже 2 года и его не забросили, что тоже важно в этом мире :)

#kubernetes #quota

Прям хорошая статья про квоты в кубере.

#java #kubernetes

Бывает так что приложение при старте потребляет много ресурсов, а потом меньше. Например, ява при старте в контейнере.
Гугл подумал об этом и написал оператор, который дает больше ресурсов приложению при старте, а потом отбирает.

#kubernetes #kubelet #security

Принес мой коллега вопрос от ИБ. А может ли атакующий поменять лейбл у ноды и в итоге зашедулить на хост под с более высокими привилегиями, чем предполагалось? И в принципе может!
kubelet у ноды ходит в api сервер с clusterrole system:node. Там ограничений на это особых нет.
Есть контроллер у кубера NodeRestriction, который не дает кубелету править лейблы других нод и есть специальный лейбл, который запрещено править вовсе - node-restriction.kubernetes.io.
Вот его и надо использовать на ноде для разграничений.

#dentry #linux #perfomance

Как большой размер dentry может жестко мешать работе контейнера.
Проблема в статье уже не актуальна для новых ядер, но будет полезна всем интересующимся тем, как докапываться до корня проблем.

#security

Sysdig (это компания, которая занимается безопасностью контейнеров) опубликовала тренды безопасности за 23 год.
Главной проблемой они называют что пользователи не следят за созданными ресурсами. В частности за выданными правами приложениям. А это, например, workload identity или сетевые правила.
Далее они жалуются что юзеры выбирают скорость в ущерб безопасности.
Так же говорят что среднее время атаки около 10 минут и не стоит думать что если ваши контейнеры живут не долго у атакующего ничего не получится.
Полный репорт где-то там по ссылке.

#cgroups #linux

Искал в интернете сведения про iocost и наткнулся на совершенно фееричный по своей полезности ресурс от FB.
В серии статей они рассказывают как с помощью механизмов cgroups добиваться большей утилизации на сервере не вредя основной нагрузке на сервере.
В цикле затрагиваются CPU/MEM/IO.
Советую прочитать всем кто интересуются перфоманс инжинирингом.

#oauth #openid

Понятное и короткое описание как работает OAuth2 и OpenID.

#almaLinux #redhat

Рассказ про то как делают АльмуЛинукс похожей на Редхат.

Пакеты берут из:
- базового образа от redhat (вообще отличная вещь я считаю для контейнеров)
- немного тянут из апстрима centos stream
- и чуть-чуть с опаской из OracleLinux

Далее собирают, сравнивают и получают альму.

#CFS #linux

Читал тут главу System Performance посвященную процессору и наткнулся на полиси шедулинга.
Ну вы все их знаете:
- RR
- FIFO
- NORMAL
- BATCH
- IDLE
- DEADLINE

Меня заинтересовало описание BATCH (говорят что это тоже самое что и NORMAL (OTHER), но всегда считается что это CPU-bound задача)

The difference is that this policy will cause the scheduler to always assume that the thread is CPU-intensive

Но что это означает для шедулера CFS (Completely Fair Scheduler)?
Хоть и в 6 ядре говорят появился новый шедулер, разобраться до конца как работает CFS мне все же было интересно. Поэтому я зарылся в инет на несколько часов.

Для себя я вынес следующее:
- Каждый процессор имеет свою очередь шедулинга.
- выбирается процесс с меньшим vruntime
- vruntime - это виртуальное время проведенное на процессоре
- следовательно - процессы потребляющие CPU работают реже, а процессы потребляющие IO - чаще
- Использует красно-черные деревья для шедулинга процессов
- Учитывает nice
- Если у процесса nice = 0 - vruntime не изменяется.
- Если у процесса nice < 0 - vruntime становится меньше
- Если у процесса nice > 0 - vruntime становится больше
- Есть групповой шедулинг. Это когда группе процессов может быть назначена группа, и другой группе процессов может быть назначена группа. И CFS пытается сделать так чтобы эти две группы процессов получили равное количество процессорного времени, не смотря на то что в одной группе может быть 5 процессов, а в другой 50.

Итого, чем же BATCH отличается от NORMAL (OTHER)?
В моем понимании, так как все batch процессы считаются CPU-bound по умолчанию, они сразу помещаются в правую сторону красно-черного дерева очереди процессов и соответственно вызываются реже.

В процессе изысканий наиболее полезными оказались следующие ресурсы
- Статья по CFS
- Видео про шедулинг в Linux курса SE 350