Azalio_tech

#os #db Как насчет OS поверх распределенной базы данных? Один энтузиас и его команда (MIT, Stanford, Google, VMware и тд) разработала распределенную OS, в которой главная мантра: "Все есть таблица". И утверждают: - Она проще кубера и линукса. - Перфоманс локальной fs сравним с первомансом fs на линуксе. - Одним легким движением руки fs превращается в lustre подобную. - Можно легко откатить систему на любое ее состояние в прошлом. Вот прям на то состояние, которое было включая весь стейт. OS в основном предназначена для Stateful FaaS сервисов (написанных на TypeScript и использующих PostgreSQL) и работает намного быстрее чем AWS Lambda (по его словам, конечно) К сожалению, в открытом доступе ее нет и она продается в составе облака.

#kubernetes #k8s #etcd #scale Занимательная статья про скейлинг кубер-компонентов. - Скейлят etcd по нагруженным путям - Скейлят контроллер-менеджеры по задачам (выселили GC отдельно) - Скейлят api-servers через HPA Для балансировки используют envoy.

#THP #linux #mem Зашла в одном из рабочих чатов речь про Transparent Hugepages, которые заметно влияют на производительность систем и я пошел разбираться. Грегг "святой" Брендан в книге System performance говорит:

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

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

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

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

#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.

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

Зашел разговор в чате про токены, которые кубер выписывает сервис аккаунту пода для доступа к апи. Решил освежить знания. #kubernetes #sa https://telegra.ph/Kubernetes-SA-tokens-03-06

#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

#almaLinux #redhat Рассказ про то как делают АльмуЛинукс похожей на Редхат. Пакеты берут из: - базового образа от redhat (вообще отличная вещь я считаю для контейнеров) - немного тянут из апстрима centos stream - и чуть-чуть с опаской из OracleLinux Далее собирают, сравнивают и получают альму.

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

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

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

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

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

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

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

#gpu #monitoring Dynolog: Open source system observability GPU вычисления в последнее время как вы все знаете очень горячая тема. Наверное в каждой крупной компании сейчас стоят или скоро будут стоять вычислительные кластера забитые A100/H100 картами. И встает тема как мониторить их производительность на стыке CPU-GPU/GPU-GPU/IO. Да уже есть инструменты которые делают это по отдельности, но вот в фейсбуке подумали, что хорошо бы была система, которая делает это сразу в одном месте. Подумали и написали, а потом и выложили в опенсорс. Dynolog умеет мониторить весь стек, который может влиять на производительность ML вычислений и поддерживает трейсинг по запросу, что по-моему, очень полезная фича. Проекту на гитхабе уже 2 года и его не забросили, что тоже важно в этом мире :)

#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: растущий счетчик в микросекундах. Более длинно можно почитать еще и тут