Linux Skill - Освой Linux c нуля до DevOps
11.2K subscribers
66 photos
103 videos
502 links
Освой Linux c нуля до DevOps
Подробный гайд по Linux и море других уроков для системных администраторов

📩 По всем вопросам: @chorapov

РКН https://vk.cc/cMUwm4
Download Telegram
Media is too big
VIEW IN TELEGRAM
🎥 Производительность Nginx vs Apache: кто победит?

В этом видео мы сравниваем два популярных веб-сервера — Nginx и Apache. Узнай, какой из них лучше справляется с нагрузкой и обеспечивает стабильную работу.


1. Введение и цели теста (00:00):
- Сравнение производительности Nginx и Apache на AWS.
- Измерение задержки, вывода данных и насыщенности сервисов.

2. Первый тест (01:38):
- Развертывание серверов на виртуальных машинах с использованием статического веб-сайта.
- Генерация нагрузки через кластер EKS.

3. Второй тест (02:36):
- Использование TLS и HTTP/2 для повышения производительности.
- Google оценивает сайты выше при использовании HTTPS.

4. Третий тест (03:12):
- Веб-серверы как обратные прокси: безопасность, масштабируемость, балансировка нагрузки.

5. Результаты первого теста (05:26):
- Nginx обрабатывает в три раза больше запросов в секунду, чем Apache.
- Apache снижает производительность при 8000 запросах в секунду.

6. Результаты второго теста (08:10):
- Nginx лучше справляется с нагрузкой при 85% загрузке процессора.
- Apache начинает снижать производительность при 7000 запросах в секунду.

7. Результаты третьего теста (11:02):
- Apache показывает лучшую производительность как прокси-сервер.
- Nginx демонстрирует нестабильность при высокой загрузке.

8. Использование памяти и сетевой трафик (14:10):
- Анализ использования памяти и сетевого трафика.
- Планируется тестирование Apache Ingress Controller для сравнения с Nginx.

Результаты тестов показывают, что Nginx превосходит Apache в обработке запросов, но Apache может быть более стабильным как прокси-сервер. Подписывайтесь на канал, чтобы не пропустить новые тесты и сравнения!
Источник: https://www.youtube.com/watch?v=UGp4LmocE7o

📩 Завтра: Как измерить время выполнения программы в Linux?
Включи 🔔 чтобы не пропустить!
____________________

Дополнительный материал:
🧠 - Овладейте искусством управления системой с серией руководств по Systemd
🧠 - Алфавит команд Linux
🧠 - Погружаемся в a2disconf

#Linux_youtube @LinuxSkill #Linux #Nginx #Apache #Performance #SysAdmin #DevOps
👍6👀3
⏱️ Как измерить время выполнения программы в Linux?

Хочешь узнать, сколько времени занимает выполнение твоих скриптов или команд в Linux? Сегодня мы расскажем, как использовать встроенную команду time для этого.

Основная информация:

Команда time позволяет измерить реальное время, затраченное на выполнение команды, а также время работы процессора. Вот как это сделать:

1. Использование команды time:

Просто добавь time перед командой, которую хочешь измерить. Например:

   time sleep 2


Вывод будет примерно таким:

   real    0m2.009s
user 0m0.000s
sys 0m0.004s


- real — общее время выполнения.
- user — время, затраченное на выполнение пользовательского кода.
- sys — время, затраченное на выполнение системного кода.

2. Измерение времени для нескольких команд:

Если нужно измерить время выполнения нескольких команд, используй группу команд:

   time { command1; command2; }


Используя команду time, ты можешь легко измерять производительность своих скриптов и оптимизировать их. Попробуй сам и убедись, насколько это полезно!

🌳 Ветка: https://stackoverflow.com/questions/385408/get-program-execution-time-in-the-shell

📩 Завтра: Как не стать жертвой сниффинга паролей на Linux
Включи 🔔 чтобы не пропустить!
____________________

Дополнительный материал:
🧠 - Открываем Мир b2-tools
🧠 - Открываем Все Тайны Команды Cat
🧠 - Разгадываем Загадки с Diff3

#stackoverflow @LinuxSkill #Linux #TimeCommand #Performance #SysAdmin #DevOps
👍14
Media is too big
VIEW IN TELEGRAM
🎥 Сравнение производительности Nginx и Caddy Performance: кто победит?

В этом видео мы сравниваем два мощных веб-сервера — Nginx и Caddy. Узнай, какой из них лучше справляется с нагрузкой и обеспечивает стабильную работу.

Основная информация:

1. Введение и цели теста (00:00):
- Сравнение Nginx и Caddy Performance как веб-серверов и обратных прокси-серверов.
- Тестирование обслуживания статического веб-сайта по HTTPS и балансировки нагрузки.

2. Настройка и оборудование (00:55):
- Использование AWS и новейших инстансов EC2 для создания кластера EKS.
- Применение Route 53 для обнаружения сервисов и Next.js для создания веб-сайта.

3. Настройка веб-серверов (01:53):
- Создание больших инстансов EC2 с двумя процессорами и 8 ГБ памяти.
- Настройка сертификатов для аутентификации и безопасности.

4. Оптимизация Nginx (03:38):
- Использование оптимизированной конфигурации для повышения производительности.
- Настройка мультиподключения и увеличение лимита открытых файлов.

5. Настройка Caddy (04:37):
- Использование минимальной конфигурации и включение сжатия.
- Формат логов, аналогичный Nginx и Apache.

6. Результаты первого теста (06:27):
- Nginx показал меньшую задержку и обработал больше запросов, чем Caddy.
- Caddy начал отставать при 8000 запросах в секунду.

7. Тестирование Nginx и Caddy (08:19):
- Nginx достиг 80% загрузки процессора и не сбоил.
- Caddy ухудшился при 8000 запросах, достигнув максимума при 10000 запросов.

8. Сетевой трафик и производительность (09:55):
- Nginx передавал почти 600 МБ/с, обеспечивая более высокую производительность.

9. Второй тест с обратным прокси (11:16):
- Caddy превзошел Nginx по производительности, но ненадолго.
- Nginx обработал почти 27000 запросов за 2 часа.

Nginx обработал почти вдвое больше запросов, чем Caddy, обеспечив более высокую пропускную способность и меньшую задержку. Рекомендуется использовать Nginx для веб-серверов и обратных прокси-серверов.

Источник: https://www.youtube.com/watch?v=N5PAU-vYrN8

📩 Завтра: Вопрос №11 из теста Linux Essentials Certification
Включи 🔔 чтобы не пропустить!
____________________

Дополнительный материал:
🧠 - Управление Процессами с Kill
🧠 - Временная Капсула с Last
🧠 - Как проверить файлы на целостность и не поймать вирус? Просто запусти md5sum!

#Linux_youtube @LinuxSkill #Linux #Nginx #Caddy #Performance #SysAdmin #DevOps
👍11👀2
Media is too big
VIEW IN TELEGRAM
🎥 Производительность Nginx против Traefik: кто победит?

В этом видео мы сравниваем два популярных обратных прокси-сервера — Nginx и Traefik. Узнай, какой из них лучше справляется с нагрузкой и обеспечивает стабильную работу.

1. Введение и цели тестирования (00:00):
- Сравнение Nginx и Traefik в качестве обратных прокси.
- Измерение задержки, доступности, загрузки процессора, памяти и сетевого трафика.

2. Инфраструктура и развертывание (00:53):
- Использование семи больших и четырех средних экземпляров для развертывания прокси и приложений.
- Создание кластера EKS для мониторинга и генерации нагрузки.

3. Функции обратного прокси-сервера (01:17):
- Балансировка нагрузки и динамическое масштабирование приложений.
- Возможность обновления приложений без простоев.

4. Преимущества и недостатки Nginx и Traefik (03:15):
- Nginx требует времени для настройки и оптимизации.
- Traefik имеет встроенные механизмы обнаружения сервисов и упрощает управление сертификатами.

5. Тестирование и настройка (05:44):
- Использование последних версий Nginx и Traefik.
- Включение журналов доступа и настройка прокси-серверов.

6. Результаты тестирования (08:04):
- Nginx поддерживает меньшую задержку и потребляет меньше ЦП.
- Traefik достигает 100% загрузки процессора быстрее, чем Nginx.

7. Заключение (10:14):
- Nginx обрабатывает больше запросов и потребляет больше ЦП.
- Задержка Nginx остается стабильной, в отличие от Traefik.

8. Использование памяти и частота ошибок (11:41):
- Traefik кэширует больше запросов, что объясняет задержку.
- Nginx отбрасывает несколько запросов для низкой задержки.

Оба сервера имеют свои преимущества и недостатки. Nginx обеспечивает стабильную задержку и лучше справляется с нагрузкой, в то время как Traefik предлагает удобство в управлении и настройке. Выбор зависит от ваших потребностей и предпочтений.

Источник: https://www.youtube.com/watch?v=42RNqGdpELE

📩 Завтра: Вопрос №14 из теста Linux Essentials Certification:
Включи 🔔 чтобы не пропустить!
____________________

Дополнительный материал:
🧠 - Ты точно знаешь, кто ты? Whoami расскажет!
🧠 - Ускорь работу в Linux на 200% с помощью команды xargs
🧠 - Хочешь сэкономить время? Вот как Yes скажет "да" за тебя

#Linux_youtube @LinuxSkill #Linux #Nginx #Traefik #Performance #SysAdmin #DevOps
👍6
🚀 Почему бенчмарки в bash дают разные результаты?

Привет, повелитель терминала! 🧙‍♂️

Запустил простой код:

bash -c 'x=0; time while ((x < 999999)); do ((++x)); done'


А время выполнения прыгает от 0.9 до 2.2 секунд? Почему?

Ответ: CPU Frequency Scaling.
Процессор снижает частоту при простое и повышает под нагрузкой.
Из-за этого первое выполнение скрипта медленнее последующих.

Решение:

1. Зафиксировать максимальную частоту ядра:

sudo cpupower -c 0 frequency-set -g performance


2. Закрепить выполнение скрипта за одним ядром:

taskset -c 0 ./your-benchmark


3. После теста вернуть режим энергосбережения:

sudo cpupower -c 0 frequency-set -g powersave


Бонус: Делай "разогревочный" прогон перед реальными замерами и старайся минимизировать фоновую нагрузку.

🌐 Источник: https://unix.stackexchange.com/questions/777424/why-are-my-benchmark-times-not-repeatable-even-for-a-cpu-bound-task

📩 Завтра: Как узнать ВСЁ о железе и системе в Linux за 5 минут
Включи 🔔 чтобы не пропустить!
____________________

Дополнительный материал:
🧠 - Мастер-класс по iptables: вставляем, заменяем и удаляем правила
🧠 - Настраиваем iptables с нуля: Полный гайд по фильтрации пакетов
🧠 - Раскрой тайны владения файлами с namei -o!


#stackoverflow @LinuxSkill #linux #bash #benchmark #performance
👍17🔥1
💥 Забудь про медленный SCP: NFS-сервер одной командой

Привет, скоростной гонщик!

Копируешь терабайты через SCP и ждёшь часами? NFS быстрее в разы! Держи готовую инструкцию для копипаста — настройка временной шары за 5 минут.

🖥️ На сервере:

Подготовка:

# mkdir /mnt/nfs
# chown nobody:nogroup /mnt/nfs
# apt install nfs-kernel-server


Настройка экспорта:

# nano /etc/exports
# Для одного IP:
/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)

# Для подсети:
/mnt/nfs 10.20.1.56/24(rw,all_squash,no_subtree_check,crossmnt)

# Для нескольких IP:
/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)
/mnt/nfs 10.20.1.52(rw,all_squash,no_subtree_check,crossmnt)


Запуск:

# systemctl restart nfs-server


💻 На клиенте:


# apt install nfs-common

# Проверка доступности:
# showmount -e 10.20.1.36

# Монтирование:
# mkdir /mnt/nfs
# mount 10.20.1.36:/mnt/nfs /mnt/nfs

# Проверка версии (должна быть v4):
# mount -t nfs4


🚀 Автомонтирование:

# echo "10.20.1.36:/mnt/nfs /mnt/nfs nfs4 defaults 0 0" >> /etc/fstab


💡 Порт 2049/tcp должен быть открыт!

Теперь копирование файлов летает! По скорости: NFS > HTTP > SMB > SSH > SCP.

________________

Дополнительный материал:
🧠 - Временная спираль Linux: От SysV к Systemd
🧠 - GRUB Rescue Mission: Как восстановить систему из grub rescue>
🧠 - Systemd для начинающих: Первые шаги к мастерству в Linux

#Linux_Mastery #nfs #network #storage #Linux #performance #filesharing
👍16
Media is too big
VIEW IN TELEGRAM
Linux грузится минуту? Ускоряем до 10 секунд!

Привет, нетерпеливый админ!

Устал ждать загрузку системы? Автор показывает, как сократить время старта с 60+ секунд до 10! Реальный кейс на Debian 12.

📹 Что узнаешь (таймкоды):

00:00 — Введение
00:57 — Анализ проблем загрузки
02:57systemd-analyze в действии
03:55 — Находим самые медленные службы
04:50 — Оптимизация монтирования разделов
06:47 — Отключаем ненужные службы
08:45 — Решаем проблему с ядром и swap
12:38 — Обновление системы
14:37 — Работа с NTFS разделами
18:31 — Результаты: с 37 до 6 секунд!
21:28 — Графический анализ загрузки

Смотри видео и ускоряй свою систему прямо сейчас!

🌐 Источник: https://youtu.be/sLZ8kYfp2lQ

#Linux_youtube #systemd #optimization #boot #Linux #performance #video
👍18🔥6
15 строк кода = полный контроль над производительностью

Эй, повелитель серверов!

Надоело переключаться между htop, df и free? Сейчас соберём свой монитор системы, который покажет всё важное одной командой. Bash + Python = твоя личная панель управления.

📌 Что получишь:
- CPU, RAM и диск в одном месте
- JSON-формат для интеграции
- Легко расширить под свои нужды

🔧 Шаг 1: Python-сборщик данных

Создай monitor.py:
import psutil
import json

def get_system_stats():
stats = {
"cpu": psutil.cpu_percent(interval=1),
"memory": psutil.virtual_memory().percent,
"disk": psutil.disk_usage('/').percent
}
return json.dumps(stats)

if __name__ == "__main__":
print(get_system_stats())


🔧 Шаг 2: Bash-обработчик

Создай monitor.sh:
#!/bin/bash
# Получаем данные от Python
stats=$(python3 monitor.py)

# Парсим JSON через jq
cpu=$(echo $stats | jq -r '.cpu')
memory=$(echo $stats | jq -r '.memory')
disk=$(echo $stats | jq -r '.disk')

# Красивый вывод
echo "CPU Usage: $cpu%"
echo "Memory Usage: $memory%"
echo "Disk Usage: $disk%"


🚀 Запускаем:
# Делаем исполняемым
chmod +x monitor.sh

# Смотрим магию
./monitor.sh


Результат:
CPU Usage: 12.3%
Memory Usage: 45.6%
Disk Usage: 67.8%


💡 Прокачай скрипт:
- Добавь алерты при превышении порогов
- Логируй данные для графиков
- Отправляй метрики в Telegram при критических значениях

Теперь один скрипт заменяет кучу утилит. А главное — ты можешь допилить его под свои задачи!
____________________

Дополнительный материал:
🧠 - Мастер-класс по выключению и перезагрузке Linux с помощью команды shutdown
🧠 - Прозрачность systemd: Освещаем теневые уголки системных процессов в Linux
🧠 - Управление питанием в Linux: Искусство выключения с помощью systemctl

#Linux_Mastery #Linux #Monitoring #Python #Bash #DevOps #Performance
🔥8👍6
🚀 Забудь про SCP! Вот как передавать файлы в 10 раз быстрее

Привет, повелитель скорости!

Устал ждать, пока SCP докачает твои гигабайты? NFS обгоняет SSH, SMB и HTTP по скорости передачи. Вот готовая шпаргалка — копипасть и используй.

Настройка NFS сервера

Создаём директорию для шары:
# mkdir /mnt/nfs
# chown nobody:nogroup /mnt/nfs


Ставим NFS сервер:
# apt install nfs-kernel-server


Настраиваем экспорт в /etc/exports:
# Для одного IP
/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)

# Для подсети
/mnt/nfs 10.20.1.56/24(rw,all_squash,no_subtree_check,crossmnt)

# Для нескольких IP (каждый в своей строке)
/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)
/mnt/nfs 10.20.1.52(rw,all_squash,no_subtree_check,crossmnt)


Перезапускаем и проверяем:
# systemctl restart nfs-server
# systemctl status nfs-server


💡 Важно: открой TCP порт 2049 в файрволе!

Настройка клиента

Ставим клиентский пакет:
# apt install nfs-common


Проверяем доступность сервера:
# showmount -e 10.20.1.36
Export list for 10.20.1.36:
/mnt/nfs 10.20.1.56


Монтируем шару:
# mkdir /mnt/nfs
# mount 10.20.1.36:/mnt/nfs /mnt/nfs


Проверяем результат:
# df -h | grep nfs
10.20.1.36:/mnt/nfs 48G 3.2G 43G 7% /mnt/nfs

# Смотрим версию протокола (должна быть v4)
# mount -t nfs4


Тестируем запись:
# echo "test" > /mnt/nfs/testfile


Для постоянного монтирования добавь в /etc/fstab:
10.20.1.36:/mnt/nfs /mnt/nfs nfs4 defaults 0 0


Результат: максимальная скорость передачи файлов между серверами. Особенно выручает для временных задач — поднял, скопировал, удалил.

____________________

Дополнительный материал:
🧠 - Путешествие во Времени: От ext до ext4 - Эволюция Файловых Систем Linux
🧠 - Linux Mastery: Организация файлов и каталогов
🧠 - Как пентестеры взломали ИТ-компанию через сайт уролога и Роскомнадзор

#Linux_Mastery #fileserver #nfs #linux #sysadmin #devops #performance
👍13
Media is too big
VIEW IN TELEGRAM
🔥 Как я ускорил поиск с 10 секунд до миллисекунд

Привет, цифровой архитектор!

Твой поиск по базе тормозит как трактор в болоте? Пользователи ждут результаты вечность, а ты не знаешь, как это починить? Сейчас покажу реальное решение.

📍 Таймкоды видео:
00:00 — Введение в Elasticsearch
02:05 — Почему обычный поиск тормозит
05:49 — Основные понятия: индексы, документы, запросы
07:09 — Установка через Docker
08:23 — Базовые команды GET, PUT, POST
10:51 — Добавление и обновление документов
14:19 — Настройка поиска и ранжирование
18:29 — Реальный пример: веб-приложение на Spring Boot
25:43 — Тестирование и результаты

🚀 Попробуй настроить у себя и сравни скорость!

🌐 Источник: https://youtu.be/vxE1aGTEnbE?si=1tTdg2QASMGfF6f_
____________________

Дополнительный материал:
🧠 - От простого до грандиозного: Путешествие Kubernetes в мире контейнеризации
🧠 - Linux Mastery: Управление разрешениями каталогов с помощью chmod
🧠 - Станьте мастером управления пользователями и группами в Linux с помощью команд adduser и addgroup

#Linux_youtube #Elasticsearch #DevOps #Search #Docker #Performance #Database
🔥3
Media is too big
VIEW IN TELEGRAM
📉 Диагностика производительности в Linux: с чего начать?

Если top, iotop, perf, uptime и vmstat вызывают только лёгкую тревогу, а не понимание — это видео для тебя.

Разбираем, как анализировать ресурсы, собирать метрики, строить флеймграфы и не ловить фантомные баги при помощи методики Брендона Грега.

🌐 Источник: https://www.youtube.com/watch?v=bGqdRyXWPP0

#linux #performance #diagnostics #devops #monitoring
👍11
🏎️ Почему твой Linux грузится вечность? Находим и обезвреживаем

Эй, линуксоид! 👋

Знакома ситуация: отправил сервер в reboot, и можно идти варить кофе, потому что он поднимается мучительно долго? 😤 Часто виноват один-единственный «зависший» сервис, который тянет время всей системы.

В systemd есть встроенный инструмент-детектив, который покажет, кто именно крадет твои секунды.

📌 1. Оцениваем общий масштаб бедствия
Сначала посмотрим, сколько времени ушло на загрузку в целом (ядро + userspace).

$ systemd-analyze
Startup finished in 253ms (kernel) + 933ms (initrd) + 6.873s (userspace) = 8.060s

Это дает общее понимание: если userspace занимает слишком много времени, значит, проблема в службах.

📌 2. Ищем виновника (команда blame)
Эта команда выводит список всех запущенных юнитов, отсортированных по времени инициализации — от самых медленных к самым быстрым.

$ systemd-analyze blame
3.811s NetworkManager-wait-online.service
806ms tuned.service
680ms postfix.service
490ms lvm2-monitor.service
...

В данном примере видно, что NetworkManager-wait-online.service задерживает запуск почти на 4 секунды.

📌 3. Анализируем критический путь
Иногда сервис запускается долго, но не тормозит остальных. Чтобы увидеть дерево зависимостей и понять, какой процесс реально блокирует финиш загрузки, используйте:

$ systemd-analyze critical-chain
graphical.target @9.663s
└─multi-user.target @9.661s
└─snapd.seeded.service @9.062s +62ms
└─basic.target @6.336s
└─sockets.target @6.334s
└─snapd.socket @6.316s +16ms
└─sysinit.target @6.281s
└─cloud-init.service @5.361s +905ms
└─systemd-networkd-wait-online.service @3.498s +1.860s

Здесь видно, что systemd-networkd-wait-online.service является узким местом в цепочке,.

💡 Совет:
Если вы нашли «тормоза», которые вам не нужны (например, postfix на рабочей станции или ожидание сети там, где это не критично), их можно отключить (systemctl disable) или оптимизировать.

#Linux #Systemd #DevOps #SysAdmin #Performance
👍10🔥3