#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

Зашел разговор в чате про токены, которые кубер выписывает сервис аккаунту пода для доступа к апи. Решил освежить знания.
#kubernetes #sa

https://telegra.ph/Kubernetes-SA-tokens-03-06

Разбирался тут с кешами процессора и нашел отличную хардкорную статью доступную для моего уровня понимания.
Так же вы узнаете за какое время процессор складывает два 64битных числа!
https://habr.com/ru/amp/publications/515660/

#linux #mem

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

Говорят примерно до 128 TB на x86_64
https://www.kernel.org/doc/Documentation/arch/x86/x86_64/mm.rst

И 256TB на ARM64
https://www.kernel.org/doc/Documentation/arch/arm64/memory.rst

Я решил проверить :)
Вот программка с помощью которой я это проверял:

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

int main() {
    char *chars;
    size_t nbytes;

    while(chars != MAP_FAILED) {
      nbytes +=  0x39999999; // almost 1GB
      chars = mmap(
        NULL,
        nbytes,
        PROT_READ | PROT_WRITE,
        MAP_SHARED | MAP_ANONYMOUS,
        -1,
        0
      );

      munmap(chars, nbytes);
    }

    printf("Allocated %ld total GB\n", nbytes/1024/1024/1024);
    exit(EXIT_FAILURE);
}

А вот что получилось:

5.14.0-362.18.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC

# free -m
               total        used        free      shared  buff/cache   available
Mem:         1031182        7334     1026066          82        2273     1023847
Swap:              0           0           0

# echo 0 > /proc/sys/vm/overcommit_memory - ОС смотрит на сколько памяти в системе + добавляет своп
# ./main.out
Allocated 1007 total GB
# echo 1 > /proc/sys/vm/overcommit_memory - ОС "не ограничивает" выделение памяти
# ./main.out
Allocated 130859 total GB
# echo 2 > /proc/sys/vm/overcommit_memory - ОС не дает больше чем в реальности сможет выделить
# ./main.out
Allocated 503 total GB - почему тут получилось 503GB мне не до конца ясно.

5.15.0-1034-raspi #37-Ubuntu SMP PREEMPT

# free -m
               total        used        free      shared  buff/cache   available
Mem:             905         198         346           3         360         616

(тут я немного модифицировал программу чтобы учесть что у меня всего 1GB оперативной памяти)
# echo 0 > /proc/sys/vm/overcommit_memory
# ./main.out
Allocated 906 total MB
# echo 1 > /proc/sys/vm/overcommit_memory
# ./main.out
Allocated 170 total TB
# echo 2 > /proc/sys/vm/overcommit_memory
root@raspberrypi-1:/home/azalio# ./main.out
Allocated 921 total MB

Что в итоге?
На ARM64 памяти выделили 170TB, а обещали 256TB.

#physics

Интересное видео о том работает транзистор на физическом уровне. Заодно рассказывают как на них складываются и вычитаются числа.

#linux #mem #aslr

В итоге дело оказалось в ASLR и дырках в адресном пространстве.
Указание опции компилятору -no-pie позволило выделить 255ТB виртуальной памяти.
Рассказали мне об этом на стековерфлоу :)

#THP #linux #mem

Зашла в одном из рабочих чатов речь про Transparent Hugepages, которые заметно влияют на производительность систем и я пошел разбираться.

Грегг "святой" Брендан в книге System performance говорит:

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

Перкона проводила тест для PostgreSQL и тест показал что чуть хуже становится при включении THP.

Но в тоже время почти все дистрибутивы включают их по-умолчанию. На SO тоже задались этим вопросом и получили очевидные ответы.

На куберах у нас эта опция включена, но на некоторых нодах по запросу продукта была переведена в madvise.
А должна она быть включена или нет в кубере, видимо, без глубоких тестов так и останется неизвестным.