DevOps Brain 🧠

Dive in performance tools. Часть 3️⃣ [bmon / bandwhich / iptraf / iperf]

Продолжим разбирать утилиты, помогающие в диагностике проблем с производительностью. Сегодня коснемся сетей. Но я сразу хочу проговорить пару моментов:

1. Разобрать детально все возможные проблемы с сетью, которые могут повлиять на производительность, в рамках одной данной серии постов нереально. Поэтому остановимся на тулах с прямым уклоном в определении что, куда и зачем утилизирует сеть.
2. Помимо перечисленных ниже тулзов существует огромное множество альтернатив. Я же хочу остановиться на тех, которые мне кажутся наиболее полезными и имеют вменяемый TUI.
3. Я не буду описывать способы установки тулзов под каждый дистрибутив, а остановлюсь на демонстрации основных возможностей. Установку гуглится за пару секунд — не будем тратить на это время.
4. Чтобы не спамить в канал буду выкладывать каждый день по 1 туле из списка.

3️⃣.1️⃣ bmon

https://github.com/tgraf/bmon — утилита для мониторинга сетевого трафика в реальном времени. Она показывает скорость передачи данных, ошибки, потери пакетов и общую статистику по интерфейсам.

Позволяет быстро взглянуть на утилизацию с сети и понять, что происходит с сетью в целом. Если нажать d - то появится детальная статистика, которую мы сейчас разберем на примере. Разберем детально что именно показывает нижняя панель details.

Давайте посмотрим данные, на которые стоит обратить внимание.

▶️ Bytes — Показывает объем входящего и исходящего трафика в байтах.
▶️ Abort Error — Ошибки разрыва соединения между источником и получателем пакета.
▶️ Carrier Errors — Ошибки связи между устройствами, возникающие из-за несоответствия дуплекса или проблем с сигналом.
▶️ Collisions — Количество коллизий (конфликтов) при передаче данных между устройствами.
▶️ CRC Errors — Ошибки контрольной суммы (Cyclic Redundancy Check, CRC), возникающие из-за поврежденных пакетов.
▶️ Dropped — Количество пакетов, которые были отброшены из-за проблем с доставкой (например, перегрузка сети).
▶️ Errors — Общее количество ошибок в сети.
▶️ FIFO Errors — Ошибки очереди FIFO (First In, First Out) — возникают, когда сетевой интерфейс не успевает передавать данные и буфер заполняется.
▶️ Frame Error — Ошибки фрейма — поврежденные пакеты, вызванные сбоями в передаче данных.
▶️ Heartbeat Errors — Количество потерянных сигналов (heartbeat) между оборудованием или программными модулями, что может привести к проблемам синхронизации.
▶️ Length Error — Ошибки длины пакетов - когда длина в заголовке меньше минимально возможного размера.
▶️ Missed Error — Количество пакетов, пропущенных при передаче (обычно пакеты нумеруются для их восстановления).
▶️ No Handler — Количество пакетов, для которых не найден обработчик протокола.
▶️ Over Errors — Ошибки переполнения - когда буфер приема был переполнен или пакеты превышали максимальную длину фрейма.
▶️ Window Error — Количество пакетов, в которых размер окна (число октетов в заголовке) оказался некорректным и не может быть обработан.


💭 Анализ вывода bmon на примере из скриншота

В данном случае разберем конкретный сетевой интерфейс. На графике показано мы видим ходящий трафик (RX): примерно 780 KiBps. Исходящий трафик (TX): 3.76 MiBps. Вывод: сервер больше отправляет данных, чем получает. Это характерно для сервера - тут вопросов нет.

Явные проблемы:

- 18K потерянных пакетов (RX) — возможно, перегрузка интерфейса или дроп пакетов из-за политики очередей (QoS).
- 7.82K ошибок приема — проблемы могут быть на уровне сетевого оборудования или драйвера.

Из хороших новостей — нет ошибок передачи - сервер стабильно передает данные, но испытывает проблемы с приемом.

А на этом у меня все, а в следущих постах мы с вами детально разберем bandwhich, iptraf и iperf...stay tuned ⬇️

🔑 Утечка секретов это всегда больно. Несу вам два решения, которые помогут обнаружить утекшие секреты и довольно легко интегрируются в cicd. (Методом pennis to nose интеграция в github actions займет минут 10 максимум).

Trufflehog (https://github.com/trufflesecurity/trufflehog) и Gitleaks (https://github.com/gitleaks/gitleaks) - оба решения очень похожи по своей сути, отличие только в алгоритмах поиска. Ну и Trufflehog - он более универсален и может искать утечки:

- git / github
- docker
- filesystem (files and directories)
- gitlab / circleci / travisci / jenkins
- gcs / s3
- postman
- syslog
- elasticsearch

Я не смог придумать кейсов когда надо постоянно проверять всю историю и при интеграции этих решений (если только вы не работаете в банке =) ). Кажется, достаточно проверить репозиторий один раз и дальше уже навешивать проверку просто на пул-реквесты ( с условием что у вас есть branch protection ). Ну и бонусом можно настроить git-хуки.

Подробные инструкции по использованию и установки я приводить нет смысла - они есть в github репах проектов. Единственное покажу как быстро потестить и запустить в докер проверку на файловой системе и репозиториях организации.

# проверяем текущий каталог
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest filesystem

# проверяем github репы организации trufflesecurity на github
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=trufflesecurity

Что в итоге выбрать?

- Trufflehog больше подходит для глубокого анализа, если вам нужно работать с разными источниками данных, но также может использоваться и для анализа пул-реквестов, ну и вашего кода.
- Gitleaks — если вы хотите быстро и просто проверять Git-репозитории с хорошей производительностью и минимальной настройкой.

Бесконечно можно смотреть на 3 вещи: огонь, воду и симулятор kafka от softwaremill

🔗 https://softwaremill.com/kafka-visualisation.

Очень классная визуализация, которая позволяет понять принципы работы и покрутить разные ручки для разных сценариев 🔥

#kafka #simulators

Пока сидел и ждал ребенка с тренировки наткнулся на ntfy. Это простой бесплатный и опенсорсный HTTP-сервис для уведомлений. Он позволяет отправлять уведомления на ваш телефон через POST запрос.

На самом деле прикольный сервис, особенно с учетом что его можно заселфхостить. Ставишь приложение, создаешь "топик". И просто curl-ом шлешь запросик.

curl -d "Backup successful 😀" ntfy.sh/devops-brain-test

Несмотря на свою простоту, он имеет очень хорошую документацию с кучей примеров использования https://docs.ntfy.sh/publish. Я честно пока не придумал зачем мне это может понадобиться, с учетом того, что нет никаких проблем в telegram создать канал под уведомления и через API-ключ также засылать в телегу.

curl -X POST \
     -H 'Content-Type: application/json' \
     -d '{"chat_id": "123456789", "text": "Backup successful 😀"}' \
     https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage

Но может вам такой способ получение пушей покажется более интересным и вы найдете как применить этот сервис. Вот тут есть много интеграций из коробки https://docs.ntfy.sh/integrations/

Котлеги, привет. Наткнулся вчера на решение для личного управления знаниями https://github.com/siyuan-note/siyuan. Думаю вот круто - 28000 звезд, написан на go и typescript, есть просто мощнейший редактор, есть расширения и API, интеграция с AI, есть готовые образы docker и активное коммьюнити.

Парни реально пишут крутое решение. Но есть пара минусов:

1. Нельзя заводить пользователей. Те доступ в workspace тупо по ключу. Ну оно и понятно оно же для личного управления знаниями все же.
2. SiYuan предоставляет большую часть функций бесплатно, даже для коммерческого использования. Однако есть платные возможности, которые доступны только членам Membership (платного тарифа). Например, синхронизация через облако.

Я сначала подумал, что мобильной прилке в настройках указываешь url где лежит твой поднятый siyuan. Но нет - оказывается это отдельное приложение со своим внутренним стораджем. Вот тут то и нужна синхронизация - ведь одна из фич, что документы можно редачить даже в offline. Но если это вам не нужно то достаточно будет открыть web url где развернут ваш персональный siyuan.

В целом видно, что ребята сосредоточились именно на core-фичах своего продукта и это здорово. Думаю на этом развитие не остановится и скоро мы увидим разные методы аутентификации для бизнеса и клаудовую версию, но будет это все скорее всего за денюжку. И мир увидит новый полноценный конкурент notion.

Подходит ли вам SiYuan? Как и с любым другим приложением, лучший способ понять, отвечает ли оно вашим задачам, — это попробовать. Так как оно бесплатное, вы ничего не теряете, кроме времени. В принципе и в рамках организации также можно его задействовать, прикрыв каким нибудь nginx + https://oauth2-proxy.github.io/oauth2-proxy/

mkdir -p siyuan/workspace && cd siyuan

cat <<EOF > compose.yml
services:
  main:
    image: b3log/siyuan
    command: ['--workspace=/siyuan/workspace/', '--accessAuthCode=change-me']
    ports:
      - 6806:6806
    volumes:
      - ./workspace:/siyuan/workspace
    restart: unless-stopped
EOF

docker compose up -d

🆕 Вредные советы начинающим специалистам в IT

Идея написать вредные советы у меня давно витала в голове. Если вы опытный специалист, то я надеюсь вам понравится и вы вспомните где то себя. А если вы как раз в начале карьеры, я надеюсь вы сделаете выводы.

0️⃣1️⃣ Не читай документацию. Она только путает и отвлекает от настоящей работы — гугли ответы на форумах и копируй чужие решения с StackOverflow или GPT.

0️⃣2️⃣ Никогда не проси помощи у коллег. Покажи всем, что ты «волк-одиночка» и можешь сам во всем разобраться, даже если это будет стоить бизнесу денег.

0️⃣3️⃣ Постоянно проси помощи у коллег. Это же в их интересах, чтобы ты сделал задачу побыстрее, поэтому постоянно проси помощи. К тому же, коллегам это очень нравится - они так чувствуют, что они важны в компании. Поверь, они очень любят помогать.

0️⃣4️⃣ Специально переусложняй реализацию. Чем запутаннее твое решение, тем более высоко смогут оценить тебя коллеги. Ведь это покажет, что ты можешь реализовать “сложные” решения.

0️⃣5️⃣ Комментарии и осмысленные названия переменных не нужны. Тут итак все понятно, зачем тратить время на какую то ерунду. К тому же, тимлид и коллеги явно поопытнее и уж точно разберутся.

0️⃣6️⃣ Не трать время на тестирование своего решения. Вообще пусть тестирует тот кто поставил тебе задачу, это же им надо.

0️⃣7️⃣ Не используй системы контроля версий. Зачем усложнять себе жизнь Git? Просто сохраняй файлы с названиями project_final_v6_final2 (FINAL).zip. Просто потом их в чат можно скинуть автору задачи, он там сам разберется уже. Зато ничего лишнего не будет в архиве.

0️⃣8️⃣ Сразу делай в production окружении. Тестовые и локальные окружения только трата времени. Зачем что-то проверять локально, если можно сделать в проде тем самым быстро пофиксить проблему. Коллеги оценят твою скорость и может даже премию дадут.

0️⃣9️⃣ Забудь про резервное копирование. Бэкапы — удел тех, кто не уверен в том что делает. Но ты то совершенно точно все делаешь правильно.

1️⃣0️⃣ Пароли храни в текстовом файле. Парольные менеджеры это переусложнение на ровном месте. У тебя же стоит антивирус и ты не ставишь программы с левых сайтов. Так что тебя точно никто и никогда не взломает и вирус ты никакой не поймаешь. А в файле все удобно, все под рукой

1️⃣1️⃣ Игнорируй обратную связь. Да что они вообще понимают? Ты итак потратил целых 2 недели на решение, а им еще что-то не нравится. Пусть сами тогда делают. Так и скажи руководителю. Скорее всего тебе пойдут на встречу и доделывать будет уже кто то другой.

1️⃣2️⃣ Тратить время на свое обучение больше не нужно. Ты ведь уже итак специалист: закончил курсы, посмотрел пару уроков на YouTube, почитал несколько статей — достаточно. Все остальное на практике доберешь. Лучше все изучать сразу на практике без нудной теории. Вот когда коснется чего то, тогда и изучишь.

1️⃣3️⃣ Любые знания, не относящиеся к твоей текущей задаче, бесполезны. Мир меняется очень медленно, чтобы тратить время на расширение кругозора и знаний. Если надо будет что то изучить новое — твой руководитель сразу к тебе придет и скажет. Тогда и поизучаешь.

1️⃣4️⃣ Забудь о документировании кода и проектов. Всё держи в голове. Документацию придумали те, кому лень разбираться в чем то. Хороший специалист разберется и так в том, что ты написал.

1️⃣5️⃣ Не контролируй сроки. Можно не париться на счет сроков. Пусть повисит в in progress несколько недель без движения — никто не заметит. К тому же когда ты ее закроешь, руководство увидит сколько времени потрачено и поймет, что это сложная задача.

1️⃣6️⃣ Никому не говори, если где то увидел проблему в проекте. Поверь, не надо подсвечивать ни свои, ни чужие косяки. Во-первых, вдруг "это не баг" и тогда тебя просто выставят дураком. Во-вторых, могут заставить фиксить.

1️⃣7️⃣ И самое главное — скрывай, если накосячил. Никогда, никому не сообщай, что где то серьезно продолбался. Ведь ты явно потеряешь репутацию или (что еще хуже) за это могут сразу уволить. А это явно не входит в твои планы, тем более это может серьезно помешать тебе стать успешным ойтипшником.

https://habr.com/ru/articles/875152/

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.4️⃣ Основные выводы в практическом примере

1. Высокий iowait (26.3% wa). Процессор «ждёт» операций ввода-вывода, что может указывать на интенсивные записи/чтения (например, Redis, сбрасывающий данные на диск). Для дальнейшей диагностики можно использовать утилиты вроде iotop, iostat, dstat, чтобы выявить «виновника» I/O. О них мы поговорим в следующих сериях.

2. Память (buff/cache). ~8.9 ГБ в кэше и буферах — это нормально: ядро старается использовать RAM по максимуму, чтобы ускорять операции. При необходимости эта память освобождается, так что free может быть небольшим, но available (9.4 ГБ) ещё даёт большой запас.

3. Нагрузка на CPU (us, sy, si). Суммарный пользовательский и системный процент невысок (около 13%), однако iowait делает общую картину менее радужной. Нужно следить за si (softirq), если оно продолжит расти, возможно, идёт большой сетевой трафик или нуждаются в настройке сетевые стеки.

4. Load average ~6. На сервере с 8 ядрами это не критично, но при дальнейших пиках нагрузка может дойти до очередей на выполнение задач. Необходимо мониторить в динамике - нет ли дальнейшего роста или все подконтролем.


2️⃣.5️⃣. Что еще можно посмотреть в top

Надо сказать, что вы можете настраивать список столбцов и отображать много других метрик, например:

- SWAP: объём свопа, используемый процессом.
- ENV: перменные окружения которые видит процесс.
- CODE, DATA: размер сегментов кода и данных в памяти.
- MajF, MinF: количество «major» и «minor» ошибок страницы (page faults).
- VolCxt, NonVolCxt: количество переключений контекста (voluntary/involuntary).
- P, CPU: на каком процессоре (или ядре) выполняется процесс.
- Threads: общее число потоков, запущенных процессом.
- И т. д.

Чтобы выбрать и упорядочить столбцы в интерактивном режиме можно нажать F и выбрать интересующую метрику.

И на этом у меня все, всем спасибо и хорошего дня 🦾️️️️️️ Дальше мы будем разбираться с другими тулами

Почитать на habr: https://habr.com/ru/articles/876428/

Бонус: для обучения сделал https://top.tools.devopsbrain.ru

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.3️⃣ Таблица процессов в top

Ниже разберём, что означают поля PR, NI, VIRT, RES, SHR в выводе top (или похожих утилит):

1. PR (Priority) – приоритет, с которым планировщик ядра запускает процесс. В Linux приоритет обычно отображается целым числом, где более высокое число означает более низкий приоритет (несмотря на кажущуюся «логичность» наоборот). Значения PR могут меняться динамически ядром, исходя из нагрузки и «nice»-приоритета процесса.

2. NI (Nice) – «nice»-значение процесса, задающее его базовый приоритет. Диапазон nice: от -20 (самый высокий приоритет) до +19 (низкий приоритет). По умолчанию процессы запускаются с nice = 0. Если запустить процесс с nice -n 10 COMMAND, то процесс получит NI = 10, то есть будет иметь более низкий приоритет при распределении CPU.

3. VIRT (Virtual Memory) – объём виртуального адресного пространства, зарезервированного или видимого для процесса. Большой VIRT не обязательно означает, что процесс реально занимает столько физической памяти; часть из этого может никогда не загружаться в оперативную память (RAM).

4. RES (Resident Memory) – резидентная (фактически используемая) память в физической оперативной памяти (RAM). Это объём памяти, действительно загруженный в ОЗУ для данного процесса. Если часть процесса или библиотеки выгружена в swap (или ещё не загружена), она не считается в RES.

5. SHR (Shared Memory) – объём разделяемой памяти, используемой процессом. Обычно это доля памяти, которую процесс использует вместе с другими (например, разделяемые библиотеки, общие сегменты). Если два процесса используют одну и ту же библиотеку, её часть может отображаться в SHR у обоих, но в действительности она хранится в памяти единоразово.

Таким образом:

- PR и NI определяют, с каким приоритетом планировщик будет выделять CPU для процесса.
- VIRT говорит, сколько адресного пространства потенциально доступно процессу.
- RES показывает, сколько физической памяти реально выделено ему в данный момент.
- SHR указывает, какую часть этой резидентной памяти (RES) процесс делит с другими.

Теперь разберем практический пример. Здесь мы видим группу процессов Redis под пользователем с UID 999, а также системные процессы (root). Пример строк с Redis:

PID      USER  PR NI    VIRT    RES   SHR  %CPU %MEM    TIME+      COMMAND
110005   999   20  0 8182684 3.2g  1524  36.5 10.8   0:14.70   redis-server
110045   999   20  0 8182684 1.1g  1532  28.2  3.6   1:10.86   redis-server
109437   999   20  0 8182292 3.2g  1744   9.6 12.9 111:19.74   redis-server
... и т.д.

- VIRT ~8.1 ГБ Это виртуальное адресное пространство (не значит, что все 8 ГБ реально заняты). В данном случае для Redis нормально поднимать большие VIRT, особенно если включены RDB/AOF-снапшоты.

- RES (фактическая резидентная память): мы видим 3.2G, 1.1G, 3.8G и т. д. У нескольких процессов Redis довольно большие значения. Суммарно они занимают значительную часть из 30 ГБ ОЗУ.

- %CPU по Redis варьируется от 9.3% до ~36%. Если сложить все Redis-процессы, получится внушительный процент — но поскольку система многопроцессорная, это ещё не обязательно «упор» в один CPU.

Продолжение следует… ⬇️

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.2️⃣ Про CPU

В строке CPU(s) в top видим восемь основных показателей — проценты от общего времени CPU:

1. us (user) – Время, затраченное на выполнение пользовательских процессов (приложений). Если значение us высокое, значит процессы в userspace активно нагружают процессор. Пример: сложные вычисления в Python, компрессия данных, рендеринг видео.

2. sy (system) – Время, занятое системными вызовами и кодом ядра (kernel space). Если sy растёт, это признак того, что ядро выполняет много работы (обработка I/O, сетевых стэков, драйверов и т. д.). Иногда это бывает из-за большого числа контекстных переключений, или интенсивного чтения-записи на диск.

3. ni (nice) – Время, отведённое процессам с изменённым приоритетом (nice). Если процессы запускаются с nice (пониженным приоритетом) или renice, их CPU-время может отражаться в ni. Редко встречается в большом объёме, если специально не конфигурируете приоритеты.

4. id (idle) – Процент времени, когда CPU простаивает. Если id высок, значит процессор почти без нагрузки. Важно понимать, что часть «простоя» может относиться к iowait, который выделяют отдельно.

5. wa (iowait) – Время, когда CPU простаивает в ожидании операций ввода-вывода (диск, сеть, и т. д.). Если wa велик (например, >10–15%), обычно это говорит, что система не успевает обрабатывать I/O, и процессор «ждёт» данные, вместо вычислять. При высоком iowait стоит проверить диски (iotop, iostat), подсистему хранения (SSD vs HDD) и сетевые операции (если хранилище находится в сети). Как это диагностировать мы поговорим в следующих статьях данного цикла.

6. hi (hardware interrupt) – Время обработки аппаратных прерываний. Например, при поступлении сигнала от сетевой карты или дискового контроллера. Если hi внезапно скачет, есть риск «шторма» прерываний из-за нештатной работы железа.

7. si (software interrupt) – Время обработки программных прерываний (softirqs). Часто связано с сетевыми пакетами, таймерами, межпроцессным взаимодействием. Высокие значения бывают при интенсивном сетевом трафике.

8. st (steal) – «Украденное» время при работе на виртуальной машине. Гипервизор может забирать часть CPU для других виртуалок. Если st высок, значит ваша VM не получает достаточно CPU-ресурсов от хост-сервера.

Важно: Если у вас многоядерный процессор (к примеру, 8 ядер), то проценты показывают агрегированное время по всем ядрам. Можно нажать 1 в top, чтобы увидеть загрузку по каждому ядру отдельно.

Давайте разберем практический пример:

19:48:03 up 403 days,  5:30,  1 user,  load average: 6.17, 5.91, 5.64
Tasks: 164 total,   3 running, 161 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.6 us,  5.7 sy,  0.0 ni, 55.1 id, 26.3 wa,  0.0 hi,  5.2 si,  0.0 st
MiB Mem : 30614.7 total,   846.8 free, 20870.0 used,  8898.0 buff/cache
MiB Swap:  5120.0 total,  5068.7 free,    51.3 used.  9435.4 avail Mem

1. Uptime: up 403 days, 5:30. Сервер не перезагружался более года.

2. Load average: 6.17, 5.91, 5.64. Загрузка за последние 1, 5 и 15 минут. Если на машине, к примеру, 8 ядер, эти значения — не критический показатель. Полезно помнить, что Load Average включает как процессы, использующие CPU, так и те, что ждут ввода-вывода (IO wait).

3. %Cpu(s). us = 7.6% — пользовательские процессы не особо перегружены. sy = 5.7% — умеренная нагрузка на ядро. id = 55.1% — более половины времени CPU простаивает. wa = 26.3% — довольно высокое ожидание I/O. Это может указывать на интенсивную запись/чтение (например, Redis сбрасывает свои данные). si = 5.2% — есть некоторая нагрузка софт-прерываний (сетевой трафик?). st = 0.0% — на данном экземпляре нет «украденного» времени (возможно, это физический сервер).

4. Память. Total: ~30.6 ГБ. Free: ~0.85 ГБ, однако buff/cache = ~8.9 ГБ и avail Mem = ~9.4 ГБ. То есть Linux эффективно использует оставшиеся ~8–9 ГБ под кэш, и при необходимости может её освободить. Swap: практически не используется (51.3 МБ), значит нехватки ОЗУ нет.

Продолжение следует…⬇️

Dive in performance tools. Часть 2️⃣. [top / htop]

Сегодня мы максимально подробно разберем такой базовый инструмент диагностики, который встречается чуть ли не в каждом гайде, а именно про top. По ходу мы знатно приправим все теорией и разберем практический пример анализа. Текст будет разбит на несколько разделов из-за ограничений телеги. Погнали 😲

2️⃣.1️⃣ Про память в Linux

Когда вы смотрите на показатели памяти (например, в top, free или через `cat /proc/meminfo`), важно понимать, что именно подразумевается под «used», «free», «buff/cache» и т. д. На первый взгляд может казаться, что система «съедает» всю память, но зачастую это лишь особенности кэширования и работы ядра.

1. Total — Общий объём оперативной памяти (RAM), который распознаёт ядро Linux.

2. Used — Количество памяти, занимаемой процессами вместе буферами и кэшами.

3. Free — Память, которая прямо сейчас не задействована ни под процессы, ни под кэш.

4. Buff/Cache
- Buffers — память, зарезервированная под буферизацию операций ввода-вывода (I/O). Пример: при копировании большого файла cp bigfile /backup/bigfile часть данных попадает в буферы, прежде чем окончательно записаться на диск. Это помогает оптимизировать операции записи. По окончании записи ядро освобождает или переиспользует буферы.
- Cache — память, используемая для кэширования файловых данных. Пример: когда вы повторно открываете один и тот же лог-файл, чтение во второй раз будет быстрее, так как ядро может брать данные из кэша (без повторных обращений к диску). Если приложению понадобится память, ядро автоматически «отдаст» часть кэша, так что buff/cache не означает «пропавшую» память.

5. Available — Показывает объём памяти, который ядро может отдать под новые процессы без использования swap. При необходимости кэш и буфер освобождаются автоматически.

6. Swap — Когда системе не хватает физической памяти (или при определённой настройке swappiness), неиспользуемые страницы памяти могут выгружаться в swap-раздел (или файл). Если swap активно используется, это может указывать на нехватку RAM, но иногда ядро использует swap и при наличии свободной памяти, если считает, что выгрузка «простаивающих» страниц — более эффективный вариант.

Продолжение следует… ⬇️

Эта кстати ещё тоже не закрыта. Нужен прям реальный джун-джун. Отправляйте тем кого любите.

У нас открылась еще одна вакансия SRE. Шлите тем, кого не любите больше всего 🤓

https://www.aviasales.ru/about/vacancies/3880098

⚡️⚡️⚡️ В России что-то глобально упало. Не работает Я.Почта, Гугл, ничего не работает, кроме Telegram. Как в 2018