IThub
Administrators
-
Joined
-
Last visited
Everything posted by IThub
-
Введение: зачем вообще нужен частотникПредставьте насос, который гоняет воду в системе водоснабжения. Без частотного преобразователя он работает в одном режиме — на полную мощность. Давление в сети выросло — открывается байпасный клапан и лишняя энергия тупо рассеивается. Это как ехать на машине с педалью газа в полу и тормозить ногой одновременно. Частотный преобразователь (ЧП, частотник, VFD — Variable Frequency Drive, инвертор) решает эту проблему радикально: он плавно регулирует скорость электродвигателя, меняя частоту и напряжение питания. Насосу нужно меньше давления — он просто крутится медленнее. Результат: экономия электроэнергии 30–70%, меньше износ оборудования, мягкий пуск без ударных нагрузок. Сегодня частотники стоят везде: насосы, вентиляторы, конвейеры, компрессоры, станки, лифты, краны. Если в вашем производстве есть асинхронный электродвигатель — с вероятностью 80% он или уже управляется частотником, или должен управляться. Принцип работы: что происходит внутриПонимание принципа работы — ключ к правильной настройке и диагностике. Внутри любого частотника три основных блока: 1. Выпрямитель (Rectifier)Входное переменное напряжение (380В/50Гц) выпрямляется в постоянное. Используется трёхфазный диодный мост. На выходе получаем ~540В постоянного тока (380 × √2 ≈ 537В). 2. Звено постоянного тока (DC Bus)Электролитические конденсаторы большой ёмкости сглаживают пульсации выпрямленного напряжения. Именно здесь хранится энергия рекуперации при торможении. Важно: после отключения питания конденсаторы остаются заряженными до 540В в течение нескольких минут. Всегда ждите разряда перед обслуживанием! 3. Инвертор (Inverter)IGBT-транзисторы переключаются по алгоритму ШИМ (широтно-импульсная модуляция) с частотой 2–16 кГц, формируя синусоидальный ток нужной частоты и амплитуды. Именно здесь и происходит "магия" — создание переменного тока с произвольными параметрами. Сеть 380В/50Гц → [Выпрямитель] → 540В DC → [Инвертор ШИМ] → Переменный ток 0-400Гц / 0-380В → Двигатель Типы управления: скалярное vs векторноеЭто первое принципиальное решение при настройке. Выбор не правильный — получите либо плохую динамику, либо нестабильную работу. Скалярное управление (V/f = const)Самый простой алгоритм: соотношение напряжения к частоте держится постоянным. Поднимаем частоту с 50Гц до 25Гц — напряжение тоже снижается вдвое (с 380В до 190В). Магнитный поток ротора остаётся примерно постоянным. Когда использовать: Насосы и вентиляторы (вентиляторная нагрузка) Момент не нужен на малых скоростях Несколько двигателей на одном частотнике Простые конвейеры без точного позиционирования Ограничения: При малых скоростях момент проседает. Нет контроля скорости под нагрузкой — при увеличении нагрузки двигатель чуть замедляется. Векторное управление (Vector Control)Алгоритм управляет не просто частотой и напряжением, а непосредственно вектором магнитного потока и моментом. Два варианта: Без датчика скорости (Sensorless Vector): Математическая модель двигателя внутри частотника оценивает скорость ротора и момент. Требует настройки параметров двигателя (автотюнинг). Точность: ±0.5–2% от номинала. С датчиком скорости (Closed Loop Vector): Энкодер на валу двигателя даёт точную информацию о скорости. Точность: ±0.01–0.1%. Используется в станках, намоточных машинах, лифтах. Когда использовать векторное: Нужен полный момент при нулевой скорости (краны, экструдеры) Точное поддержание скорости под переменной нагрузкой Быстрая динамика разгона/торможения Один двигатель — один частотник Выбор частотника: критерии и расчётМощностьГлавное правило: мощность частотника ≥ мощности двигателя. Для большинства применений выбирают одноступенчатое превышение по каталогу. Например, двигатель 11 кВт — берём частотник 11 кВт или 15 кВт. Поправочные коэффициенты: Условие Коэффициент к мощности Длинный кабель (>50м) ×1.1–1.2 Тяжёлый пуск (компрессор) ×1.25–1.5 Частые пуски/остановы ×1.25 Высокая температура (>40°C) Деrating по паспорту Высота >1000м над уровнем моря Derating 1% на каждые 100м ТокНоминальный ток частотника должен быть не меньше номинального тока двигателя с учётом пиковых нагрузок. Многие приводы имеют режим перегрузки 150% на 60 секунд или 200% на 3 секунды. Серии популярных производителейБюджетный сегмент (учёба, простые задачи): Delta VFD-E, VFD-M — отличное соотношение цена/качество Hyundai N700E — популярны в России Веспер Е5 — отечественный производитель Средний сегмент (промышленность): ABB ACS310, ACS550 — надёжные, хорошая документация Danfoss FC-051, FC-102 — особенно хороши для насосов Schneider Electric Altivar 312, 320 Высокий сегмент (серводрайвы, точное позиционирование): Siemens SINAMICS G120, S120 ABB ACS880 — промышленный стандарт Yaskawa A1000, GA700 Подключение: схема и важные нюансыСиловая частьСеть 3ф 380В | [Автоматический выключатель] ← Защита от КЗ, НЕ защита от перегрузки! | [Сетевой реактор] ← ОБЯЗАТЕЛЬНО при искажённой сети или мощности >15кВт | [Частотник] L1 L2 L3 — вход питания PE — заземление (обязательно!) U V W — выход на двигатель | [Моторный дроссель] ← при кабеле >20м, защита от перенапряжений | [Двигатель] Критические ошибки подключения: Никогда не подключайте выход ЧП к сети! U,V,W — только на двигатель. Никогда не ставьте контактор между ЧП и двигателем без специальной схемы — IGBT умирает мгновенно. Заземление обязательно — без него ЧП работает через паразитные ёмкости и сгорит от статики или помех. Разделяйте силовые и сигнальные кабели — минимум 20–30 см между ними. Управляющая частьТиповое подключение аналогового задания скорости (0–10В): ПЛК/потенциометр → AVI (Analog Voltage Input) — задание частоты ПЛК/кнопка → DI1 (Digital Input 1) — команда ПУСК ПЛК/кнопка → DI2 (Digital Input 2) — команда СТОП ЧП → DO1 (Digital Output 1) → ПЛК — сигнал "работает" ЧП → DO2 (Digital Output 2) → ПЛК/лампа — сигнал "авария" Токовое задание (4–20мА) более помехоустойчиво для длинных кабелей. При 4мА = 0 об/мин, при 20мА = максимальные обороты. Потеря сигнала (обрыв кабеля) → 0мА → частотник видит это как аварию. Основные параметры настройкиКаждый производитель имеет свои номера параметров, но логика везде одинакова. Покажем на примере логики настройки: Группа 1: Параметры двигателяЭто самые важные параметры — частотник должен "знать" двигатель: P_мощность = 7.5 кВт (с шильдика двигателя) P_напряжение = 380 В P_ток = 15.5 А P_частота = 50 Гц P_скорость = 1440 об/мин (или 1450, 1460 — смотреть шильдик) P_cos_phi = 0.86 После ввода этих данных — обязательно запустите автотюнинг (Auto-tuning). Частотник сам измерит активное сопротивление обмоток, индуктивность и другие параметры. Занимает 30–120 секунд. Двигатель при этом либо неподвижен (статический тюнинг), либо вращается (динамический — точнее). Группа 2: ОграниченияМин. частота = 5–10 Гц (ниже нельзя — перегрев двигателя) Макс. частота = 50–60 Гц (можно выше, но нужен расчёт подшипников) Макс. ток = 110–120% от номинала двигателя Группа 3: Разгон и торможениеВремя разгона = 5–30 с (чем тяжелее механизм — тем больше) Время торможения = 5–30 с Тип кривой = S-образная (плавнее для конвейеров, насосов) Слишком короткое время торможения → ошибка OV (перенапряжение в звене DC) → нужен тормозной резистор или увеличить время. Группа 4: Источник задания и управлениеИсточник задания частоты: аналог 0–10В / 4–20мА / цифровые входы / Modbus Источник команды пуск/стоп: цифровые входы / пульт / Modbus Режим управления: скалярный / векторный без датчика / с датчиком ПИД-регулятор в частотникеБольшинство современных ЧП имеют встроенный ПИД-регулятор. Это позволяет строить замкнутую систему управления без внешнего контроллера. Типичный пример: насос с поддержанием давления Датчик давления (4–20мА) → Вход обратной связи ЧП Уставка давления → Задание (аналог или цифровое значение) Выход ПИД → Управляет частотой насоса Настройка ПИД (упрощённый метод Циглера-Николса): Установить I=0, D=0, поднимать P до возникновения устойчивых колебаний Записать критический коэффициент Kc и период колебаний Tc P = 0.6×Kc, I = 2×Tc, D = Tc/8 Для насосов и вентиляторов (инерционная нагрузка) типичные значения: P (пропорциональная составляющая): 20–50% I (интегральная): 2–10 секунд D (дифференциальная): 0–1 секунда (часто не нужна) Важно: Включите функцию Sleep/Wake — при малом потреблении (ночное время) насос останавливается, при снижении давления — запускается. Экономия 15–30% электроэнергии. Защитные функции и их настройкаСовременный частотник — это не просто регулятор, это полноценная система защиты двигателя и механизма. Тепловая защита двигателя (Motor Thermal Protection)Электронный тепловой реле внутри ЧП моделирует нагрев двигателя на основе тока и времени. Задаётся номинальный ток двигателя (I_nom) и тепловая постоянная времени (обычно 30–600 секунд). Гораздо точнее биметаллических реле — учитывает режим работы. Защита от перенапряжения (OV — Over Voltage)Срабатывает когда напряжение в звене DC превышает порог (~800В для 380В-сетей). Причины: резкое торможение (обратная ЭДС двигателя), выброс в сети. Решения: увеличить время торможения, поставить тормозной резистор, включить функцию "регулирование торможения по напряжению DC". Защита от перегрузки (OC — Over Current)Ток превысил допустимый предел. Причины: механическое заклинивание, слишком короткое время разгона, неправильно введены параметры двигателя. Никогда не повышайте порог защиты бездумно — это приведёт к перегреву или сгоранию двигателя. Потеря фазы (Input/Output Phase Loss)Отсутствует одна из фаз входного питания или обрыв в кабеле до двигателя. Критически важная защита — трёхфазный двигатель на двух фазах перегревается за секунды. Коммуникация: Modbus RTU на практикеПочти все промышленные частотники поддерживают Modbus RTU через RS-485. Это позволяет управлять приводом с ПЛК или SCADA без аналоговых сигналов. Типичные Modbus-регистры (адреса условные, смотрите документацию вашего ЧП):Регистр Тип Описание 40001 Holding Управляющее слово (пуск/стоп/реверс) 40002 Holding Задание частоты (×0.01 Гц, т.е. 5000 = 50.00 Гц) 40003 Input Статусное слово (работает/авария) 40004 Input Текущая частота 40005 Input Ток двигателя (×0.1А) 40006 Input Напряжение DC-шины 40007 Input Код последней аварии Пример управления через Python (для тестирования и прототипирования):import minimalmodbus import time # Настройка соединения vfd = minimalmodbus.Instrument('/dev/ttyUSB0', 1) # COM-порт, адрес устройства = 1 vfd.serial.baudrate = 9600 vfd.serial.bytesize = 8 vfd.serial.parity = 'N' vfd.serial.stopbits = 1 vfd.serial.timeout = 0.5 vfd.mode = minimalmodbus.MODE_RTU def vfd_start(): """Команда ПУСК вперёд""" vfd.write_register(0x2000, 0x0002, functioncode=6) # Control word: Run Forward def vfd_stop(): """Команда СТОП (свободный выбег)""" vfd.write_register(0x2000, 0x0001, functioncode=6) # Control word: Stop def vfd_set_freq(freq_hz: float): """Задать частоту в Гц (0.0 - 50.0)""" value = int(freq_hz * 100) # Например 50.0 Гц → 5000 vfd.write_register(0x2001, value, functioncode=6) def vfd_get_status() -> dict: """Считать текущее состояние""" status_word = vfd.read_register(0x2100, functioncode=3) freq = vfd.read_register(0x2101, functioncode=3) / 100.0 current = vfd.read_register(0x2102, functioncode=3) / 10.0 voltage_dc = vfd.read_register(0x2103, functioncode=3) return { 'running': bool(status_word & 0x0001), 'fault': bool(status_word & 0x0008), 'frequency': freq, 'current': current, 'dc_voltage': voltage_dc } # Пример использования try: print("Запуск двигателя...") vfd_set_freq(30.0) # Задаём 30 Гц vfd_start() for i in range(10): time.sleep(2) status = vfd_get_status() print(f"Частота: {status['frequency']} Гц, Ток: {status['current']} А") if status['fault']: print("АВАРИЯ! Проверьте частотник.") break print("Остановка...") vfd_stop() except Exception as e: print(f"Ошибка связи: {e}") Типичные аварии и их устранениеF001 / OC — Сверхток при пускеСимптомы: Ошибка возникает сразу при подаче команды пуск или в первые секунды разгона. Причины и решения: Слишком короткое время разгона → Увеличить в 2–3 раза Механическое заклинивание → Проверить механику, проворачивается ли вал вручную КЗ в кабеле или обмотках → Мегомметром проверить изоляцию кабеля (500В) и двигателя Неверные параметры двигателя → Перепроверить ток, мощность, cos_phi Включён режим векторного управления без автотюнинга → Запустить автотюнинг F002 / OV — Перенапряжение в DC-шинеСимптомы: Ошибка при торможении или при резком снижении нагрузки. Причины и решения: Слишком короткое время торможения → Увеличить время Нет тормозного резистора при большом маховике → Установить резистор Высокое напряжение сети (>415В) → Проверить сеть, возможно нужен трансформатор Включить функцию "Voltage regulation during deceleration" — ЧП сам замедляет торможение F003 / OH — ПерегревСимптомы: После длительной работы или в жаркую погоду. Причины и решения: Загрязнён радиатор → Очистить сжатым воздухом (не водой!) Сломан вентилятор охлаждения → Заменить Недостаточно места для вентиляции → Минимум 10 см сверху и снизу Температура в шкафу >40°C → Добавить принудительную вентиляцию шкафа Слишком высокая частота ШИМ → Снизить с 8кГц до 4кГц (будет чуть громче, но прохладнее) F004 / LV — Пониженное напряжениеСимптомы: При просадке сети или при запуске мощного оборудования рядом. Решения: Проверить напряжение сети мультиметром под нагрузкой Установить сетевой реактор — сглаживает просадки Настроить время повторного пуска после восстановления питания (Auto-restart) Энергосбережение: реальные цифрыЗакон куба: мощность вентилятора/насоса пропорциональна кубу скорости. Снизили скорость на 20% → потребление упало на 49%! P2/P1 = (n2/n1)³ При n1 = 50 Гц, n2 = 40 Гц (снижение на 20%): P2/P1 = (40/50)³ = 0.512 → экономия 48.8%! Реальный пример из практики: вентилятор системы вентиляции цеха, 55 кВт, работал 24/7 на 50 Гц. После установки частотника с датчиком CO2 и ПИД-регулятором: Среднесуточная частота работы: 35–40 Гц Фактическое потребление: снизилось с 55 кВт до 22–28 кВт Годовая экономия: ~250 000 кВт·ч При тарифе 6 руб/кВт·ч: 1 500 000 руб/год Стоимость частотника 55 кВт: ~180 000 руб Срок окупаемости: 6 недель Чек-лист при вводе в эксплуатациюПеред первым пуском обязательно проверить: □ Напряжение питания соответствует номиналу ЧП (380В ±10%) □ Заземление подключено и проверено (<4 Ом) □ Кабели L1-L2-L3 и U-V-W не перепутаны местами □ Нет КЗ между фазами и на землю (мегомметром) □ Введены параметры двигателя (шильдик) □ Проведён автотюнинг □ Настроены ограничения: мин/макс частота, макс ток □ Настроены времена разгона/торможения □ Проверена правильность направления вращения (на малой скорости 5–10 Гц) □ Настроены аварийные выходы и тестирована их реакция □ Записаны все изменённые параметры в документацию ЗаключениеЧастотный преобразователь — один из самых универсальных и окупаемых инструментов в промышленной автоматизации. Правильно подобранный и настроенный, он одновременно экономит электроэнергию, продлевает ресурс двигателя и механического оборудования, даёт возможность тонкого управления технологическим процессом. Ключевые принципы, которые стоит запомнить: выбирайте тип управления под задачу, всегда вводите точные параметры двигателя и делайте автотюнинг, не пренебрегайте сетевыми и моторными дросселями, настраивайте защиты адекватно нагрузке. И помните про безопасность — конденсаторы DC-шины хранят смертельное напряжение ещё несколько минут после отключения питания. Изучите документацию на ваш конкретный привод — производители вкладывают в неё годы опыта тысяч инсталляций. Это лучший источник правильных решений для конкретного устройства. -
Пользователи не любят ждать. Если кнопка "Отправить" не реагирует три секунды — они уже в Twitter пишут что ваш сайт сломан. Один из самых мощных инструментов для улучшения perceived performance — асинхронная обработка через очереди. Что уходит в очередьВ HTTP-запросе должно происходить только то, что нужно пользователю для немедленного ответа. Что НЕ нужно пользователю немедленно: Отправка email Генерация PDF Пересчёт статистики Синхронизация с внешними системами Изменение размеров изображений Push-уведомления Webhook-уведомления партнёров Всё это — в очередь. HTTP отвечает за 50ms. Фоновый воркер делает остальное. Базовая архитектура очередей на Redis + CI4<?php namespace App\Libraries\Queue; class Queue { private \Redis $redis; private string $prefix = 'queue:'; public function push(string $queueName, BaseJob $job, int $delay = 0): string { $payload = [ 'id' => $id = uniqid('job_', true), 'class' => get_class($job), 'data' => serialize($job), 'attempt' => 0, 'created_at' => time(), ]; if ($delay > 0) { $this->redis->zAdd( $this->prefix . 'delayed:' . $queueName, time() + $delay, json_encode($payload) ); } else { $this->redis->lPush($this->prefix . $queueName, json_encode($payload)); } return $id; } public function pop(string $queueName, int $timeout = 5): ?array { $this->promoteDelayedJobs($queueName); $result = $this->redis->brPop($this->prefix . $queueName, $timeout); return $result ? json_decode($result[1], true) : null; } private function promoteDelayedJobs(string $queueName): void { $delayedKey = $this->prefix . 'delayed:' . $queueName; $jobs = $this->redis->zRangeByScore($delayedKey, '-inf', time()); foreach ($jobs as $job) { $this->redis->multi(); $this->redis->zRem($delayedKey, $job); $this->redis->lPush($this->prefix . $queueName, $job); $this->redis->exec(); } } } Worker — CI4 CLI команда<?php namespace App\Commands; use App\Libraries\Queue\Queue; class QueueWorker extends BaseCommand { protected $name = 'queue:work'; protected $description = 'Process jobs from the queue'; private bool $shouldStop = false; public function run(array $params): void { $queueName = $params[0] ?? 'default'; $maxJobs = (int) ($this->getOption('max-jobs') ?? 0); $processed = 0; if (function_exists('pcntl_signal')) { pcntl_signal(SIGTERM, fn() => $this->shouldStop = true); pcntl_signal(SIGINT, fn() => $this->shouldStop = true); } $queue = new Queue(); while (!$this->shouldStop) { if (function_exists('pcntl_signal_dispatch')) { pcntl_signal_dispatch(); } $payload = $queue->pop($queueName); if (!$payload) continue; $this->processJob($queue, $queueName, $payload); $processed++; if ($maxJobs > 0 && $processed >= $maxJobs) break; } } private function processJob(Queue $queue, string $queueName, array $payload): void { try { $job = unserialize($payload['data']); $job->setAttempt($payload['attempt'] + 1); set_time_limit($job->getTimeout()); $job->handle(); } catch (\Throwable $e) { $payload['attempt']++; if ($payload['attempt'] < $job->getMaxAttempts()) { $delay = pow(2, $payload['attempt']) * 10; $queue->push($queueName, $job, $delay); } else { $job->failed($e); $queue->bury($queueName, $payload); } } } } Реальный пример: отправка email<?php namespace App\Jobs; use App\Libraries\Queue\BaseJob; class SendWelcomeEmailJob extends BaseJob { protected int $maxAttempts = 5; protected int $timeout = 30; public function __construct( private readonly int $userId, private readonly string $email, private readonly string $name ) {} public function handle(): void { service('email')->send( to: $this->email, subject: 'Добро пожаловать!', view: 'emails/welcome', data: ['name' => $this->name] ); model('EmailLogModel')->insert([ 'user_id' => $this->userId, 'type' => 'welcome', 'sent_at' => date('Y-m-d H:i:s'), 'status' => 'sent', ]); } } Использование в Controller: // Вместо: $emailService->send(...); // ждём 500ms // Делаем: $queue = new Queue(); $queue->push('emails', new SendWelcomeEmailJob($user->id, $user->email, $user->name)); // HTTP response за 15ms вместо 515ms return $this->response->setJSON(['status' => 'registered', 'message' => 'Check your email']); РезультатыEndpoint До После POST /register 580ms 45ms POST /upload-photo 2300ms 120ms POST /generate-report 8000ms 80ms (async) POST /checkout 1200ms 340ms Bounce rate на страницах с "тяжёлыми" действиями упал на 34%. Конверсия регистрации выросла на 12%. Просто потому что форма теперь отвечает мгновенно. Пользователи не знают о ваших очередях. Они просто чувствуют что сайт быстрый. Это и есть цель. ⚡ Максим — продуктовый DevOps с горящими глазами и умеренно сгоревшими нервами. Пишу про реальный highload, реальные ошибки и реальные решения. Больше таких историй — на ithub.uno, там собираются те, кто делает, а не только говорит.
-
"Просто добавь серверов" — говорят менеджеры. "Это не так просто" — говорим мы. Сегодня расскажу почему не так просто, и как всё-таки сделать так, чтобы было просто.Проблема №1: Состояние сессийЗапускаете второй сервер, и пользователи жалуются: "я только что вошёл, а меня снова просит логин". Потому что сессия хранится в файловой системе первого сервера. Правильное решение: Redis-сессии: // app/Config/App.php public string $sessionDriver = 'CodeIgniter\Session\Handlers\RedisHandler'; public string $sessionSavePath = 'tcp://redis-cluster:6379?auth=password&database=1'; public int $sessionExpiration = 7200; public bool $sessionMatchIP = false; // Важно! Иначе CDN сломает сессии С Sentinel для HA: public string $sessionSavePath = 'tcp://redis-sentinel:26379?auth=password&database=1&sentinel_master=mymaster'; Проблема №2: Загрузка файловПользователь загружает аватар на сервер #1. Следующий запрос идёт на сервер #2 — он ничего не знает об этом файле. Решение: S3-совместимое хранилище: <?php namespace App\Services; use Aws\S3\S3Client; class FileStorageService { private S3Client $s3; public function __construct() { $config = config('FileStorage'); $this->s3 = new S3Client([ 'version' => 'latest', 'region' => $config->region, 'endpoint' => $config->endpoint, 'credentials' => ['key' => $config->key, 'secret' => $config->secret], 'use_path_style_endpoint' => $config->usePathStyle, ]); } public function upload(string $localPath, string $remotePath, string $acl = 'private'): string { $this->s3->putObject([ 'Bucket' => $this->bucket, 'Key' => $remotePath, 'SourceFile' => $localPath, 'ACL' => $acl, 'ContentType' => mime_content_type($localPath), ]); return $this->getUrl($remotePath); } public function getSignedUrl(string $remotePath, int $expiry = 3600): string { $cmd = $this->s3->getCommand('GetObject', ['Bucket' => $this->bucket, 'Key' => $remotePath]); return (string) $this->s3->createPresignedRequest($cmd, "+{$expiry} seconds")->getUri(); } } Проблема №3: Cron jobs10 серверов, у каждого crontab — пользователи получают email 10 раз. Решение: distributed locking: <?php namespace App\Libraries; class DistributedLock { private string $lockValue; public function __construct( private readonly string $key, private readonly int $ttl = 300 ) { $this->lockValue = gethostname() . '_' . getmypid() . '_' . uniqid(); } public function acquire(): bool { // SET key value NX EX ttl — атомарная операция $result = cache()->getRedis()->set( $this->key, $this->lockValue, ['NX', 'EX' => $this->ttl] ); return $result === true; } public function release(): bool { // Lua для атомарного освобождения только СВОЕГО лока $script = <<<LUA if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end LUA; return (bool) cache()->getRedis()->eval($script, [$this->key, $this->lockValue], 1); } } Базовый класс для singleton cron-команд: abstract class SingletonCommand extends BaseCommand { protected int $lockTtl = 300; final public function run(array $params): void { $lock = new DistributedLock('cron_lock_' . static::class, $this->lockTtl); if (!$lock->acquire()) { $this->write("Another instance is already running. Skipping."); return; } try { $this->execute($params); } finally { $lock->release(); } } abstract protected function execute(array $params): void; } Чеклист горизонтального масштабированияПеред тем как добавить второй сервер: ✅ Сессии в Redis/Memcached, не в файловой системе ✅ Файлы в S3/MinIO, не на диск ✅ Кэш в Redis, не в файловой системе ✅ Логи в centralized storage (ELK/Loki) ✅ Cron с distributed locking ✅ Конфиги из environment variables ✅ Нет hardcoded hostname в коде ✅ Нет состояния в оперативной памяти между запросами ✅ Graceful shutdown (SIGTERM handler) ✅ Health checks настроены Если всё это есть — добавление сервера занимает минуты. Если нет — недели головной боли. На ithub.uno таких архитектурных обсуждений всегда много — там есть практические нюансы, которых нет в документации. Масштабируйтесь грамотно. 📊🖥️
-
Это история эволюции. Начнём с того момента, когда деплой выглядел так: "Ваня, выгрузи файлики на сервер через FileZilla". И закончим тем, что у нас сейчас — полностью автоматический pipeline с тестами, security checks, zero-downtime deploy и автоматическим rollback. Эра FTP (тёмные времена)Просто знайте: когда я пришёл в эту компанию, деплой выглядел следующим образом: Разработчик локально делал изменения Открывал FileZilla Перетаскивал папку app/ на сервер Молился Это было в 2019 году. Не в 2009, а в 2019. Такое ещё встречается. Шаг 1: Git + простой CI# .gitlab-ci.yml v1.0 — наивная версия stages: - test - deploy test: stage: test script: - composer install - php vendor/bin/phpunit deploy: stage: deploy script: - ssh deploy@production "cd /var/www/app && git pull && composer install" only: - main git pull на продакшне — это тоже не очень хорошая идея, но это следующий шаг. Шаг 2: Деплой через rsync + atomic switch#!/bin/bash set -euo pipefail DEPLOY_PATH="/var/www" RELEASES_PATH="$DEPLOY_PATH/releases" CURRENT_LINK="$DEPLOY_PATH/current" RELEASE_ID=$(date +%Y%m%d_%H%M%S) RELEASE_PATH="$RELEASES_PATH/$RELEASE_ID" mkdir -p "$RELEASE_PATH" rsync -az --exclude='.git' --exclude='vendor' --exclude='writable' \ ./ "$RELEASE_PATH/" ln -sf "$SHARED_PATH/writable" "$RELEASE_PATH/writable" ln -sf "$SHARED_PATH/.env" "$RELEASE_PATH/.env" cd "$RELEASE_PATH" composer install --no-dev --optimize-autoloader --no-interaction php spark migrate --no-interaction # Атомарное переключение симлинка — zero downtime! ln -sfn "$RELEASE_PATH" "$CURRENT_LINK" nginx -s reload ls -dt "$RELEASES_PATH"/* | tail -n +6 | xargs rm -rf echo "✅ Deploy $RELEASE_ID complete" Rollback: ls -dt /var/www/releases/* | head -2 | tail -1 | xargs -I{} ln -sfn {} /var/www/current nginx -s reload Шаг 3: Docker + KubernetesDockerfile для PHP 8.3 + CI4: FROM composer:2.7 AS vendor-builder WORKDIR /app COPY composer.json composer.lock ./ RUN composer install --no-dev --no-scripts --no-autoloader --prefer-dist COPY . . RUN composer dump-autoload --optimize --classmap-authoritative FROM php:8.3-fpm-alpine AS production RUN apk add --no-cache libzip-dev icu-dev \ && docker-php-ext-install pdo_mysql zip intl opcache \ && pecl install redis igbinary \ && docker-php-ext-enable redis igbinary COPY docker/php/php.ini /usr/local/etc/php/php.ini COPY docker/php/www.conf /usr/local/etc/php-fpm.d/www.conf WORKDIR /var/www/html COPY --from=vendor-builder /app/vendor ./vendor COPY --from=vendor-builder /app/app ./app COPY --from=vendor-builder /app/system ./system COPY --from=vendor-builder /app/public ./public COPY --from=vendor-builder /app/spark ./spark HEALTHCHECK --interval=10s --timeout=3s --retries=3 \ CMD php-fpm -t || exit 1 EXPOSE 9000 USER www-data CMD ["php-fpm"] GitLab CI/CD — финальная версия: stages: - validate - test - security - build - deploy-staging - integration-test - deploy-production - verify variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA lint: stage: validate script: - find app/ -name "*.php" -exec php -l {} \; - composer validate --strict unit-tests: stage: test services: - mysql:8.0 - redis:7.0-alpine script: - php spark migrate --env=testing - vendor/bin/phpunit --coverage-min=70 sast: stage: security script: - vendor/bin/psalm --no-cache - composer audit --no-dev build-image: stage: build script: - docker build --target production -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE deploy-production: stage: deploy-production when: manual # Требует ручного подтверждения! script: - kubectl set image deployment/php-app php-fpm=$DOCKER_IMAGE -n production - kubectl rollout status deployment/php-app -n production --timeout=10m post-deploy-verify: stage: verify script: - sleep 60 - php spark synthetic:run --suite=smoke --env=production - | ERROR_RATE=$(curl -s "http://prometheus/api/v1/query?query=rate(http_errors_total[5m])" | jq '.data.result[0].value[1]') if (( $(echo "$ERROR_RATE > 0.05" | bc -l) )); then echo "Error rate too high! Auto-rollback!" kubectl rollout undo deployment/php-app -n production exit 1 fi Итого: что получилиМетрика FTP era Git + rsync Docker + k8s Время деплоя 5-40 мин 3-8 мин 2-4 мин Downtime при деплое 30s-5min 0 0 Rollback время 10-30 мин 2 мин 45 секунд Деплоев в день 1-2 5-10 20-30 Инцидентов из-за деплоя 2-3/мес 0-1/мес ~0 Больше деплоев в день — это не потому что мы хаотичнее. Маленькие частые деплои безопаснее больших редких. Каждый PR идёт в прод в тот же день. Это называется continuous delivery. И это меняет жизнь. 🚀
-
Есть два типа DevOps. Первые узнают об авариях от пользователей. Вторые — за 5 минут до того как проблема станет аварией. Я прошёл путь от первого ко второму. Это было долго, больно и неочевидно. Расскажу как. Уровень 0: Никакого мониторингаЭто страшное место. Узнаёшь что что-то не так, когда: Пишет пользователь в поддержку Звонит CEO в воскресенье Видишь в Twitter "ваш сайт сломан" Это лечится быстро — после первого воскресного звонка от CEO инстинкт самосохранения быстро мотивирует к действию. Уровень 1: Uptime monitoringСамое простое: проверяем что сайт отвечает: class HealthCheck extends BaseCommand { protected $name = 'health:check'; public function run(array $params): void { $endpoints = config('HealthCheck')->endpoints; foreach ($endpoints as $endpoint) { $start = microtime(true); try { $response = \Config\Services::curlrequest()->get($endpoint['url'], [ 'timeout' => 10, 'http_errors' => false, ]); $duration = (microtime(true) - $start) * 1000; $status = $response->getStatusCode(); if ($status !== 200 || $duration > $endpoint['threshold_ms']) { $this->alertTeam($endpoint, $status, $duration); } } catch (\Exception $e) { $this->alertTeam($endpoint, 0, 0, $e->getMessage()); } } } } Лучше чем ничего. Но это как термометр в одной комнате большого дома. Уровень 2: Application метрикиPrometheus + Grafana. В CI4 интегрируем через After-фильтр: <?php namespace App\Filters; class MetricsFilter implements FilterInterface { public function before(RequestInterface $request, $arguments = null): void { $GLOBALS['_request_start_time'] = microtime(true); } public function after( RequestInterface $request, ResponseInterface $response, $arguments = null ): ResponseInterface { $duration = microtime(true) - ($GLOBALS['_request_start_time'] ?? microtime(true)); $status = $response->getStatusCode(); $route = service('router')->controllerName(); $method = $request->getMethod(); $metrics = service('metricsCollector'); $metrics->histogram( 'http_request_duration_seconds', $duration, ['method' => $method, 'route' => $route, 'status' => $status] ); $metrics->counter( 'http_requests_total', 1, ['method' => $method, 'route' => $route, 'status' => (string)intdiv($status, 100) . 'xx'] ); if ($status >= 500) { $metrics->counter('http_errors_total', 1, ['route' => $route]); } return $response; } } Уровень 3: Предиктивные алертыНастоящий прорыг — когда алерты стали срабатывать ДО того как всё упало. Пример: за 8-12 минут до OOM Redis всегда происходило: Memory usage рос быстрее обычного (+15% за 5 минут) Cache hit rate начинал падать Eviction rate был 0 Prometheus alerting rule: groups: - name: redis_predictive rules: - alert: RedisMemoryGrowthAnomaly expr: | ( redis_memory_used_bytes / redis_memory_max_bytes > 0.75 ) and ( rate(redis_memory_used_bytes[5m]) > 0 ) and ( redis_stat_keyspace_hits / (redis_stat_keyspace_hits + redis_stat_keyspace_misses) < 0.85 ) for: 3m labels: severity: warning annotations: summary: "Redis memory growing fast, potential OOM in ~10min" - alert: MySQLConnectionPoolDanger expr: | mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8 for: 2m labels: severity: critical annotations: summary: "MySQL connection pool at {{ $value | humanizePercentage }}" Уровень 4: Synthetic monitoringПроверяем что реальный пользовательский сценарий работает end-to-end. CLI-команда CI4 каждые 2 минуты симулирует key user journey: namespace App\Commands\Synthetic; class CheckoutFlow extends BaseCommand { protected $name = 'synthetic:checkout'; public function run(array $params): void { $client = service('curlrequest'); $baseUrl = env('SYNTHETIC_BASE_URL'); $metrics = service('metricsCollector'); $start = microtime(true); $step = 'init'; try { $step = 'login'; $loginResp = $client->post($baseUrl . '/api/auth/login', [ 'json' => ['email' => env('SYNTHETIC_USER_EMAIL'), 'password' => env('SYNTHETIC_USER_PASSWORD')], 'timeout' => 5, ]); assert($loginResp->getStatusCode() === 200); $token = json_decode($loginResp->getBody(), true)['token']; $step = 'product_list'; $productsResp = $client->get($baseUrl . '/api/products', [ 'headers' => ['Authorization' => "Bearer $token"], 'timeout' => 3, ]); assert($productsResp->getStatusCode() === 200); // ... другие шаги $metrics->counter('synthetic_checkout_flow_success_total', 1); $this->write("✅ Checkout flow OK "); } catch (\Throwable $e) { $metrics->counter('synthetic_checkout_flow_failure_total', 1, ['step' => $step]); service('alertManager')->fire(level: 'critical', title: "Synthetic checkout failed at: {$step}", body: $e->getMessage()); } } } Текущий стек мониторингаPrometheus — сбор метрик Grafana — визуализация и алертинг Loki — агрегация логов Alertmanager — маршрутизация (Telegram, PagerDuty, Slack) Synthetic monitoring — CI4 CLI команды в cron OpenTelemetry + Jaeger — distributed tracing MTTR за год: Период MTTR До нормального мониторинга 47 минут После 8 минут Это не просто красивая цифра. Это живые деньги. Мониторинг — это бизнес-инвестиция с прямым ROI. 📈
-
Когда PHP 8.0 вышел с JIT-компилятором, интернет взорвался. "PHP теперь БЫСТРЕЕ Python!" "JIT изменит всё!" "Переписывайте на PHP!". Заголовки были прекрасны. Реальность — немного иначе. Я потратил месяц на бенчмарки JIT в нашем реальном highload-проекте на PHP 8.3 + CodeIgniter 4.6. Расскажу что нашёл. Без маркетинга, только цифры и контекст. Немного теории (обещаю, коротко)JIT (Just-In-Time compilation) — это компиляция горячего кода в нативные машинные инструкции во время выполнения. В отличие от OPcache, который кэширует opcode (байткод PHP), JIT генерирует настоящий машинный код. PHP реализует два режима JIT: Tracing JIT (jit=tracing) — анализирует трассы выполнения, оптимизирует горячие пути. Лучше для численных вычислений. Function JIT (jit=function) — компилирует целые функции. Более предсказуемый, но менее агрессивный. Конфигурация в php.ini: [opcache] opcache.enable=1 opcache.jit=tracing opcache.jit_buffer_size=256M opcache.jit_hot_loop=64 opcache.jit_hot_func=127 opcache.jit_hot_return=8 opcache.jit_hot_side_exit=8 Бенчмарк 1: Мандельброт (классика)function mandelbrot(float $x0, float $y0): int { $x = 0.0; $y = 0.0; $iteration = 0; $maxIteration = 1000; while ($x * $x + $y * $y <= 4.0 && $iteration < $maxIteration) { $xTemp = $x * $x - $y * $y + $x0; $y = 2.0 * $x * $y + $y0; $x = $xTemp; $iteration++; } return $iteration; } Результаты: Конфигурация Время PHP 8.3, OPcache off 8.43s PHP 8.3, OPcache on, JIT off 4.21s PHP 8.3, OPcache on, JIT tracing 0.84s PHP 8.3, OPcache on, JIT function 1.12s JIT Tracing ускорил Мандельброт в 5 раз. Потрясающий результат! Но кто в вашем web-приложении считает Мандельброт? Бенчмарк 2: Реальный CI4 requestРезультаты на типичном API endpoint (среднее по 10,000 запросов): Конфигурация Среднее время P99 OPcache on, JIT off 42.3ms 89ms OPcache on, JIT tracing 41.8ms 87ms OPcache on, JIT function 42.1ms 88ms Разница: 1.2%. Это в пределах погрешности измерений. Почему JIT не помогает веб-приложениямТипичный PHP web-request проводит время примерно так: ~45% — ожидание БД (I/O bound) ~25% — сетевые операции (Redis, внешние API) ~15% — OPcache-оптимизированный PHP-код ~10% — сериализация/десериализация (JSON, etc.) ~5% — собственно бизнес-логика с вычислениями JIT помогает именно с CPU-bound вычислениями. Но в web-запросе CPU-bound части — это ~20% от общего времени. Максимальное теоретическое ускорение: 16%. На практике — 1-3%. Правильная конфигурация для highload CI4[opcache] opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=256 opcache.interned_strings_buffer=32 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0 ; В prod — ВСЕГДА 0 opcache.save_comments=1 ; CI4 использует атрибуты opcache.preload=/var/www/app/preload.php opcache.preload_user=www-data opcache.jit=tracing opcache.jit_buffer_size=128M opcache.jit_hot_loop=64 opcache.jit_hot_func=127 И обязательно — preload для CI4: <?php // preload.php $preloadClasses = [ \App\Models\UserModel::class, \App\Models\ProductModel::class, \App\Libraries\Cache\ResilientCacheService::class, \App\Services\AuthService::class, // ... топ-50 самых используемых классов ]; foreach ($preloadClasses as $class) { if (class_exists($class)) { opcache_compile_file((new \ReflectionClass($class))->getFileName()); } } С preload время ответа на первые запросы после деплоя сократилось с 200ms до 45ms. Это важнее JIT. Итог: стоит ли включать JIT?Включайте, если: У вас PHP 8.1+ (в 8.0 JIT был сыроват) Есть CPU-bound операции (обработка данных, вычисления) Достаточно памяти для JIT buffer Не ждите чудес, если: Приложение I/O-bound (БД, Redis, внешние API) Это стандартное CRUD web-приложение Надеетесь что JIT заменит оптимизацию запросов Прежде чем думать о JIT, убедитесь что правильно настроен OPcache, нет N+1 запросов, есть кэширование и нормальные индексы в БД. Это даст 10-100× ускорение. JIT — ещё 1-5% сверху. Но 5% при 10 миллионах запросов в сутки — тоже деньги. Поэтому включайте. Просто знайте зачем. 📊
-
Это не та история, которой гордятся. Это история, которую рассказывают тихо, за пивом, другим DevOps'ам — чтобы они не совершили те же ошибки. Но знаете что? Я решил рассказать её громко. Потому что честность важнее репутации, а реальные истории учат лучше, чем придуманные кейсы. Black Friday. Наш e-commerce на CI4. Трафик × 15 от обычного. Что могло пойти не так? Спойлер: всё. Подготовка (которой, как оказалось, было недостаточно)За три недели до BF мы провели "подготовку". По тем временам нам казалось, что мы сделали всё правильно: ✅ Провели нагрузочный тест на 5× нормального трафика ✅ Настроили автомасштабирование k8s ✅ Прогрели CDN-кэш для статики ✅ Оптимизировали топ-20 медленных запросов ✅ Увеличили connection pool MySQL ✅ Настроили алерты Что мы не сделали (и о чём потом пожалели): ❌ Не протестировали 15× трафика (только 5×) ❌ Не протестировали scenario с высоким числом одновременных checkout операций ❌ Не проверили поведение при частичном отказе зависимостей ❌ Не подготовили runbook для дежурной команды Хронология событий00:00 — Midnight madness старт Трафик начал расти в 23:45. К полуночи — ×4 от нормы. Всё отлично, k8s масштабируется, метрики в норме, team в Teams чатится позитивно. 00:23 — Первый звонок 🔴 ALERT: Checkout error rate > 5% 5% checkout'ов не проходят. Это много. Начинаем копать. В логах: Deadlock found when trying to get lock; try restarting transaction MySQL deadlock. Два процесса пытались обновить одну и ту же запись в таблице inventory (остатки товаров) одновременно. При ×4 трафике вероятность коллизии выросла критически. Быстрое решение: добавили SELECT ... FOR UPDATE с retry-логикой: public function decrementStock(int $productId, int $quantity): bool { $maxRetries = 3; $retryDelay = 100; // ms for ($attempt = 1; $attempt <= $maxRetries; $attempt++) { $this->db->transStart(); try { $product = $this->db ->table('inventory') ->where('product_id', $productId) ->lockForUpdate() ->get() ->getRowArray(); if ($product['stock'] < $quantity) { $this->db->transRollback(); return false; } $this->db->table('inventory') ->where('product_id', $productId) ->update(['stock' => $product['stock'] - $quantity]); $this->db->transCommit(); return true; } catch (\Exception $e) { $this->db->transRollback(); if ($attempt < $maxRetries && str_contains($e->getMessage(), 'Deadlock')) { usleep($retryDelay * 1000 * $attempt); continue; } throw $e; } } return false; } Деплой. Прошло. Продолжаем. 01:47 — Главное событие 🔴 CRITICAL: Database primary unreachable 🔴 CRITICAL: All checkout endpoints down 🔴 CRITICAL: Payment service timeout MySQL primary упал. Не лёг — упал. Полностью. Причина выяснилась позже: диск заполнился из-за бинарных логов (binary log retention не был настроен для ситуации с × 15 write операциями). df -h /var/lib/mysql # Filesystem: 100% used (512GB / 512GB) 512 гигабайт. Всё. Диск кончился. MySQL не может писать — MySQL падает. Элегантно, ничего не скажешь. Автоматический failover сработал — реплика стала primary. Это заняло 23 секунды. 23 секунды — 100% ошибок на checkout. При трафике BF это $147,000 потерянной выручки. За двадцать три секунды. Затем выяснилось: наша реплика не была настроена на роль primary. У неё не было некоторых критических stored procedures. Checkout стал работать, но с ошибками 15%. Следующие 40 минут команда в поту накатывала stored procedures на новый primary, чистила binlogs на упавшем сервере (он был ещё нужен), настраивала новую репликацию. 02:47 — Всё относительно стабильно Error rate 2.3%. Для BF — терпимо, но не хорошо. 04:15 — Redis OOM OOM command not allowed when used memory > 'maxmemory' Redis закончил память. Eviction policy была noeviction — вместо того чтобы выкидывать старые ключи, Redis начал отклонять все write-операции. Приложение посыпалось. Быстрый фикс: redis-cli CONFIG SET maxmemory-policy allkeys-lru LRU eviction включён. Redis начал вытеснять старые ключи. Кэш-хиты упали с 94% до 61%, нагрузка на MySQL снова выросла, но хотя бы приложение работало. Постмортем: что пошло не такПричина 1: Мы не тестировали реальный сценарий Нагрузочный тест в ×5 — это не BF при ×15. Мы протестировали "всё нормально", а не "всё горит". Нужно было делать chaos testing: убивать primary во время нагрузки, заполнять диск, устраивать OOM Redis. Причина 2: MySQL binlog retention -- Должно быть настроено! SET GLOBAL binlog_expire_logs_seconds = 86400; -- 24 часа Это одна строчка. ОДНА. И она бы предотвратила заполнение диска. Причина 3: Replica не была готова к роли primary Наша "репликация" была настроена для read scaling, а не для failover. Stored procedures, triggers, специфичные настройки — ничего из этого не дублировалось. Это фундаментальная ошибка в архитектуре HA. Причина 4: Redis maxmemory-policy noeviction Кто-то (я) настроил noeviction "чтобы данные не терялись". Логика благородная. Результат катастрофический. В production eviction лучше, чем полный отказ сервиса. Что изменилось после1. GameDay — обязательная практика Раз в квартал мы проводим "день катастрофы": специально ломаем production-like окружение и смотрим как команда реагирует. Сценарии: упал primary MySQL, заполнился диск, OOM Redis, одна нода k8s недоступна. 2. Runbook для каждого critical alert Каждый алерт в PagerDuty теперь ссылается на confluence-страницу с пошаговым runbook. Дежурный не должен думать — он должен читать и выполнять. 3. Pre-BF чеклист # Automated pre-event checks ./scripts/pre-event-check.sh # Checks: # ✓ MySQL disk usage < 50% # ✓ Binlog retention configured # ✓ Redis maxmemory-policy = allkeys-lru # ✓ Replica can promote to primary (stored procs present) # ✓ HPA max replicas sufficient # ✓ CDN cache warm # ✓ All alerts configured and tested # ✓ On-call rotation confirmed # ✓ Rollback plan documented Финансовые итогиОбщие потери от инцидентов BF: ~$230,000 (прямые потери выручки + компенсации + репутационный ущерб). Следующий год, после всех изменений: BF прошёл без единого critical инцидента. Error rate — 0.08%. Выручка выросла на 340% по сравнению с прошлым BF. Цена нормальной подготовки: 3 недели работы команды + $15,000 на gameday инфраструктуру. Разница: 230,000 vs 15,000. Выбор очевиден. Делитесь похожими историями — на ithub.uno такие postmortem'ы читают и обсуждают живее всего. Потому что в них — настоящий опыт. 💀➡️🧠
-
Есть проблемы, о которых говорят на каждой конференции, пишут в каждом учебнике и которые всё равно продолжают жить в каждом втором продакшн-проекте. N+1 — именно такая. Это как тараканы: знаешь о них, ведёшь с ними борьбу, думаешь что победил — а потом открываешь новый модуль и привет. Сегодня расскажу про реальный кейс из нашего highload-проекта на PHP 8.2 + CodeIgniter 4. И покажу, как мы с этим боролись системно, а не точечными заплатками. Что такое N+1 на практикеТеория все знают. Загружаешь список из N объектов, потом для каждого делаешь ещё один запрос. Итого 1 + N запросов вместо 1-2. При N=100 это 101 запрос вместо 2. Ничего страшного, да? Нет. Вот реальный пример из нашего кода. Страница со списком заказов: // OrderModel.php — выглядит невинно public function getOrdersList(int $page = 1): array { $orders = $this->paginate(50); foreach ($orders as &$order) { // Запрос #1 ... #50: грузим пользователя $order['user'] = model('UserModel')->find($order['user_id']); // Запрос #51 ... #100: грузим товары заказа $order['items'] = model('OrderItemModel') ->where('order_id', $order['id']) ->findAll(); // Запрос #101 ... #150: грузим статус доставки $order['delivery'] = model('DeliveryModel') ->where('order_id', $order['id']) ->first(); } return $orders; } 50 заказов на странице. Итого: 1 (список) + 50 (пользователи) + 50 (товары) + 50 (доставка) = 151 запрос. На страницу. Которую открывают 500 раз в минуту. Итого 75,500 запросов в минуту только на эту одну страницу. MySQL рыдал. Тихо, но рыдал. Обнаружение: логирование запросов в CI4Первым шагом была инструментация. CI4 позволяет логировать все запросы через Toolbar, но в highload нам нужно что-то более production-ready. Мы написали EventSubscriber, который считает запросы на request: <?php namespace App\Subscribers; use CodeIgniter\Events\Events; class QueryCounterSubscriber { private static int $queryCount = 0; private static array $slowQueries = []; public static function register(): void { Events::on('DBQuery', [self::class, 'onQuery']); } public static function onQuery(\CodeIgniter\Database\Query $query): void { self::$queryCount++; $duration = $query->getDuration(6); if ($duration > 0.1) { // 100ms threshold self::$slowQueries[] = [ 'sql' => $query->getQuery(), 'duration' => $duration, 'trace' => debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 10), ]; } if (self::$queryCount > 50) { log_message('warning', sprintf( 'N+1 suspicion: %d queries for %s %s', self::$queryCount, service('request')->getMethod(), service('request')->getUri()->getPath() )); } } public static function getReport(): array { return [ 'total' => self::$queryCount, 'slow_queries' => self::$slowQueries, ]; } } Через неделю мы нашли 23 endpoint'а с N+1. Некоторые делали до 800 запросов за один HTTP request. Один из них — статистическая страница для администратора — делал 1,247 запросов. Нет, это не опечатка. Решение 1: Eager Loading через Query BuilderВ CI4 нет встроенного ORM с eager loading как в Laravel. Но это не повод делать N+1. Пишем вручную — это даже лучше, потому что контролируешь каждый запрос: <?php namespace App\Models; class OrderModel extends Model { public function getOrdersWithRelations(int $page = 1): array { // Запрос 1: список заказов $orders = $this->paginate(50); if (empty($orders)) { return []; } $orderIds = array_column($orders, 'id'); $userIds = array_unique(array_column($orders, 'user_id')); // Запрос 2: все пользователи одним запросом $users = model('UserModel') ->whereIn('id', $userIds) ->findAll(); $usersMap = array_column($users, null, 'id'); // Запрос 3: все товары заказов одним запросом $items = model('OrderItemModel') ->whereIn('order_id', $orderIds) ->findAll(); $itemsMap = []; foreach ($items as $item) { $itemsMap[$item['order_id']][] = $item; } // Запрос 4: вся доставка одним запросом $deliveries = model('DeliveryModel') ->whereIn('order_id', $orderIds) ->findAll(); $deliveriesMap = array_column($deliveries, null, 'order_id'); // Собираем результат в памяти foreach ($orders as &$order) { $order['user'] = $usersMap[$order['user_id']] ?? null; $order['items'] = $itemsMap[$order['id']] ?? []; $order['delivery'] = $deliveriesMap[$order['id']] ?? null; } return $orders; } } 151 запрос → 4 запроса. Время ответа страницы: с 3.2 секунды до 87 миллисекунд. Разница в 37 раз. Буквально изменением подхода к написанию одного метода. Решение 2: Автоматическое обнаружение в CI4 FilterЧтобы N+1 не возвращались незаметно, добавили Filter для development/staging: <?php namespace App\Filters; use CodeIgniter\Filters\FilterInterface; use CodeIgniter\HTTP\RequestInterface; use CodeIgniter\HTTP\ResponseInterface; class QueryAnalyzerFilter implements FilterInterface { private const WARNING_THRESHOLD = 30; private const ERROR_THRESHOLD = 100; public function before(RequestInterface $request, $arguments = null): void { QueryCounterSubscriber::reset(); } public function after( RequestInterface $request, ResponseInterface $response, $arguments = null ): ResponseInterface { $report = QueryCounterSubscriber::getReport(); $count = $report['total']; if ($count >= self::WARNING_THRESHOLD) { $level = $count >= self::ERROR_THRESHOLD ? 'error' : 'warning'; log_message($level, sprintf( '[QueryAnalyzer] %s %s: %d queries', $request->getMethod(), $request->getUri()->getPath(), $count )); if (ENVIRONMENT === 'development') { $response->setHeader('X-Query-Count', (string) $count); $response->setHeader('X-Query-Warning', $count >= self::ERROR_THRESHOLD ? 'N+1_DETECTED' : 'HIGH_QUERIES'); } } return $response; } } Теперь любой новый endpoint с N+1 автоматически логируется с уровнем error. Это попадает в наш ELK стек, алертинг срабатывает, приходит уведомление. Разработчик узнаёт о проблеме ещё на code review этапе, а не когда MySQL упал в прод. Цифры до и послеEndpoint Запросов ДО Запросов ПОСЛЕ Время ответа ДО Время ПОСЛЕ Список заказов 151 4 3200ms 87ms Профиль пользователя 89 3 1800ms 45ms Каталог товаров 347 5 8900ms 210ms Статистика 1247 12 31000ms 890ms Суммарная нагрузка на MySQL упала на 78%. Не шучу. Просто убрали N+1 — и почти вдвое освободили ресурсы БД. Главный выводN+1 — это не ошибка джуниоров. Это системная проблема, которая возникает когда нет инструментов для её обнаружения и нет культуры её предотвращения. Добавьте автоматическое логирование числа запросов. Сделайте Code Review check на паттерны N+1. И помните: каждый .find() внутри цикла — это потенциальная бомба. Удачи вашим базам данных. 🗄️
-
Прежде чем начать, хочу сказать одну важную вещь: я люблю Kubernetes. Искренне. Как любят сложного человека — за глубину, за то, что никогда не знаешь чего ожидать, за то, что каждый день чему-то учишься. И одновременно хочется иногда взять его и... ну, вы понимаете. Восемнадцать месяцев в продакшне с k8s. Сорок семь инцидентов в PagerDuty. Из них тридцать один — "это мы сами виноваты". Остальные шестнадцать — "это k8s виноват, но мы неправильно его настроили". Итого: сорок семь раз мы были виноваты сами. Добро пожаловать в правду. Начало: эйфорияМы переехали на k8s с bare-metal + ansible + systemd. По тем временам это был большой шаг. Наконец-то: декларативная конфигурация, автомасштабирование, rolling updates без даунтайма, самолечение. Красота! Первая неделя прошла в написании манифестов. Я писал их как поэт — вдохновенно, не жалея строк. YAML цвёл. Deployments, Services, ConfigMaps, Secrets, Ingress — всё было прекрасно. apiVersion: apps/v1 kind: Deployment metadata: name: php-app spec: replicas: 3 template: spec: containers: - name: php-fpm image: myapp:latest # ← вот здесь уже первая мина resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" image: myapp:latest — это первая из ошибок, которая позже стоила нам часа даунтайма. Тег latest — это зло. Это не версия, это "бог знает что". При следующем деплое k8s может подтянуть другой образ на разные ноды, и у вас будет кластер, где половина подов — старая версия, а половина — новая, и они несовместимы. Всегда используйте immutable теги: git sha, semver, timestamp. Всегда. Инцидент #7: OOMKiller приходит ночьюНаше PHP приложение — CI4 с тяжёлой бизнес-логикой. PHP-FPM воркеры потребляют память по-разному в зависимости от endpoint'а. Лёгкий API — 40MB. Тяжёлый отчёт — 380MB. Мы выставили limits.memory: 512Mi и думали, что этого хватит. Ночью запустился cron-джоб, который генерировал ежемесячные отчёты. Каждый воркер под отчёт — ~380MB. PHP-FPM с 8 воркерами = 3GB. Лимит пода — 512MB. OOMKilled Exit Code: 137 Под убит. k8s перезапускает. Новый под опять запускает отчёт. Опять OOMKilled. Restart loop. Кейс называется CrashLoopBackOff, и выглядит он в логах примерно так: pod/php-app-7d9f8c-xk2p9 0/1 CrashLoopBackOff 14 47m Четырнадцать рестартов за 47 минут. k8s упорно пытался поднять под, PHP упорно пытался сожрать память, OOMKiller упорно его убивал. Это было похоже на зомби-апокалипсис в миниатюре. Решение: разделение воркеров Мы разделили PHP-FPM на два пула: ; /etc/php-fpm.d/www.conf — общий пул [www] pm = dynamic pm.max_children = 20 pm.max_requests = 500 ; /etc/php-fpm.d/heavy.conf — пул для тяжёлых операций [heavy] pm = ondemand pm.max_children = 4 pm.max_requests = 50 pm.process_idle_timeout = 10s И создали отдельный Deployment для heavy-операций с увеличенными лимитами: # heavy-deployment.yaml resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "2000m" Nginx роутит по prefix: location /api/reports/ { fastcgi_pass heavy-php-fpm:9001; } location / { fastcgi_pass www-php-fpm:9000; } Элегантно? Не очень. Работает? Да. Инцидент #19: Liveness probe убивает продЭто был шедевр. Мы настроили liveness probe — k8s регулярно проверяет, жив ли под, и если нет — убивает и перезапускает: livenessProbe: httpGet: path: /health port: 80 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 Endpoint /health возвращал 200 и JSON со статусами всех зависимостей: Redis, MySQL, очередь. Казалось бы — отлично. И вот в один прекрасный день MySQL реплика начала лагать (проблема с дисками). Запросы к реплике стали занимать 15-20 секунд. Наш /health endpoint проверял реплику, таймаут probe — 5 секунд. Итог: Liveness probe failed: Get "http://10.244.2.5/health": context deadline exceeded k8s решил, что под нездоров. Убил его. Поднял новый. Новый тоже упёрся в лагающую реплику. Тоже убит. В какой-то момент k8s убивал поды быстрее, чем они успевали принять трафик. Мы устроили собственноручный DDoS на наш прод с помощью liveness probe. Это надо уметь. Решение: Разделили liveness и readiness: # Liveness: только "жив ли процесс" livenessProbe: httpGet: path: /health/live # Проверяет только PHP-FPM ping port: 80 initialDelaySeconds: 30 periodSeconds: 30 timeoutSeconds: 2 failureThreshold: 5 # Readiness: "готов ли принимать трафик" readinessProbe: httpGet: path: /health/ready # Проверяет все зависимости port: 80 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 // CI4 Controller class HealthController extends BaseController { public function live(): ResponseInterface { // Только базовая проверка процесса return $this->response->setJSON(['status' => 'ok']); } public function ready(): ResponseInterface { $checks = [ 'database' => $this->checkDatabase(), 'redis' => $this->checkRedis(), 'queue' => $this->checkQueue(), ]; $healthy = !in_array(false, $checks, true); return $this->response ->setStatusCode($healthy ? 200 : 503) ->setJSON([ 'status' => $healthy ? 'ready' : 'degraded', 'checks' => $checks, ]); } } Теперь при проблемах с репликой поды переставали получать трафик (readiness failed), но не убивались (liveness — ok). Через 20 минут реплика восстановилась, readiness снова позеленела, трафик вернулся. Без единой 500-й ошибки. Инцидент #31: HPA и смерть от масштабированияHorizontal Pod Autoscaler — прекрасная вещь. Трафик растёт — поды добавляются. Трафик падает — поды убираются. Автоматически. Без участия человека. Кроме случаев, когда всё идёт не так. Мы настроили HPA по CPU: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-app-hpa spec: minReplicas: 3 maxReplicas: 30 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 Ждём нагрузочного теста. Трафик растёт. HPA видит CPU 85% → добавляет поды. Новые поды стартуют, прогревают OPcache, пока прогреваются — CPU у них 90% → HPA добавляет ещё поды. Те тоже прогреваются → CPU опять высокий → ещё поды. Через 3 минуты у нас было 28 подов из максимальных 30. Они все одновременно прогревали OPcache, коннектились к MySQL, коннектились к Redis. MySQL задыхался от 28×20 = 560 новых соединений. Redis cluster не успевал. Прод лёг под весом собственного масштабирования. Решение: Добавить cooldown и stabilization: behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Pods value: 2 # Не более 2 подов за раз periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 Использовать custom metrics (RPS), а не CPU: metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "300" Добавить PHP-FPM warming в startup probe: startupProbe: httpGet: path: /warmup port: 80 failureThreshold: 30 periodSeconds: 5 Endpoint /warmup прогревал OPcache и пул соединений. Пока startupProbe не вернула 200 — под не получал трафик и не учитывался в метриках HPA. ПросветлениеПосле 18 месяцев и 47 инцидентов я пришёл к простому выводу: Kubernetes не упрощает жизнь. Он переносит сложность из "как запустить" в "как правильно настроить". И это совершенно другой уровень сложности — более тонкий, более коварный, и требующий понимания системы на глубоком уровне. Ключевые правила, которые я вколотил в стену рядом с рабочим столом: Никогда image:latest — только иммутабельные теги Liveness ≠ Readiness — это разные вещи с разной ценой ошибки Resource limits — это не потолок, это граница жизни и смерти пода HPA с CPU — ловушка для PHP. Используйте RPS или custom metrics Один под не значит один процесс — PHP-FPM это N воркеров Chaos engineering — убивайте поды намеренно, пока это не сделает production И последнее: k8s — это не серебряная пуля. Это мощный инструмент с огромным количеством движущихся частей. Уважайте его, изучайте, читайте исходники при необходимости. И обязательно найдите коммьюнити — на ithub.uno, на форумах, на конференциях. Потому что некоторые грабли лучше подбирать чужим лбом. До следующего CrashLoopBackOff. 🤕
-
Есть вещи, которые меняют тебя как специалиста. Первый деплой в прод. Первый incident report, который ты пишешь в 3 ночи. И первый раз, когда ты видишь в логах Redis: CLUSTERDOWN Hash slot not served. Вот это последнее — особенное. После такого начинаешь иначе смотреть на жизнь, на архитектуру и на документацию, которую ты "почти дочитал". Сегодня расскажу про Redis Cluster в highload-продакшне. Без прикрас, без маркетинговых буклетов. Только боль, инсайты и несколько команд, которые спасли мне карьеру. Контекст: зачем вообще Redis ClusterК тому моменту мы уже года полтора успешно жили на одном Redis-инстансе с репликой. Всё было хорошо: 50GB данных, ~80,000 ops/sec в пике, latency стабильно под 1ms. Идиллия. Потом случился бизнес. Нас купили, влили денег, пользователей стало в пять раз больше. Нагрузка выросла до 380,000 ops/sec. Один Redis задыхался. CPU на инстансе — 94% (Redis однопоточный в плане основного event loop, напоминаю). Latency поползла вверх — 8ms, 15ms, 40ms... Решение очевидное: Redis Cluster. Шардирование данных по hash slots (всего 16384 слота) на несколько нод. Я читал документацию. Я смотрел туториалы. Я думал, что готов. Я не был готов. Первая попытка: наивнаяПоднял кластер из 3 мастеров + 3 реплик. Конфигурация нод: redis1 (master) — слоты 0-5460 redis2 (master) — слоты 5461-10922 redis3 (master) — слоты 10923-16383 redis4 (replica) — реплицирует redis1 redis5 (replica) — реплицирует redis2 redis6 (replica) — реплицирует redis3 Всё прекрасно работало на стейджинге. В прод переехали ночью. Первые два часа — тишина и красивые графики. Потом началось. Наш код активно использовал MGET, MSET и пайплайны. И вот тут — сюрприз из документации, которую я "почти дочитал": в Redis Cluster мульти-ключевые операции работают только если все ключи находятся в одном hash slot. CROSSSLOT Keys in request don't hash to the same slot Это сообщение я запомнил навсегда. Потому что половина нашего кода сыпала им как из ведра. Погружение в hash tagsRedis Cluster использует CRC16 от имени ключа для определения слота. Но если в ключе есть фигурные скобки {}, то для вычисления слота используется только содержимое скобок — это называется hash tag. # Эти ключи попадут в РАЗНЫЕ слоты: user:1:profile → slot 7638 user:1:settings → slot 2892 user:1:cart → slot 6899 # А эти — в ОДИН, потому что hash tag {user:1}: {user:1}:profile → slot 7638 {user:1}:settings → slot 7638 {user:1}:cart → slot 7638 Казалось бы, просто добавить фигурные скобки и всё. Но у нас было 200+ мест в коде с генерацией ключей. И это был PHP-монолит, переписанный на CI4 модули. Кайф. Мы написали специальный класс-обёртку: <?php namespace App\Libraries\Cache; class ClusterAwareCacheKey { public static function userScoped(int $userId, string $suffix): string { return sprintf('{user:%d}:%s', $userId, $suffix); } public static function sessionScoped(string $sessionId, string $suffix): string { return sprintf('{session:%s}:%s', $sessionId, $suffix); } public static function globalKey(string $key): string { // Глобальные ключи не группируем — пусть шардируются равномерно return $key; } } И CI4 Cache Driver, который умеет работать с Cluster: <?php namespace App\Libraries\Cache; use CodeIgniter\Cache\Handlers\RedisHandler; class RedisClusterHandler extends RedisHandler { protected \RedisCluster $redis; public function initialize(): void { $config = config('Cache'); $this->redis = new \RedisCluster( null, $config->redisClusterNodes, $config->redisTimeout, $config->redisReadTimeout, true, // persistent $config->redisAuth ); $this->redis->setOption(\Redis::OPT_SERIALIZER, \Redis::SERIALIZER_IGBINARY); } public function getMultiple(array $keys, mixed $default = null): array { // Группируем ключи по слотам для batch-операций $slotGroups = $this->groupBySlot($keys); $result = []; foreach ($slotGroups as $slotKeys) { $values = $this->redis->mget($slotKeys); foreach ($slotKeys as $i => $key) { $result[$key] = $values[$i] !== false ? $this->unserialize($values[$i]) : $default; } } return $result; } private function groupBySlot(array $keys): array { $groups = []; foreach ($keys as $key) { $slot = $this->calculateSlot($key); $groups[$slot][] = $key; } return array_values($groups); } private function calculateSlot(string $key): int { // Извлекаем hash tag если есть if (preg_match('/\{([^}]+)\}/', $key, $matches)) { $key = $matches[1]; } return crc32($key) & 0x3FFF; // 16384 слота } } Второй уровень ада: failoverМы починили CROSSSLOT. Живём. Счастливы. Три недели тишины. Потом у нас умер сервер. Не виртуалка, не под — физический сервер. Просто взял и умер в 14:22 в среду. На нём жили redis2 (мастер) и redis5 (реплика redis1, то есть другого мастера). Вот тут начался настоящий thriller. Redis Cluster должен автоматически делать failover: реплика замечает, что мастер недоступен, объявляет выборы, становится новым мастером. Это работает. Но есть нюанс, который я знал теоретически и совершенно недооценил практически. Время failover — от 15 до 30 секунд. Пятнадцать секунд, в течение которых слоты 5461-10922 не обслуживаются. При 380,000 ops/sec. Можете себе представить, как выглядел error rate в эти 15 секунд? Error rate: 0.1% → 34% → 67% → 89% → 67% → 12% → 0.3% Наш PHP-код в CI4 при ошибке Redis просто падал с exception. Никакого graceful degradation. Никакого fallback на БД. Просто 500-е ответы. Вот это был момент просветления. Решение: Circuit Breaker для RedisМы реализовали паттерн Circuit Breaker специально для Redis. В CI4 это элегантно делается через Service Container: <?php namespace App\Libraries\Cache; class ResilientCacheService { private const FAILURE_THRESHOLD = 5; private const RECOVERY_TIMEOUT = 30; private const HALF_OPEN_MAX_CALLS = 3; private string $state = 'closed'; // closed | open | half-open private int $failureCount = 0; private int $lastFailureTime = 0; private int $halfOpenCalls = 0; public function __construct( private readonly RedisClusterHandler $redis, private readonly \CodeIgniter\Cache\CacheInterface $fallback ) {} public function get(string $key, mixed $default = null): mixed { if ($this->isOpen()) { return $this->fallback->get($key, $default); } try { $value = $this->redis->get($key); $this->onSuccess(); return $value ?? $default; } catch (\Throwable $e) { $this->onFailure($e); return $this->fallback->get($key, $default); } } public function set(string $key, mixed $value, int $ttl = 0): bool { if ($this->isOpen()) { return $this->fallback->set($key, $value, $ttl); } try { $result = $this->redis->save($key, $value, $ttl); $this->onSuccess(); return $result; } catch (\Throwable $e) { $this->onFailure($e); return $this->fallback->set($key, $value, $ttl); } } private function isOpen(): bool { if ($this->state === 'open') { if (time() - $this->lastFailureTime > self::RECOVERY_TIMEOUT) { $this->state = 'half-open'; $this->halfOpenCalls = 0; return false; } return true; } return false; } private function onSuccess(): void { if ($this->state === 'half-open') { $this->halfOpenCalls++; if ($this->halfOpenCalls >= self::HALF_OPEN_MAX_CALLS) { $this->state = 'closed'; $this->failureCount = 0; } } elseif ($this->state === 'closed') { $this->failureCount = max(0, $this->failureCount - 1); } } private function onFailure(\Throwable $e): void { $this->lastFailureTime = time(); $this->failureCount++; if ($this->state === 'half-open' || $this->failureCount >= self::FAILURE_THRESHOLD) { $this->state = 'open'; log_message('critical', 'Redis Circuit Breaker OPEN: ' . $e->getMessage()); } } } Регистрируем в Services: // app/Config/Services.php public static function resilientCache(bool $getShared = true): ResilientCacheService { if ($getShared) { return static::getSharedInstance('resilientCache'); } return new ResilientCacheService( new RedisClusterHandler(), new FileHandler() // filesystem как fallback ); } Теперь при падении Redis кластера приложение продолжало работать — медленнее, с filesystem кэшем, но без 500-х ошибок. Error rate во время следующего (учинённого намеренно!) failover теста: 0.8%. Против 89% до. Третий круг: Memory fragmentationЭто тихий убийца. Redis работает, данные записываются и читаются, но потихоньку mem_fragmentation_ratio ползёт вверх. redis-cli --cluster call all-nodes INFO memory | grep mem_fragmentation_ratio Через полгода работы я увидел значение 2.47. Норма — от 1.0 до 1.5. Значение 2.47 означает, что Redis использует в 2.47 раза больше памяти, чем реально нужно для данных. На наших 80GB инстансах это ~50GB впустую. Причина — интенсивные операции записи/удаления ключей с разным TTL, что приводит к фрагментации heap у jemalloc. Решение — Active defragmentation: redis-cli CONFIG SET activedefrag yes redis-cli CONFIG SET active-defrag-ignore-bytes 100mb redis-cli CONFIG SET active-defrag-threshold-lower 10 redis-cli CONFIG SET active-defrag-threshold-upper 100 redis-cli CONFIG SET active-defrag-cycle-min 25 redis-cli CONFIG SET active-defrag-cycle-max 75 Через сутки mem_fragmentation_ratio опустился до 1.18. Мы вернули ~45GB памяти. Без перезапуска. В прод. Итог и выводыRedis Cluster — мощнейший инструмент, но он требует понимания на уровне "читал исходники, а не только README". Мои главные уроки: Hash tags планируйте заранее, не когда уже CROSSSLOT в логах Failover длится 15-30 секунд — ваш код должен это переживать Circuit Breaker — обязательный паттерн, не опциональный Мониторьте mem_fragmentation_ratio — без этого потеряете память Multi-key операции — только в одном слоте — это не баг, это дизайн Latency в cluster выше, чем в standalone — заложите это в SLA Если вы тоже занимаетесь highload и Redis — заходите на ithub.uno, там есть живые обсуждения именно таких кейсов. Без теории ради теории, только production experience. Удачи с кластерами. И пусть ваши слоты всегда будут served. 🔴✅
-
Привет, коллеги по несчастью. Меня зовут Максим, я продуктовый DevOps с десятью годами шрамов на психике и подгоревшим нервным окончанием там, где у нормальных людей находится чувство покоя. Сегодня я расскажу вам историю, которую в каждой IT-компании мира знают наизусть, но всё равно каждый раз проживают как первый раз. Историю о том, как прод падает именно тогда, когда тебе это меньше всего нужно. Итак. Декабрь. Пятница. Мы только что задеплоили «маленький hotfix» — ну там, буквально пять строчек, ничего серьёзного. Я уже мысленно дома, уже открываю холодильник, уже слышу шипение открываемой банки. И тут — дзынь. Алерт в Telegram. Потом ещё один. Потом ещё пять. Потом просто поток, как будто кто-то открыл кран с тревогами. 🔴 CRITICAL: Response time > 30s 🔴 CRITICAL: Error rate 78% 🔴 CRITICAL: Database connections exhausted 🔴 CRITICAL: Redis timeout 🔴 CRITICAL: Payment service unreachable Пять алертов за 40 секунд. Это рекорд, кстати. Я горжусь. Анатомия катастрофыТеперь давайте по-серьёзному, потому что случай был действительно интересный с технической точки зрения, и на ithub.uno такие постморtem-разборы ценятся. Итак, что мы имели на тот момент: Стек: PHP 8.2, CodeIgniter 4.5, MySQL 8.0 (кластер primary + 2 replica), Redis 7.0 Cluster, Nginx, всё это добро в k8s на трёх нодах Трафик: ~3500 RPS в пике, средний — около 800 RPS Hotfix: изменили одну строчку в модели, которая отвечала за выборку пользовательских настроек Что могло пойти не так? Всё. Абсолютно всё. Первое, что я сделал — зашёл на Grafana. Там картина маслом: RPS упал с 800 до 120, латентность взлетела с 80ms до 28 секунд (ДВАДЦАТИ ВОСЬМИ, Карл!), количество активных connections к MySQL упёрлось в потолок — 500/500, CPU на всех подах — 95%+. Классический симптом. Я такое уже видел. Это называется «connection pool exhaustion» в сочетании с «slow query лавиной». Но причина была нетривиальной. КопаемПервым делом — slow query log на MySQL: SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.1; Через 30 секунд смотрю лог и вижу: SELECT u.*, us.*, p.*, pr.*, c.* FROM users u LEFT JOIN user_settings us ON us.user_id = u.id LEFT JOIN profiles p ON p.user_id = u.id LEFT JOIN preferences pr ON pr.user_id = u.id LEFT JOIN cart c ON c.user_id = u.id AND c.status = 'active' WHERE u.id = 12345 Запрос сам по себе несложный. Выполняется за 0.003 секунды. Но... EXPLAIN показывает Using temporary; Using filesort на таблице cart. И вот тут начинается детективная история. Дело в том, что за час до деплоя наш аналитик (земля ему пухом) запустил миграцию, которая добавила в таблицу cart новое поле meta_json TEXT. При этом индекс idx_cart_user_status не пересоздавался. Он просто... перестал эффективно работать после изменения статистики таблицы. MySQL решил, что full scan выгоднее. При этом таблица cart содержала 47 миллионов строк. А наш «маленький hotfix»? Он убрал кэширование этого запроса. Буквально одну строку: // Было: return cache()->remember('user_data_' . $userId, 300, fn() => $this->buildUserData($userId)); // Стало (hotfix убрал кэш "для дебага"): return $this->buildUserData($userId); И вот оно. Идеальный шторм. Медленный запрос × отсутствие кэша × высокий трафик = прод в нокауте. Решение в боевых условияхВремени на красивые решения нет. Алгоритм действий: Шаг 1: Feature flag У нас есть система feature flags на Redis. Мгновенно включаю maintenance mode для новых пользователей, пропуская залогиненных: // CI4 Filter class MaintenanceFilter implements FilterInterface { public function before(RequestInterface $request, $arguments = null) { if (cache()->get('maintenance_mode') && !auth()->check()) { return redirect()->to('/maintenance'); } } } Трафик упал на 40%. Дышим. Шаг 2: Откат kubectl rollout undo deployment/app --to-revision=15 Это не решение проблемы с индексом, но снимает острую боль — кэш вернулся, запросы снова летают. Шаг 3: Экстренное создание индекса Пока прод восстанавливается, параллельно: -- На реплике сначала тестируем CREATE INDEX idx_cart_user_status_new ON cart(user_id, status) INCLUDE (id, created_at, meta_json) ALGORITHM=INPLACE, LOCK=NONE; ALGORITHM=INPLACE, LOCK=NONE — это не просто красивые слова. На таблице в 47 миллионов строк это разница между «индекс создаётся 4 минуты без локов» и «БД заблокирована на 25 минут, прощайте». Через 6 минут индекс на реплике. Тестируем — запрос летает за 1.2ms. Прогоняем на primary. Ещё 4 минуты. Готово. Шаг 4: Хотфикс хотфикса return cache()->remember('user_data_' . $userId, 300, fn() => $this->buildUserData($userId)); Да, просто вернули строку обратно. Иногда лучшее решение — отмотать назад. Постмортем и урокиЧерез два дня я провёл постмортем. Вот ключевые выводы, которые я теперь вколачиваю в голову каждому новому разработчику: 1. Никогда не убирайте кэш "для дебага" в прод Это как снять шлем "чтобы лучше видеть". Дебажьте на стейджинге. Там специально и создано это место. 2. Любая миграция схемы БД требует аудита индексов Мы внедрили правило: к каждому PR с миграцией прилагается EXPLAIN до и после на production-like данных (у нас есть анонимизированный дамп). 3. Алерты должны быть actionable Пять одновременных алертов — это не пять проблем. Это одна проблема с пятью симптомами. Мы перенастроили alertmanager с группировкой и подавлением дублей. 4. Connection pool — ваш первый друг и первый враг В CI4 мы теперь явно конфигурируем пул: // app/Config/Database.php public array $default = [ 'DBDriver' => 'MySQLi', 'hostname' => env('DB_HOST'), 'pconnect' => false, // persistent connections OFF в highload! 'DBDebug' => false, // ... ]; Persistent connections в highload — это бомба замедленного действия. Отключайте. 5. Chaos engineering — не роскошь, а необходимость После этого инцидента мы раз в квартал намеренно убиваем случайный под в прод-кластере. Да, в проде. Нет, это не безумие — это единственный способ убедиться, что система действительно resilient. ФиналВ 01:23 прод поднялся полностью. Показатели вернулись к норме. Я наконец открыл ту банку. Она была тёплой. Но знаете что? Этот инцидент стоил нам примерно $4,000 потерянной выручки и несколько седых волос. Зато мы получили бесценный опыт и полностью переработали процесс деплоя. Теперь у нас есть автоматическая проверка slow queries перед каждым деплоем, обязательный review индексов при миграциях и — самое главное — правило: никаких деплоев в пятницу после 18:00. Это правило нарушают только те, кто ещё не прожил свою первую пятничную аварию. После первой — никогда.
-
-
-
Рады сообщить ,что мы сделали группу в Телеграмм, с топиками ботами и прочими приколюхами))) Заходи и подписывайся в ТГ
-
Introduction: Why SysVinit Died and What Systemd FixedImagine a chef cooking dinner for 10 guests but making each dish completely from scratch, one at a time — starting the salad only after the soup is fully served. That's essentially how SysVinit worked: it started services one by one, in a fixed order, regardless of whether they were actually dependent on each other. As Linux systems grew more complex, this became a serious bottleneck: Slow boot times. Service A waits for Service B to finish, even if there's zero dependency between them. No process tracking. Init launched a script and moved on. A child process crashed? SysVinit had no idea. Log chaos. Every service wrote logs wherever it wanted — /var/log/nginx/, syslog, /tmp/ — no unified interface. Brittle shell scripts. The /etc/init.d/ scripts were fragile, hard to maintain, and inconsistent across distros. In 2010, Lennart Poettering introduced systemd to solve all of these problems simultaneously: parallel startup, dependency graphs, control groups, and centralized logging. The community response was controversial (to put it mildly), but today systemd is the de-facto standard on Fedora, Debian, Ubuntu, Arch, RHEL, and most other major distributions. Let's break it down piece by piece. Part 1. Systemd Architecture — What's Under the Hood1.1 PID 1 — The Ruler of All ProcessesWhen the Linux kernel boots, it launches the very first user-space process with PID 1. On systemd systems, that process IS the systemd daemon. It's the direct parent of everything else in the system. This matters for two reasons: If PID 1 crashes, the system panics. Hence systemd is written to be extremely robust. All orphaned processes (whose parent died) are automatically reparented to PID 1. Linux Kernel └── systemd (PID 1) ├── journald (logging) ├── udevd (device management) ├── networkd (networking) ├── nginx.service (your web server) ├── postgresql.service (database) └── ... all other services1.2 Key Componentssystemd (PID 1) The conductor of the whole orchestra. It reads unit files, builds a dependency graph, launches processes in the right order, and tracks them via cgroups. systemctl Your control panel. When you type systemctl start nginx, this tool does NOT start nginx directly. It sends a D-Bus message to the systemd daemon, which does the actual work. This is a fundamental difference from running a script. journald Centralized logging daemon. It captures stdout and stderr from all services, enriches each entry with structured metadata (PID, UID, unit name, hostname), and stores everything in a binary format that supports complex queries — think SQL for logs. udevd Device manager. When you plug in a USB drive, udevd creates /dev/sdb, loads the appropriate kernel modules, and can trigger specific services. networkd, timedated, logind Specialized daemons for network management, system time, and user sessions. They all communicate with PID 1 via D-Bus. 1.3 D-Bus — The Communication BackboneD-Bus is an inter-process communication (IPC) system bus — think of it as an internal messaging platform between processes. Instead of processes calling each other's functions directly (which is unsafe), they send structured messages through the bus. Example flow for systemctl start nginx: systemctl forms a D-Bus message: "Call the StartUnit method with argument nginx.service" The message goes onto the system bus The systemd daemon receives and processes it Returns the result through the same bus This provides security (permissions checked at the D-Bus level), flexibility (any program can manage services), and extensibility. Part 2. Units — The Building Blocks of SystemdA unit is a description of any system resource as a declarative configuration file. Think of it as the "passport" for a service, socket, timer, or mount point. 2.1 Where Units LivePath Purpose Priority /usr/lib/systemd/system/ Units installed by package manager Lowest /etc/systemd/system/ Your custom units and overrides High /run/systemd/system/ Temporary units (gone after reboot) Highest 2.2 Unit Types.service — Service Units (Most Common)Describes a daemon or process. This is what you'll use in 90% of cases. ini # /etc/systemd/system/myapp.service [Unit] Description=My Awesome Application After=network.target postgresql.service Requires=postgresql.service [Service] Type=simple ExecStart=/usr/bin/myapp --config /etc/myapp/config.yml ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5s User=myapp Group=myapp [Install] WantedBy=multi-user.targetThe Type= parameter — get this right: Type Behavior When to Use simple Service is considered started immediately after ExecStart launches Most modern applications forking Program calls fork() and the parent exits. Systemd waits for this. Classic Unix daemons (nginx, apache) notify Program signals systemd via sd_notify() when ready Programs with native systemd API support oneshot Program runs and exits. Systemd waits for completion. Scripts, one-off tasks dbus Service is considered started when it claims a D-Bus name Daemons using D-Bus idle Start delayed until all other jobs complete Low-priority background tasks Restart policy: ini [Service] # Restart= options: # no — never restart # on-success — only on exit code 0 # on-failure — on non-zero exit, signal, or timeout (most common choice) # on-abnormal — on signal or timeout (not normal exit) # always — always restart (even after systemctl stop!) Restart=on-failure RestartSec=5s # Limit restart attempts: # Max 5 attempts within 30 seconds, then give up StartLimitIntervalSec=30s StartLimitBurst=5.socket — Socket-Based Activation (Lazy Launch)This is one of the most powerful and underappreciated features of systemd. The idea: why keep 20 services running when most of them get called once an hour? Socket-based activation works like this: systemd opens and listens on a socket (port, Unix socket, or FIFO) The actual service is not running The first connection arrives systemd launches the service and passes the established connection to it The client never notices — the connection isn't lost! ini # /etc/systemd/system/echo.socket [Unit] Description=Echo Server Socket [Socket] ListenStream=12345 Accept=no [Install] WantedBy=sockets.targetini # /etc/systemd/system/echo.service [Unit] Description=Echo Server [Service] Type=simple ExecStart=/usr/local/bin/echo-server # Service receives the socket via file descriptor 3 StandardInput=socketEnable: sudo systemctl enable --now echo.socket — and the service starts on the first connection. .timer — Cron Replacement with SuperpowersSystemd timers beat cron on several fronts: Support dependencies (run only if some service is running) Logged in journald like any other unit Can "catch up" on missed runs after reboot (Persistent=true) Support random delays to spread load across the hour ini # /etc/systemd/system/backup.timer [Unit] Description=Daily Backup Timer [Timer] # Run every day at 02:30 OnCalendar=*-*-* 02:30:00 # Random delay up to 10 minutes (don't hammer the server at exactly 02:30!) RandomizedDelaySec=10m # Run the task if it was missed (e.g. system was off) Persistent=true [Install] WantedBy=timers.targetini # /etc/systemd/system/backup.service [Unit] Description=Daily Backup Job [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh User=backupEnable: sudo systemctl enable --now backup.timer Check all active timers: systemctl list-timers --all OnCalendar syntax cheatsheet: Expression Meaning daily Every day at 00:00 weekly Every Monday at 00:00 monthly 1st of every month *-*-* 09:00:00 Every day at 09:00 Mon-Fri *-*-* 08:30:00 Weekdays at 08:30 *-*-1,15 00:00:00 1st and 15th of every month Validate an expression: systemd-analyze calendar "Mon-Fri *-*-* 08:30:00" .target — Unit Groups (Replacing Runlevels)A target is not a service — it's a synchronization point. Think of it as a "system state" to be reached. Target SysV Runlevel Meaning poweroff.target 0 Shutdown rescue.target 1 Single-user mode multi-user.target 3 Multi-user, no GUI graphical.target 5 With graphical interface reboot.target 6 Reboot bash # Check current default target (like current runlevel) systemctl get-default # Switch target (like init 3) sudo systemctl isolate multi-user.target # Set default target sudo systemctl set-default multi-user.target2.3 Unit Dependencies — A Graph, Not a QueueThis is one of the key differentiators from SysVinit. Instead of a fixed sequence, systemd builds a directed dependency graph. Dependency directives: Directive Type Behavior Requires= Hard If the dependency fails to start, this unit also fails and stops with it Wants= Soft Tries to start the dependency, but won't stop if it fails BindsTo= Very hard Like Requires, but this unit stops whenever the dependency stops PartOf= One-way Stops/restarts together with the dependency, but doesn't start with it Conflicts= Conflict Cannot run simultaneously with the specified unit Ordering directives: Directive Behavior After= This unit starts AFTER the specified one Before= This unit starts BEFORE the specified one Part 3. cgroups — Why Systemd Always Knows Your Processes3.1 The Problem cgroups SolveConsider: nginx is running. It forks 4 workers. One worker forks a CGI process. That forks something else. Now there are 10 processes, all "belonging" to nginx, but in SysVinit there was no way to track this. Control Groups (cgroups) are a Linux kernel mechanism that lets you group processes hierarchically and manage them collectively. Systemd automatically creates a cgroup for every service. All child processes live inside that group. Always. /sys/fs/cgroup/ ├── system.slice/ │ ├── nginx.service/ ← all nginx processes here │ │ ├── pid: 1234 (master) │ │ ├── pid: 1235 (worker 1) │ │ ├── pid: 1236 (worker 2) │ │ └── pid: 1237 (cache loader) │ ├── postgresql.service/ │ └── redis.service/ └── user.slice/ └── user-1000.slice/ ← user processes3.2 What cgroups Give You in PracticeClean process termination — no zombie processes: When you run systemctl stop nginx, systemd sends the signal to the entire cgroup — all 10 processes die, including ones you didn't know existed. No more phantom workers. Monitoring: bash # Show process tree for a service's cgroup systemd-cgls /system.slice/nginx.service # Real-time resource monitoring (like top, but for cgroups) systemd-cgtop3.3 Resource Limits via Unit FilesInstead of manually configuring cgroups, just add lines to your [Service] section: ini [Service] # === MEMORY === # Soft limit: systemd will aggressively reclaim memory MemoryHigh=400M # Hard limit: OOM Killer will kill the process if exceeded MemoryMax=512M # Guaranteed memory (won't be given to others) MemoryMin=100M # === CPU === # 50% of a single core CPUQuota=50% # Or: CPU weight (1-10000, default=100) CPUWeight=200 # === DISK I/O === IOReadBandwidthMax=/dev/sda 50M IOWriteBandwidthMax=/dev/sda 20M # === NETWORK === IPAccounting=yes IPAddressAllow=192.168.0.0/24 IPAddressDeny=anyVerify current limits: bash # Check cgroup filesystem directly cat /sys/fs/cgroup/system.slice/nginx.service/memory.max # 536870912 (512 MB in bytes) # Or via systemctl systemctl show nginx.service | grep -E 'Memory|CPU|IO'Part 4. journald — Logs as a Database4.1 Why journald Beats Plain Text LogsA plain syslog is a text file. Want to find all nginx errors from the last hour? You write grep "error" /var/log/nginx/error.log | grep "$(date +%b\ %d)" and hope for the best. journald is a structured store with indexes. Every entry is not a text string but an object with fields: _SYSTEMD_UNIT=nginx.service ← which service _PID=1234 ← which process _UID=www-data ← which user _HOSTNAME=web-01 ← which host PRIORITY=3 ← severity level (err) MESSAGE=connection refused... ← the message itself _SOURCE_REALTIME_TIMESTAMP=... ← precise timestamp4.2 Complete journalctl Referencebash # === BASIC QUERIES === # All logs for a service sudo journalctl -u nginx.service # Last 50 lines sudo journalctl -u nginx.service -n 50 # Follow in real time (like tail -f) sudo journalctl -u nginx.service -f # From a specific time sudo journalctl -u nginx.service --since "2024-01-15 10:00:00" sudo journalctl -u nginx.service --since "1 hour ago" sudo journalctl -u nginx.service --since today sudo journalctl -u nginx.service --since yesterday --until "2024-01-14 23:59:59" # === FILTERING BY SEVERITY === # 0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug sudo journalctl -p err # only errors sudo journalctl -p err..warning # err through warning sudo journalctl -u nginx -p warning # nginx warnings only # === FILTERING BY BOOT === sudo journalctl -b # current boot sudo journalctl -b -1 # previous boot sudo journalctl -b -2 # two boots ago sudo journalctl --list-boots # list all boots # === OUTPUT FORMATS === sudo journalctl -u nginx -o json # JSON (for parsing) sudo journalctl -u nginx -o json-pretty # Formatted JSON sudo journalctl -u nginx -o verbose # All metadata fields sudo journalctl -u nginx -o cat # Message text only # === ADVANCED QUERIES === # Logs for a specific process sudo journalctl _PID=1234 # Logs from a specific user sudo journalctl _UID=1000 # Combine conditions (OR) sudo journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=php-fpm.service # Export to file sudo journalctl -u nginx --since today -o json > nginx-today.json # === JOURNAL MANAGEMENT === # Disk usage of the journal sudo journalctl --disk-usage # Clean up logs older than 2 weeks sudo journalctl --vacuum-time=2weeks # Clean up to a specific size sudo journalctl --vacuum-size=500MPart 5. Real-World Scenarios5.1 Creating a Production-Ready Service from Scratchini # /etc/systemd/system/api-server.service [Unit] Description=API Server Documentation=https://github.com/company/api-server After=network-online.target Wants=network-online.target Requires=postgresql.service After=postgresql.service [Service] Type=notify ExecStart=/usr/local/bin/api-server EnvironmentFile=/etc/api-server/env Environment="PORT=8080" Environment="LOG_LEVEL=info" Restart=on-failure RestartSec=5s StartLimitIntervalSec=60s StartLimitBurst=3 User=api Group=api WorkingDirectory=/opt/api-server # === SECURITY HARDENING === NoNewPrivileges=yes PrivateTmp=yes ProtectSystem=strict ProtectHome=yes ProtectKernelTunables=yes ProtectKernelModules=yes ProtectControlGroups=yes SystemCallFilter=@system-service ReadWritePaths=/var/lib/api-server /var/log/api-server # === RESOURCE LIMITS === MemoryMax=512M CPUQuota=200% LimitNOFILE=65536 [Install] WantedBy=multi-user.target5.2 Drop-in Files — Override Without Touching Originalsbash # systemctl edit creates the override file automatically sudo systemctl edit nginx.service # Creates: /etc/systemd/system/nginx.service.d/override.confini [Service] MemoryMax=256M Restart=always Environment="NGINX_ENVSUBST_OUTPUT_DIR=/etc/nginx"bash sudo systemctl daemon-reload sudo systemctl restart nginx.service # View the full effective config (original + drop-ins) sudo systemctl cat nginx.service5.3 Boot Time Analysis and Optimizationbash # Total boot time systemd-analyze # Startup finished in 2.134s (kernel) + 8.643s (userspace) = 10.777s # Top boot-time offenders systemd-analyze blame # Critical path to a specific target systemd-analyze critical-chain graphical.target # Generate visual timeline (open in browser!) systemd-analyze plot > boot-plot.svg # Validate a unit file for errors systemd-analyze verify /etc/systemd/system/myapp.service5.4 Diagnosing a Failing Service — Step by Stepbash # Step 1: Service status sudo systemctl status myapp.service # Step 2: Recent logs with full detail sudo journalctl -u myapp.service -n 100 --no-pager # Step 3: Logs since last boot (for startup issues) sudo journalctl -u myapp.service -b # Step 4: All errors in the system at the time of failure sudo journalctl -p err --since "10 min ago" --no-pager # Step 5: Check dependencies systemctl list-dependencies myapp.service # Step 6: Run manually as the service user (to reproduce) sudo -u myapp /usr/local/bin/myapp --config /etc/myapp/config.yml # Step 7: Check environment variables sudo systemctl show myapp.service -p Environment # Step 8: Check file permissions sudo systemctl cat myapp.service | grep -E 'ExecStart|WorkingDirectory|User' sudo ls -la /usr/local/bin/myappQuick Reference CheatsheetService ControlTask Command Start sudo systemctl start <name> Stop sudo systemctl stop <name> Restart sudo systemctl restart <name> Reload config (no stop) sudo systemctl reload <name> Status systemctl status <name> Enable autostart sudo systemctl enable <name> Disable autostart sudo systemctl disable <name> Enable AND start sudo systemctl enable --now <name> Block permanently sudo systemctl mask <name> Viewing StateTask Command All running services systemctl list-units --type=service --state=running All failed systemctl --failed Check autostart systemctl is-enabled <name> Check active systemctl is-active <name> Dependency tree systemctl list-dependencies <name> Who depends on this systemctl list-dependencies --reverse <name> All timers systemctl list-timers Logs (journalctl)Task Command Service logs sudo journalctl -u <name> Last N lines sudo journalctl -u <name> -n 50 Real-time sudo journalctl -u <name> -f Current boot sudo journalctl -u <name> -b Errors only sudo journalctl -u <name> -p err Since time sudo journalctl -u <name> --since "1h ago" Journal size sudo journalctl --disk-usage Cleanup sudo journalctl --vacuum-time=2weeks Performance DiagnosticsTask Command Boot time systemd-analyze Boot bottlenecks systemd-analyze blame Critical chain systemd-analyze critical-chain <target> Visual timeline systemd-analyze plot > boot.svg Validate unit file systemd-analyze verify /path/to/unit cgroup tree systemd-cgls cgroup resource usage systemd-cgtop ConclusionSystemd is not a monster to be feared — it's a powerful tool that makes you dramatically more effective as a sysadmin or developer. Key takeaways from this guide: Units are declarative resource descriptions. Write them properly and use available security directives. cgroups mean systemd always knows where your processes are. Use this for monitoring and resource constraints. journald is a database, not a text file. Learn to query it properly. Drop-in files — never edit original package-installed unit files. systemd-analyze — your first tool when diagnosing boot problems. -
Введение: Почему SysVinit умер, и при чём тут SystemdПредставьте себе повара, который готовит ужин на 10 человек, но строго по одному блюду за раз — сначала суп, потом только начинает нарезать салат. Именно так работала старая система инициализации SysVinit: запускала службы строго по одной, в заранее заданном порядке. Независимо от того, зависят ли они друг от друга. С усложнением Linux-систем это стало болью: Медленная загрузка. Служба A ждёт завершения службы B, даже если между ними нет никакой реальной зависимости. Нет контроля за процессами. Запустил — и забыл. Упал дочерний процесс? SysVinit об этом не знает. Хаос в логах. Каждый сервис пишет куда хочет: один в /var/log/nginx/, другой в syslog, третий в /tmp/. Никакой единой точки входа. Хрупкие скрипты. Shell-скрипты в /etc/init.d/ — это огромное поле для ошибок и несовместимостей между дистрибутивами. В 2010 году Леннарт Поттеринг (Lennart Poettering) представил systemd — систему, которая решала все эти проблемы разом. Параллельный запуск, граф зависимостей, контрольные группы, централизованные логи. Сообщество поначалу встретило его в штыки (споры были жаркими), но сегодня systemd — стандарт де-факто в Fedora, Debian, Ubuntu, Arch, RHEL, CentOS и большинстве других дистрибутивов. Давайте разберём его по косточкам. Часть 1. Архитектура systemd — что происходит под капотом1.1 PID 1 — главный процесс системыКогда ядро Linux загружается, оно запускает самый первый пользовательский процесс с PID 1. В системах с systemd это и есть демон systemd. Он — прямой родитель всех остальных процессов в системе. Это важно по двум причинам: Если PID 1 упадёт — система паникует. Поэтому systemd написан максимально надёжно. Все процессы, которые становятся «сиротами» (их родитель умер), автоматически переходят под крыло PID 1. Ядро Linux └── systemd (PID 1) ├── journald (логирование) ├── udevd (устройства) ├── networkd (сеть) ├── nginx.service (ваш веб-сервер) ├── postgresql.service (БД) └── ... все остальные сервисы1.2 Ключевые компоненты системыsystemd (PID 1) Главный дирижёр. Читает юнит-файлы, строит граф зависимостей, запускает процессы в нужном порядке, следит за их состоянием через cgroups. systemctl Ваш пульт управления. Когда вы пишете systemctl start nginx, эта утилита НЕ запускает nginx напрямую. Она отправляет сообщение по D-Bus демону systemd, который и выполняет работу. Это ключевое отличие от простого вызова скрипта. journald Централизованная система логирования. Перехватывает stdout и stderr всех сервисов, обогащает каждую запись метаданными (PID, UID, имя юнита, хостнейм) и сохраняет в структурированном бинарном формате. Это позволяет делать сложные запросы к логам — как SQL к базе данных. udevd Менеджер устройств. Когда вы подключаете USB-флешку, именно udevd создаёт /dev/sdb, загружает нужные модули ядра и может запустить определённый сервис. networkd, timedated, logind Специализированные демоны для управления сетью, системным временем и пользовательскими сессиями. Они общаются с PID 1 через D-Bus. 1.3 D-Bus — как компоненты разговаривают друг с другомD-Bus — это системная шина сообщений, аналог внутренней корпоративной почты между процессами. Вместо того чтобы процессы вызывали функции друг друга напрямую (что небезопасно), они отправляют структурированные сообщения через шину. Практический пример: systemctl start nginx systemctl формирует D-Bus-сообщение: «Вызови метод StartUnit с аргументом nginx.service» Сообщение уходит в системную шину Демон systemd получает его и выполняет Возвращает ответ через ту же шину Это даёт безопасность (права проверяются на уровне D-Bus), гибкость (любая программа может управлять сервисами) и расширяемость. Часть 2. Юниты — строительные блоки systemdЮнит (unit) — это описание любого системного ресурса в виде декларативного конфигурационного файла. Думайте о нём как о «паспорте» для сервиса, сокета, таймера или точки монтирования. 2.1 Где хранятся юнитыПуть Назначение Приоритет /usr/lib/systemd/system/ Юниты, установленные пакетным менеджером Низкий /etc/systemd/system/ Ваши кастомные юниты и переопределения Высокий /run/systemd/system/ Временные юниты (исчезают после перезагрузки) Высший 2.2 Типы юнитов.service — сервисы (самый частый тип)Описывает демон или процесс. Именно с ним вы работаете в 90% случаев. ini # /etc/systemd/system/myapp.service [Unit] Description=My Awesome Application After=network.target postgresql.service Requires=postgresql.service [Service] Type=simple ExecStart=/usr/bin/myapp --config /etc/myapp/config.yml ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5s User=myapp Group=myapp [Install] WantedBy=multi-user.targetПараметр Type= — это важно понимать правильно: Тип Поведение Когда использовать simple systemd считает сервис запущенным сразу после старта ExecStart Большинство современных программ forking Программа делает fork() и завершает родительский процесс. systemd ждёт этого. Старые Unix-демоны (nginx, apache) notify Программа сама сигнализирует systemd через sd_notify(), что готова Программы с поддержкой systemd API oneshot Программа выполняется и завершается. systemd ждёт завершения. Скрипты, одноразовые задачи dbus Сервис считается запущенным, когда занял имя на D-Bus Демоны, использующие D-Bus idle Запуск откладывается до завершения всех остальных задач Фоновые задачи с низким приоритетом Жизненный цикл и перезапуск: ini [Service] # Варианты для Restart=: # no — не перезапускать никогда # on-success — только при коде выхода 0 # on-failure — при любом ненулевом коде, сигнале или таймауте (самый частый выбор) # on-abnormal — при сигнале или таймауте (не при коде выхода) # always — перезапускать всегда (даже при systemctl stop!) Restart=on-failure RestartSec=5s # Ограничение на количество перезапусков: # Максимум 5 попыток за 30 секунд, потом сдаться StartLimitIntervalSec=30s StartLimitBurst=5.socket — socket-based activation (ленивый запуск)Это одна из самых мощных и недооценённых фич systemd. Идея простая: зачем держать 20 сервисов запущенными, если большинство из них обращаются раз в час? Socket-based activation работает так: systemd открывает и слушает сокет (порт, Unix socket, FIFO) Сам сервис не запущен Приходит первое подключение systemd запускает сервис и передаёт ему уже установленное соединение Клиент не замечает разницы — соединение не потеряно! ini # /etc/systemd/system/echo.socket [Unit] Description=Echo Server Socket [Socket] ListenStream=12345 Accept=no [Install] WantedBy=sockets.targetini # /etc/systemd/system/echo.service [Unit] Description=Echo Server Service [Service] Type=simple ExecStart=/usr/local/bin/echo-server # Сервис получит сокет через файловый дескриптор 3 StandardInput=socketАктивация: sudo systemctl enable --now echo.socket — и сервис будет запускаться автоматически при первом подключении. .timer — замена cron с суперспособностямиТаймеры systemd мощнее cron по нескольким причинам: Поддерживают зависимости (запустить только если работает такой-то сервис) Логируются в journald как обычные юниты Могут «догнать» пропущенные запуски после перезагрузки (Persistent=true) Точность до секунды и поддержка случайных задержек для распределения нагрузки ini # /etc/systemd/system/backup.timer [Unit] Description=Daily Backup Timer [Timer] # Запускать каждый день в 02:30 OnCalendar=*-*-* 02:30:00 # Случайная задержка до 10 минут (не всё одновременно в 02:30!) RandomizedDelaySec=10m # Запустить задачу, если она была пропущена (например, система была выключена) Persistent=true [Install] WantedBy=timers.targetini # /etc/systemd/system/backup.service [Unit] Description=Daily Backup Job [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh User=backupАктивация: sudo systemctl enable --now backup.timer Проверить все активные таймеры: systemctl list-timers --all Синтаксис OnCalendar: Выражение Значение daily Каждый день в 00:00 weekly Каждый понедельник в 00:00 monthly 1-го числа каждого месяца *-*-* 09:00:00 Каждый день в 09:00 Mon-Fri *-*-* 08:30:00 По будням в 08:30 *-*-1,15 00:00:00 1-го и 15-го каждого месяца Проверить выражение: systemd-analyze calendar "Mon-Fri *-*-* 08:30:00" .target — группы юнитов (замена runlevel)Target — это не сервис, а точка синхронизации. Думайте об этом как о «состоянии системы», которого нужно достичь. Target Аналог runlevel Значение poweroff.target 0 Выключение rescue.target 1 Однопользовательский режим multi-user.target 3 Многопользовательский без GUI graphical.target 5 С графическим интерфейсом reboot.target 6 Перезагрузка bash # Узнать текущий target (аналог текущего runlevel) systemctl get-default # Сменить target (аналог init 3) sudo systemctl isolate multi-user.target # Установить target по умолчанию sudo systemctl set-default multi-user.target.path — реакция на события файловой системыАналог incron. Запускает сервис при изменениях в файловой системе. ini # /etc/systemd/system/watch-uploads.path [Unit] Description=Watch for new uploads [Path] # Запустить связанный .service когда появится этот файл PathExists=/var/spool/uploads/trigger.flag # Или мониторить директорию на изменения DirectoryNotEmpty=/var/spool/uploads/ [Install] WantedBy=multi-user.target2.3 Зависимости между юнитами — граф, а не очередьЭто одно из ключевых отличий systemd от SysVinit. Вместо фиксированного порядка — направленный граф зависимостей. Директивы зависимостей: Директива Тип Поведение Requires= Жёсткая Если зависимость не запустилась — этот юнит тоже не стартует и останавливается вместе с ней Wants= Мягкая Пробует запустить зависимость, но если та упадёт — не останавливается BindsTo= Очень жёсткая Как Requires, но юнит останавливается если зависимость остановится в любой момент PartOf= Односторонняя Останавливается/перезапускается вместе с зависимостью, но не запускается вместе с ней Conflicts= Конфликт Не может работать одновременно с указанным юнитом Директивы порядка: Директива Поведение After= Этот юнит запускается ПОСЛЕ указанного Before= Этот юнит запускается ДО указанного ini [Unit] # Правильная комбинация: сначала БД, потом мы, и мы не работаем без БД After=postgresql.service Requires=postgresql.serviceЧасть 3. cgroups — почему systemd знает всё о ваших процессах3.1 Проблема, которую решают cgroupsПредставьте: nginx запущен. Он форкает 4 воркера. Один воркер форкает ещё процесс для CGI. Тот форкает что-то ещё. Итого 10 процессов, и все они «принадлежат» nginx, но в SysVinit это было невозможно отследить. Control Groups (cgroups) — механизм ядра Linux, который позволяет объединять процессы в иерархические группы и управлять ими совместно. Systemd автоматически создаёт cgroup для каждого сервиса. Все дочерние процессы — внутри этой группы. Всегда. /sys/fs/cgroup/ ├── system.slice/ │ ├── nginx.service/ ← все процессы nginx здесь │ │ ├── pid: 1234 (master) │ │ ├── pid: 1235 (worker 1) │ │ ├── pid: 1236 (worker 2) │ │ └── pid: 1237 (cache loader) │ ├── postgresql.service/ ← и postgres здесь │ └── redis.service/ └── user.slice/ └── user-1000.slice/ ← процессы пользователя3.2 Что даёт cgroup на практикеТочный kill без зомби-процессов: При systemctl stop nginx systemd отправляет сигнал всей cgroup — умирают все 10 процессов, включая те, о которых вы не знали. Больше никаких «phantom workers». Мониторинг: bash # Показать дерево процессов cgroup сервиса systemd-cgls /system.slice/nginx.service # Вывод: # /system.slice/nginx.service # └─ 1234 /usr/sbin/nginx -g daemon off; # ├─ 1235 nginx: worker process # ├─ 1236 nginx: worker process # └─ 1237 nginx: cache loader process # Мониторинг ресурсов в реальном времени (как top, но для cgroups) systemd-cgtop3.3 Ограничение ресурсов через юнит-файлыЭто магия. Вместо сложных настроек cgroups вручную — просто добавляете строки в секцию [Service]: ini [Service] # === ПАМЯТЬ === # Мягкий лимит: systemd начнёт агрессивно освобождать память MemoryHigh=400M # Жёсткий лимит: OOM Killer убьёт процесс если превысит MemoryMax=512M # Гарантированная память (не будет отдана другим) MemoryMin=100M # === CPU === # 50% от одного ядра CPUQuota=50% # Или: вес CPU (1-10000, default=100) CPUWeight=200 # === ДИСК (I/O) === # Ограничение чтения/записи для конкретного устройства IOReadBandwidthMax=/dev/sda 50M IOWriteBandwidthMax=/dev/sda 20M # === СЕТЬ (через IP accounting) === IPAccounting=yes IPAddressAllow=192.168.0.0/24 IPAddressDeny=anyПроверка текущих лимитов: bash # Посмотреть параметры cgroup напрямую в файловой системе cat /sys/fs/cgroup/system.slice/nginx.service/memory.max # 536870912 (512 МБ в байтах) # Или через systemctl systemctl show nginx.service | grep -E 'Memory|CPU|IO'Часть 4. journald — логи как база данных4.1 Почему journald лучше текстовых логовОбычный syslog — это текстовый файл. Хочешь найти все ошибки nginx за последний час? Пишешь grep "error" /var/log/nginx/error.log | grep "$(date +%b\ %d)" и молишься. journald — структурированное хранилище с индексами. Каждая запись — не строчка текста, а объект с полями: _SYSTEMD_UNIT=nginx.service ← какой сервис _PID=1234 ← какой процесс _UID=www-data ← от какого пользователя _HOSTNAME=web-01 ← на каком хосте PRIORITY=3 ← уровень важности (err) MESSAGE=connection refused... ← само сообщение _SOURCE_REALTIME_TIMESTAMP=... ← точное время4.2 Полное руководство по journalctlbash # === БАЗОВЫЕ ЗАПРОСЫ === # Все логи конкретного сервиса sudo journalctl -u nginx.service # Последние 50 строк sudo journalctl -u nginx.service -n 50 # Следить в реальном времени (как tail -f) sudo journalctl -u nginx.service -f # С определённого момента sudo journalctl -u nginx.service --since "2024-01-15 10:00:00" sudo journalctl -u nginx.service --since "1 hour ago" sudo journalctl -u nginx.service --since today sudo journalctl -u nginx.service --since yesterday --until "2024-01-14 23:59:59" # === ФИЛЬТРАЦИЯ ПО УРОВНЮ ВАЖНОСТИ === # 0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug sudo journalctl -p err # только err sudo journalctl -p err..warning # от err до warning sudo journalctl -u nginx -p warning # предупреждения nginx # === ФИЛЬТРАЦИЯ ПО ЗАГРУЗКЕ === sudo journalctl -b # текущая загрузка sudo journalctl -b -1 # предыдущая загрузка sudo journalctl -b -2 # позапрошлая загрузка sudo journalctl --list-boots # список всех загрузок # === ФОРМАТЫ ВЫВОДА === sudo journalctl -u nginx -o json # JSON (для парсинга) sudo journalctl -u nginx -o json-pretty # JSON с форматированием sudo journalctl -u nginx -o verbose # Все поля записи sudo journalctl -u nginx -o cat # Только текст сообщений # === ПРОДВИНУТЫЕ ЗАПРОСЫ === # Логи конкретного процесса sudo journalctl _PID=1234 # Логи от конкретного пользователя sudo journalctl _UID=1000 # Комбинирование условий (OR) sudo journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=php-fpm.service # Экспорт в файл sudo journalctl -u nginx --since today -o json > nginx-today.json # === УПРАВЛЕНИЕ ЖУРНАЛОМ === # Размер журнала на диске sudo journalctl --disk-usage # Очистка старых логов (оставить только за последние 2 недели) sudo journalctl --vacuum-time=2weeks # Очистка до определённого размера sudo journalctl --vacuum-size=500M4.3 Настройка journaldini # /etc/systemd/journald.conf [Journal] # Максимальный размер журнала на диске SystemMaxUse=1G # Максимальный размер одного файла журнала SystemMaxFileSize=100M # Хранить журналы не дольше MaxRetentionSec=1month # Сжатие (по умолчанию включено) Compress=yes # Перенаправить в syslog (для совместимости) ForwardToSyslog=no # Уровень логирования по умолчанию MaxLevelStore=debug MaxLevelSyslog=warningПосле изменения: sudo systemctl restart systemd-journald Часть 5. Практика — реальные сценарии5.1 Создание production-ready сервиса с нуляЗадача: создать сервис для Go-приложения с полной изоляцией и автоматическим перезапуском. ini # /etc/systemd/system/api-server.service [Unit] Description=API Server Documentation=https://github.com/company/api-server After=network.target Wants=network-online.target After=network-online.target # Если зависит от БД: Requires=postgresql.service After=postgresql.service [Service] Type=notify # Путь к бинарнику ExecStart=/usr/local/bin/api-server # Путь к конфигу через переменную окружения EnvironmentFile=/etc/api-server/env # Или напрямую: Environment="PORT=8080" Environment="LOG_LEVEL=info" # Перезапуск Restart=on-failure RestartSec=5s StartLimitIntervalSec=60s StartLimitBurst=3 # Пользователь и группа User=api Group=api # Рабочая директория WorkingDirectory=/opt/api-server # === БЕЗОПАСНОСТЬ === # Запрет повышения привилегий NoNewPrivileges=yes # Изолированный /tmp PrivateTmp=yes # Только чтение для /usr, /boot, /etc ProtectSystem=strict # Запрет доступа к домашним директориям ProtectHome=yes # Изолированная сеть для системных вызовов ProtectKernelTunables=yes ProtectKernelModules=yes ProtectControlGroups=yes # Список разрешённых системных вызовов SystemCallFilter=@system-service # Разрешить запись только в эти директории ReadWritePaths=/var/lib/api-server /var/log/api-server # === РЕСУРСЫ === MemoryMax=512M CPUQuota=200% # Ограничение открытых файлов LimitNOFILE=65536 [Install] WantedBy=multi-user.targetПрименение: bash sudo systemctl daemon-reload sudo systemctl enable --now api-server.service sudo systemctl status api-server.service5.2 Drop-in файлы — переопределение без изменения оригиналаЗолотое правило: никогда не редактируйте файлы в /usr/lib/systemd/system/. Используйте drop-in файлы. bash # Удобный способ — systemctl edit сам создаст файл sudo systemctl edit nginx.serviceСоздастся файл /etc/systemd/system/nginx.service.d/override.conf: ini [Service] # Добавим лимит памяти к стандартному nginx MemoryMax=256M # Переопределим тип перезапуска Restart=always # Добавим переменную окружения Environment="NGINX_ENVSUBST_OUTPUT_DIR=/etc/nginx"bash # После сохранения: sudo systemctl daemon-reload sudo systemctl restart nginx.service # Посмотреть итоговую конфигурацию (оригинал + drop-ins) sudo systemctl cat nginx.service5.3 Анализ и оптимизация времени загрузкиbash # Общее время загрузки systemd-analyze # Startup finished in 2.134s (kernel) + 8.643s (userspace) = 10.777s # Топ «тормозов» при загрузке systemd-analyze blame # 4.123s NetworkManager-wait-online.service # 2.456s plymouth-quit-wait.service # 1.234s dev-sda1.device # 0.987s apparmor.service # Критический путь загрузки — что тормозит конкретный target systemd-analyze critical-chain graphical.target # Визуальная диаграмма в SVG (откройте в браузере!) systemd-analyze plot > boot-plot.svg # Проверить юнит-файл на ошибки systemd-analyze verify /etc/systemd/system/myapp.serviceЧастые причины медленной загрузки и как их лечить: Проблема Симптом Решение NetworkManager-wait-online.service 20-30 секунд ожидания сети sudo systemctl disable NetworkManager-wait-online.service (если сеть не нужна при загрузке) Сервис висит на старте Долгий timeout Проверить TimeoutStartSec= и зависимости Много последовательных зависимостей Длинный critical chain Заменить Requires= на Wants= где возможно 5.4 Диагностика падающего сервиса — пошаговый алгоритмbash # Шаг 1: Статус сервиса sudo systemctl status myapp.service # Ищем: статус (failed/active), последние строки лога, код выхода # Шаг 2: Последние логи с подробными метаданными sudo journalctl -u myapp.service -n 100 --no-pager # Шаг 3: Логи с момента последней загрузки (для проблем при старте) sudo journalctl -u myapp.service -b # Шаг 4: Все ошибки в системе в момент падения sudo journalctl -p err --since "10 min ago" --no-pager # Шаг 5: Проверить зависимости systemctl list-dependencies myapp.service # Все зависимости должны быть зелёными # Шаг 6: Запустить вручную под тем же пользователем (для воспроизведения) sudo -u myapp /usr/local/bin/myapp --config /etc/myapp/config.yml # Шаг 7: Посмотреть все переменные окружения сервиса sudo systemctl show myapp.service -p Environment # Шаг 8: Проверить права доступа к файлам sudo systemctl cat myapp.service | grep -E 'ExecStart|WorkingDirectory|User' sudo ls -la /usr/local/bin/myappЧасть 6. Продвинутые техники6.1 Шаблонные юниты — один файл для многих экземпляровЕсли нужно запустить один и тот же сервис с разными параметрами (например, несколько воркеров), используйте шаблоны. ini # /etc/systemd/system/worker@.service # Обратите внимание на @ в имени файла! [Unit] Description=Worker Instance %i After=network.target [Service] Type=simple ExecStart=/usr/local/bin/worker --id=%i --config=/etc/worker/config.yml User=worker Restart=on-failure [Install] WantedBy=multi-user.targetЗапуск нескольких экземпляров: bash # %i заменится на значение после @ sudo systemctl start worker@1.service sudo systemctl start worker@2.service sudo systemctl start worker@3.service # Или всех сразу: sudo systemctl enable worker@{1..5}.service sudo systemctl start worker@{1..5}.service # Посмотреть все запущенные экземпляры systemctl list-units 'worker@*'6.2 Временные сервисы через systemd-runbash # Запустить команду как временный сервис (исчезнет после завершения) sudo systemd-run --unit=my-task /usr/bin/python3 /opt/scripts/heavy_task.py # С ограничением ресурсов sudo systemd-run --unit=cpu-heavy --property=CPUQuota=50% --property=MemoryMax=256M \ /usr/bin/python3 /opt/scripts/heavy_task.py # Следить за прогрессом journalctl -u my-task -f6.3 Полезные команды, о которых мало кто знаетbash # Проверить юнит-файл на синтаксические ошибки ДО применения systemd-analyze verify /etc/systemd/system/myapp.service # Показать все переопределения (drop-in файлы) для сервиса systemctl cat nginx.service # Показать все свойства юнита systemctl show nginx.service # Показать конкретное свойство systemctl show nginx.service -p MainPID systemctl show nginx.service -p MemoryCurrent # Перезагрузить конфиги без daemon-reload (для drop-in файлов) sudo systemctl daemon-reload # Перечитать конфиги всех сервисов (более мягкий вариант) sudo systemctl reload-or-restart nginx.service # Узнать, какой пакет установил юнит systemctl cat nginx.service | head -1 # # /lib/systemd/system/nginx.service dpkg -S /lib/systemd/system/nginx.service # Debian/Ubuntu rpm -qf /lib/systemd/system/nginx.service # RHEL/Fedora # Блокировка: сервис не запустится даже вручную sudo systemctl mask dangerous-service.service # Разблокировка sudo systemctl unmask dangerous-service.serviceШпаргалка — все команды в одном местеУправление сервисамиЗадача Команда Запустить sudo systemctl start <name> Остановить sudo systemctl stop <name> Перезапустить sudo systemctl restart <name> Перечитать конфиг (без остановки) sudo systemctl reload <name> Reload или restart sudo systemctl reload-or-restart <name> Статус systemctl status <name> Включить автозапуск sudo systemctl enable <name> Выключить автозапуск sudo systemctl disable <name> Включить И запустить sudo systemctl enable --now <name> Заблокировать навсегда sudo systemctl mask <name> Просмотр состоянияЗадача Команда Все запущенные сервисы systemctl list-units --type=service --state=running Все упавшие systemctl --failed Проверить автозапуск systemctl is-enabled <name> Проверить активность systemctl is-active <name> Дерево зависимостей systemctl list-dependencies <name> Кто зависит от этого systemctl list-dependencies --reverse <name> Все таймеры systemctl list-timers Логи (journalctl)Задача Команда Логи сервиса sudo journalctl -u <name> Последние N строк sudo journalctl -u <name> -n 50 В реальном времени sudo journalctl -u <name> -f За текущую загрузку sudo journalctl -u <name> -b Только ошибки sudo journalctl -u <name> -p err С определённого времени sudo journalctl -u <name> --since "1h ago" Размер журнала sudo journalctl --disk-usage Очистить старые sudo journalctl --vacuum-time=2weeks Диагностика производительностиЗадача Команда Время загрузки systemd-analyze Что грузилось дольше всех systemd-analyze blame Критический путь systemd-analyze critical-chain <target> Визуальная диаграмма systemd-analyze plot > boot.svg Проверить юнит-файл systemd-analyze verify /path/to/unit Дерево cgroups systemd-cgls Ресурсы cgroups в реальном времени systemd-cgtop ЗаключениеSystemd — это не монстр, которого стоит бояться. Это мощный инструмент, понимание которого делает вас значительно эффективнее как системного администратора или разработчика. Несколько ключевых идей, которые стоит унести из этой статьи: Юниты — декларативные описания ресурсов. Пишите их правильно, используя все доступные настройки безопасности. cgroups — системd всегда знает, где ваши процессы. Используйте это для мониторинга и ограничения ресурсов. journald — это база данных, а не текстовый файл. Учитесь делать правильные запросы. Drop-in файлы — никогда не редактируйте оригинальные юнит-файлы из пакетов. systemd-analyze — ваш первый инструмент при проблемах с загрузкой. -
Собран полный набор установочных ISO-образов для администрирования систем хранения HPE 3PAR StoreServ. В архиве представлены оригинальные дистрибутивы консолей управления, вспомогательных инструментов и клиентов для работы с массивами 3PAR. Доступны следующие образы: • 3PAR_Management_Console_4.7.3_QR482-11188.iso • 3PAR_Management_Console_4.7_QR482-10116.iso • 3PAR_SSMC_Excel_client_installer_SW_QR482-10120.iso • 3PAR_StoreServ_Management_Console_2.2_QR482-10119.iso • TOOLS_3.1.3.202_GA_Z7550-10556.iso Эти пакеты включают: 3PAR Management Console (MC) — классическую Java-консоль для управления массивами HPE 3PAR. StoreServ Management Console (SSMC) — современный веб-интерфейс администрирования. SSMC Excel Client — плагин для управления и мониторинга массивов через Microsoft Excel. 3PAR Tools — набор служебных утилит и вспомогательных компонентов для обслуживания системы. Подходит для администрирования и обслуживания различных моделей HPE 3PAR StoreServ, включая среды виртуализации, SAN-инфраструктуру и корпоративные системы хранения. Скачать образы можно по ссылке: Вот ссылка (Тык тут) Материалы будут полезны администраторам систем хранения, инженерам по инфраструктуре и специалистам по поддержке SAN, которым требуется доступ к классическим версиям консолей управления HPE 3PAR.
-
Коллеги, всем доброго времени суток! Столкнулся с проблемой при восстановлении EMC VNX5300 (дисковая полка на 25 дисков 2.5"). Информация по устройству: PROD ID / SN: CKM0013120101506 P/N: 900-567-002 Ситуация следующая: первые 4 системных диска, на которых находилась ОС массива, были уничтожены дегауссом. После этого были куплены 4 новых диска, но, разумеется, без системного образа. Что уже сделал: подключился к контроллеру через COM-порт (есть консольный кабель); при загрузке система пишет, что необходимо обратиться в поддержку; пробовал использовать команду recover. После ввода recover появляется ошибка: Data directory boot service Not Loaded Error! после чего происходит перезагрузка контроллера. Фактически массив сейчас не может загрузиться, так как системные диски пустые. В поддержку Dell обратиться не получается — профиль помечен жёлтой галкой, и дальнейшие действия непонятны (нет доступа к загрузкам). Собственно вопросы: Есть ли вообще возможность восстановить ОС на EMC VNX5300, если системные диски были полностью уничтожены? Можно ли самостоятельно развернуть системный образ на новые диски? Где можно найти образы для установки на системные диски? Насколько удалось выяснить, нужен образ примерно такого вида: FLARE-05.33.009.5.186.mif или что-то из этой же ветки FLARE OS для VNX5300. Диски, если что, имеются разные (совместимые), с этим проблем нет. Буду очень благодарен, если кто-то подскажет: возможную процедуру восстановления, либо поделится образами FLARE / recovery для VNX5300. Перепробовал уже, кажется, всё, что можно — но пока безрезультатно.
-
Коллеги, всем привет! iLO 2 Activation Key: 372CG-JCDSP-ZXKL9-WVBZ9-SJHHM iLo2/iLO4 Advanced License Keys: 35DPH-SVSXJ-HGBJN-C7N5R-2SS4W 35SCR-RYLML-CBK7N-TD3B9-GGBW2Делюсь ключиками для iLo, чтоб вам былы доступны все функции вашего сервера HP
-
В общем в очередной раз лазил в сети в поисках образа для обновления платформы HP Gen9 и нашел таки! Вот список, чего там есть: P52574_001_spp-Gen9.1-Gen9SPPGen91.2022_0822.4.iso - сам основной образ для пакетного обновления платформы P69223_001_Gen9.4HotfixBundle-Gen9PPHotFixBundleGen9.4.2.7z - самый свежий на сегодня фикс Ну и по мелочи, прошивки... Делюсь ссылкой на все файлы с вами ССЫлка на скачивание
-
Поймал программист золотую рыбку: — Загадывай желание! — Хочу, чтобы Python никогда не падал в продакшне! — Слушай, лучше мир во всём мире — оно реальнее. Построили полностью роботизированный завод. Экскурсия по цехам: — Здесь роботы на Unix. Работают как часы уже 15 лет. — Здесь на MS-DOS. Немного устарело, но стабильно. — А вот здесь — на Windows 98. Прошу всех надеть скафандры и не делать резких движений. Новый карманный компас на Windows CE. На экране: «Север не найден. Повторить поиск? Да / Позже» Звонок на радио: — Поставьте, пожалуйста, ту песню Пугачёвой — про зависший Windows! — Хм... не припомню такой. Можете напеть? — Ну там припев: «Кликну — а в ответ тишина, снова я осталась одна. Сильная женщина плачет у Окна» Пресс-конференция NASA по поводу сбоя компьютера на МКС: — Скажите, МКС работает под Windows? — А вы вообще видели, чтобы под Windows хоть что-то летало? Умер Билл Гейтс. Архангел Пётр: — Что скажешь в своё оправдание? — Я осчастливил всё человечество! — Это каким же образом? — Ну... умер же. Установка Windows. Приветственный экран: «Добро пожаловать. Откиньтесь в кресле, расслабьтесь, закройте глаза — и молитесь»
-
У меня есть примерно 450 000 шуток про BGP 📡 Шутки про RAID почти всегда избыточны 💾 Шутку про 127.0.0.1 каждый может пошутить себе сам 🖥️ Я знаю отличную шутку про UDP, но не факт, что она до вас дойдёт 📦 Жаль, что шутка про Fault Tolerance не может состоять больше чем из одного слова ⚙️ Шутки про IPv6 плохи тем, что их мало кому можно рассказать 🌍 А вы слышали шутку про ICMP? 📢 Самое клёвое в шутках про rsync — её рассказывают только если вы не слышали её до этого 🔁 Шутки про RFC 1918 можно рассказывать только своим 🏠 Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь 🎟️ Про DWDM шутят сразу несколькими голосами 🎙️ DHCP шутки смешны, только если их рассказывает один человек 🧾 Подождите все, я расскажу шутку о сети типа «шина» 🚌 Шутки про SSH-1 и SSH-2 несовместимы между собой 🔐 Из-за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point-to-multipoint 🔄 Я знаю отличную шутку про TCP, но если она не дойдёт — повторю 📬 IGMP шутка; пожалуйста, передай дальше 📡 Шутки про IPv4 уже закончились? 🤔 Шутки про MAC-адрес могут не дойти до тёзок 🏷️ Я сейчас расскажу отличную шутку про VPN, но её поймёт только один 🔒 PPP шутки всегда рассказываются только между двумя людьми 🤝 Про Schema Master шутит только один в этом лесу 🌲 Лучшее в шутках про проприетарные протоколы — это УДАЛЕНО 🚫 Фрагментированные шутки… ✂️ …всегда рассказываются… 📦 …по кусочкам. 🧩 У кого есть кабель? Есть смешная шутка про RS-232 и полусмешная про RS-485 🔌 DNS-сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду 🌪️ Я подожду Антона и расскажу классную шутку про QoS ⏳ Самое лучшее в шутках про BitTorrent — они могут идти в любом порядке 🧲 К шутке про SCTP вначале должны все подготовиться 📋 Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал 🕵️ Нет ничего забавного в шутках про определение MTU… 📏 Шутки про 10/100/1000BASE-T вряд ли услышат с расстояния больше 100 📶 Жаль, никто не помнит шутки про IPX 🗂️ А кто знает отличную шутку про ARP? 🧠 Шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC 🔄 Только что специально для сообщества пришла шутка про мультикаст 📣 И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток 📚 Министерство обороны США понимает только четыре уровня шуток 🪖 Вы уже слышали шутку про Jumbo фреймы? Она о-о-очень длинная 📏 Шутки про MitM любят все. Ну кроме Алисы и Боба 😏 А шутки про STP вам кто-нибудь рассказывал? 🌳 Я сейчас всем расскажу шутку про бродкаст 📢 Настало время рассказать шутку про NTP ⏰ Помню времена, когда шутка про модем пшшшшшш… 📞 Про MTU тоже есть классная 📐 <шутка><смешная/><про>XML</про></шутка> 🧾 Шутки про шутки про шутки часто звучат в туннелях 🚇 У кого есть пароли — приходите за шутками про RADIUS 🔑 Шутки про IPSec надо говорить, кому их рассказываешь 🛡️ Шутка про Е3 — это 30 одинаковых шуток про Е1 и ещё две для тех, кто в теме 📊 Шутки про FSMO роли могут шутить не более пяти человек 👑 Единственная проблема в шутках про Token Ring — если кто-то начнёт говорить одновременно с вами, обе шутки обрываются 🎙️
-
1. Зачем нужна PSRAM в ESP32Микроконтроллеры семейства ESP32 имеют сотни килобайт встроенной SRAM, размещённой на том же кристалле, что и CPU, периферия и контроллеры. Для задач вроде: обработки графики (LVGL, дисплеи), буферизации аудио, работы с большими JSON, сетевых стеков, ML-моделей, этого объёма часто недостаточно. Поэтому архитектура предусматривает подключение внешней PSRAM (Pseudo-Static RAM) — псевдо-статической оперативной памяти, которая расширяет доступный heap. 2. Что такое PSRAM2.1 ТерминологияВ документации Espressif используются как взаимозаменяемые: PSRAM SPI RAM SPIRAM Во всех случаях речь идёт об одном типе внешней памяти. 2.2 Почему «Pseudo-Static»PSRAM сочетает в себе: Внутренняя структура: DRAMЯчейки динамические (как в DRAM) Требуется refresh Внешний интерфейс: как у SRAMВстроенная логика регенерации CPU работает с ней как с обычной RAM Внешний контроллер refresh не нужен Именно поэтому — Pseudo-Static. 3. Аппаратная архитектура доступа к PSRAM3.1 ПодключениеPSRAM подключается: через SPI / QSPI / OPI по той же шине, что и Flash с отдельной линией Chip Select В модулях типа WROVER чип PSRAM обычно установлен внутри металлического экрана. В новых сериях возможна: in-package PSRAM (в одном корпусе с SoC) но архитектурно она остаётся «внешней» 3.2 Как CPU обращается к PSRAMДоступ НЕ прямой. Схема: CPU → Cache → MMU → SPI → PSRAM Алгоритм:CPU обращается к виртуальному адресу. MMU отображает его в физический адрес PSRAM. Cache: cache hit → мгновенно cache miss → чтение через SPI В новых сериях используется write-back cache. 3.3 Главное ограничениеPSRAM всегда медленнее внутренней SRAM, потому что: последовательная шина работа через кэш латентность SPI Следствие: стек задач и DMA-буферы по умолчанию остаются во внутренней памяти. 4. Важные аппаратные ограничения4.1 НапряжениеPSRAM бывает: 1.8 В 3.3 В Оно должно совпадать с Flash. Выбор задаётся: strapping pins eFuse Ошибка может: отключить память повредить чип 4.2 DMAНа старых ESP32: DMA напрямую с PSRAM невозможен На новых сериях: возможен но требует контроля когерентности кэша 4.3 Стек FreeRTOSПо умолчанию: стек задач → внутренняя RAM Технически можно разместить в PSRAM (через xTaskCreateStatic), но это не рекомендуется. 5. Особенности разных серий ESP325.1 Классический ESP32QSPI (4 линии) максимум 4 МБ отображаемого окна кэш 32 КБ на ядро при 8 МБ требуется Himem API (bank switching) Поддерживаются режимы MMU: Normal Low-High Even-Odd DMA напрямую не работает. 5.2 ESP32-S2независимые ICache и DCache до 10.5 МБ виртуального адресного пространства возможно выполнение кода из PSRAM настраиваемый размер кэша 5.3 ESP32-S3Quad / Octal SPI поддержка XTS-AES до 32 МБ отображаемого пространства общий кэш для двух ядер Octal PSRAM заметно быстрее Quad. 5.4 ESP32-C5 и ESP32-C61поддержка PSRAM есть до 32 МБ отображения доступ через кэш и GDMA Ранние C-серии (C2, C3, C6) PSRAM не поддерживают. 5.5 ESP32-P4Наиболее производительная архитектура: до 64 МБ PSRAM интерфейсы OPI и HPI двухуровневый кэш (L1 + L2) частоты до 200 МГц аппаратное шифрование 6. Использование PSRAM в ESP-IDFОсновной компонент: esp_psram В новых версиях ESP-IDF его нужно явно добавить в зависимости: idf_component_register( SRCS "main.c" INCLUDE_DIRS "." REQUIRES esp_psram )После этого появляется меню: Component config → ESP PSRAM7. Ключевые параметры menuconfig7.1 CONFIG_SPIRAM_BOOT_INITАвтоматическая инициализация при старте. Рекомендуется включать. 7.2 CONFIG_SPIRAM_IGNORE_NOTFOUNDПозволяет загружаться без PSRAM. Полезно для универсальных прошивок. 7.3 CONFIG_SPIRAM_MEMTESTТест памяти при старте. ≈ 1 секунда на 4 МБ. 7.4 CONFIG_SPIRAM_USEОпределяет стратегию интеграции: 1) MEMMAPПросто отображение в адресное пространство. Вы сами управляете памятью. 2) CAPS_ALLOCИспользование через: heap_caps_malloc(size, MALLOC_CAP_SPIRAM);Наиболее управляемый способ. 3) MALLOC (по умолчанию)PSRAM объединяется с общей кучей. malloc() автоматически выбирает регион. 7.5 CONFIG_SPIRAM_MALLOC_ALWAYSINTERNALПорог (по умолчанию 16 КБ): меньше → внутренняя RAM больше → PSRAM 7.6 CONFIG_SPIRAM_MALLOC_RESERVE_INTERNALРезервирует внутреннюю память под: DMA стеки задач критические участки Очень важная опция для стабильности. 7.7 Перенос кода и данныхCONFIG_SPIRAM_FETCH_INSTRUCTIONS CONFIG_SPIRAM_RODATA CONFIG_SPIRAM_XIP_FROM_PSRAM Позволяют: выполнять код из PSRAM разгрузить Flash ускорить систему (в Octal-режиме) 8. API esp_psramФункции: esp_psram_init(); esp_psram_is_initialized(); esp_psram_get_size();Практически используется только: esp_psram_get_size();9. Выделение памяти9.1 Автоматический режимvoid *ptr = malloc(size);Работает при CONFIG_SPIRAM_USE_MALLOC. 9.2 Явное выделение в PSRAMvoid *ptr = heap_caps_malloc(size, MALLOC_CAP_SPIRAM);Освобождение — обычный free(). 9.3 Когда использовать PSRAMПодходит для: больших JSON framebuffer аудиобуферов кешей временных массивов Не подходит для: DMA ISR стека задач структур с высокой частотой доступа 10. Практическая стратегияОптимальный подход для production: CONFIG_SPIRAM_USE_CAPS_ALLOC CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL WiFi/LWIP → в PSRAM Стек, DMA → внутренняя RAM Это даёт предсказуемую производительность. 11. ИтогPSRAM — это: дешёвый способ расширить RAM возможность работать с графикой и ML разгрузка внутренней памяти Но: – всегда медленнее внутренней SRAM – требует грамотной конфигурации – может вызывать проблемы когерентности Для серьёзных проектов рекомендуется: ESP-IDF ручное управление аллокацией контроль DMA-буферов резерв внутренней памяти -
LiDAR (Light Detection and Ranging) — это технология измерения расстояния с помощью лазерного излучения. Метод основан на регистрации времени пролёта лазерного импульса (TOF, Time of Flight) от источника до объекта и обратно к приёмнику. По сути, лидар — это высокоточный лазерный дальномер, формирующий трёхмерную модель окружающего пространства в виде облака точек. История технологииКонцепция лидара была предложена в 1930 году британским физиком Edward Hutchinson Synge, который рассматривал возможность исследования атмосферы с помощью мощных световых источников. Сегодня LiDAR широко применяется в: метеорологии, геодезии, автономном транспорте, сельском хозяйстве, робототехнике, космических исследованиях. Как работает LiDARПринцип работы включает несколько этапов: Генерация импульса Лазерный излучатель (часто 905 нм или 1550 нм) формирует короткий импульс света. Отражение от объекта Луч достигает поверхности (здание, автомобиль, дерево, человек) и отражается. Регистрация сигнала Отражённый свет фиксируется фотоприёмником. Расчёт расстояния Система измеряет время пролёта импульса и вычисляет расстояние по формуле: D=c⋅t2D = \frac{c \cdot t}{2}D=2c⋅t где: D — расстояние, c — скорость света, t — время между отправкой и приёмом импульса. Формирование облака точек Миллионы измерений объединяются в трёхмерную карту сцены. Основные компоненты лидараТиповая система LiDAR включает: лазерный модуль (часто VCSEL); оптическую систему (линзы, фильтры); фотоприёмник (SiPM или лавинный фотодиод); АЦП (аналогово-цифровой преобразователь); вычислительный модуль (FPGA, AI-процессор); систему сканирования. Типы лидаров1. Механические лидары (360°)Имеют вращающуюся платформу с излучателем и приёмником. Особенности: горизонтальный обзор 360° высокая точность сложная механика более высокая стоимость Применяются в автономных автомобилях и картографировании. 2. Твердотельные лидарыНе содержат вращающихся элементов. Сканирование выполняется с помощью MEMS-зеркал или фазированных решёток. Преимущества: компактность устойчивость к вибрациям меньшая стоимость высокая надёжность Широко применяются в ADAS, дронах и робототехнике. Методы измерения скоростиLiDAR может измерять скорость объектов: Доплеровский метод — по изменению частоты отражённого сигнала. Последовательные измерения — по изменению расстояния во времени. Используется для определения скорости: ветра, транспортных средств, движущихся объектов. Области применения LiDAR1. Автономный транспорт и ADASLiDAR — ключевой сенсор в системах автопилотирования. Пример промышленного внедрения — разработки компании Waymo и беспилотные проекты Яндекс. Функции: обнаружение препятствий распознавание пешеходов адаптивный круиз-контроль экстренное торможение удержание полосы 2. Геодезия и картографияАэро-лидары устанавливаются на самолёты и БПЛА. Используются совместно с: GPS инерциальными системами (IMU) Результат — цифровая модель рельефа (ЦМР). 3. Метеорология и атмосферные исследованияПозволяют измерять: аэрозольную нагрузку концентрацию метана параметры облаков скорость ветра интенсивность осадков 4. Сельское хозяйствоПрименение: построение топографии полей анализ зон урожайности обнаружение сорняков (с применением ML) навигация сельхозтехники без GPS мониторинг виноградников и садов 5. АрхеологияLiDAR позволяет выявлять объекты под густым лесным покровом. Пример — обнаружение древних сооружений в регионе Ла-Москития (Гондурас) и исследование древнего города Махендрапарвата. 6. КосмосЛазерная альтиметрия применяется для картографирования планет. Пример — марсианский альтиметр MOLA на орбитальном аппарате NASA. Также лидар используется при сближении космических аппаратов и посадке на поверхность. Российский рынок лидаровПроизводствоВ 2025 году компания Радар ММС запустила производство модулей воздушно-лазерного сканирования для автомобилей и дронов. ИсследованияВ 2022 году МТУСИ совместно с ИОФ РАН протестировали мобильный лидар в рамках научной установки беспроводной подводной лазерной связи. Мировой рынок LiDARАвтомобильный сегментПо данным Fortune Business Insights: 2024 год — $3,72 млрд 2026 год — $4,16 млрд прогноз к 2032 году — $9,54 млрд CAGR — 12,6% Крупные игроки: Luminar Technologies Valeo S.A. Innoviz Technologies Continental Aeva Technologies Ouster Hesai Technology RoboSense Рынок лидаров для смартфонов2023 год — $2,03 млрд 2024 год — $2,42 млрд прогноз к 2032 году — $10 млрд CAGR — 19,38% Рост обеспечен развитием AR/VR и мобильной съёмки. Преимущества и ограничения технологииПреимуществавысокая точность (до сантиметров) независимость от освещённости формирование 3D-моделей в реальном времени высокая дальность (до 300+ м) Ограничениячувствительность к погодным условиям высокая стоимость (для высокодальних систем) необходимость обработки больших массивов данных Перспективы развитияТренды отрасли: переход от механических к твердотельным решениям интеграция с AI снижение стоимости модулей рост применения в умных городах развитие FMCW-лидаров интеграция в потребительскую электронику -
Конденсаторы — обязательные компоненты большинства электронных устройств: от бытовой техники до промышленной автоматики. Они выполняют функции накопления и отдачи энергии, фильтрации помех, формирования частоты и сглаживания пульсаций напряжения. Во многих случаях отказ оборудования связан именно с неисправностью конденсатора. Поэтому важно понимать, как корректно проверить его работоспособность с помощью мультиметра и какие дефекты встречаются чаще всего. Что такое конденсатор и как он работаетКонденсатор — это пассивный электронный компонент, состоящий из двух проводящих обкладок, разделённых диэлектриком. Его ключевые параметры: Ёмкость (Ф, мкФ, нФ, пФ) — способность накапливать заряд Рабочее напряжение (В) — максимально допустимое напряжение Тип диэлектрика — влияет на стабильность и область применения Полярность — у некоторых типов строго соблюдается Основные виды конденсаторов1. По назначениюВысоковольтныеИспользуются в силовой электронике и высоковольтном оборудовании. Бывают керамические, масляные, вакуумные. Доступ к ним часто ограничен требованиями безопасности. ПусковыеПрименяются в электродвигателях для увеличения пускового момента. Подстроечные (переменные)Позволяют изменять ёмкость регулировкой положения подвижной пластины. ИмпульсныеФормируют короткие пики напряжения для передачи сигналов. Помехоподавляющие (X и Y-класса)Стабилизируют работу чувствительных устройств, подавляя электромагнитные помехи. 2. По типу диэлектрикаБумажные Плёночные Керамические Слюдяные Электролитические (алюминиевые, танталовые) Стеклокерамические Оксидно-полупроводниковые 3. По полярностиПолярныеЭлектролитические Танталовые Имеют маркировку минусового вывода. Нарушение полярности приводит к выходу из строя. НеполярныеКерамические Плёночные Слюдяные Не требуют соблюдения полярности при подключении. Типичные неисправности конденсаторов1. Короткое замыкание (КЗ)Причины: пробой изоляции превышение рабочего напряжения перегрев механические повреждения Симптом: сопротивление близко к нулю. 2. ОбрывПотеря электрического контакта с обкладкой. Ёмкость становится равной нулю. Часто встречается: в электролитических в помехоподавляющих Y-конденсаторах (конструктивно защищены от КЗ) 3. Потеря ёмкостиОсобенно характерна для электролитических конденсаторов из-за высыхания электролита. 4. Повышенная утечкаЭлемент не удерживает заряд. Часто наблюдается у: электролитических танталовых Подготовка к проверке мультиметромПеред измерениями необходимо: Отключить устройство от сети Разрядить конденсатор Замкнуть выводы металлическим предметом (для мощных — через резистор) Осмотреть корпус вздутие потёки трещины обугливание Определить полярность Выпаять элемент Проверка на плате часто даёт некорректные результаты из-за влияния других компонентов. Как проверить полярный (электролитический) конденсаторПроверка на КЗ или обрывРазрядить элемент Установить мультиметр в режим: «прозвонка» «сопротивление» Подключить: «+» к плюсу «−» к минусу Интерпретация результатов:Показание Диагноз 0 Ом Короткое замыкание 1 без изменений Обрыв Сопротивление растёт Исправен Рост сопротивления означает заряд конденсатора от батареи мультиметра. Как проверить неполярный конденсаторУстановить режим измерения сопротивления (МОм) Подключить щупы без соблюдения полярности Результат:Более 2 МОм → исправен Менее 2 МОм → вероятна неисправность Проверка на короткое замыканиеВ режиме прозвонкиЕсли мультиметр постоянно издаёт звуковой сигнал — присутствует КЗ. В режиме сопротивленияСопротивление близкое к 0 Ом — короткое замыкание. Проверка на обрывМетод 1 — прозвонкаКратковременный щелчок → исправен Отсутствие реакции → возможен обрыв Метод 2 — измерение сопротивленияНа максимальном диапазоне сопротивление должно плавно увеличиваться. Проверка остаточного напряженияСамый чувствительный способ: В режиме сопротивления зарядить конденсатор 2–3 секунды Переключить мультиметр на измерение постоянного напряжения Подключить снова Если прибор показывает остаточное напряжение — элемент исправен. Подходит для большинства типов, кроме сверхмалых ёмкостей (<470 пФ). Как измерить ёмкость мультиметромЕсли прибор имеет функцию измерения ёмкости: Выбрать режим Cx Установить диапазон Подключить выводы Сравнить значение с номиналом Допустимое отклонение обычно: ±5–20% для большинства типов ±10% для электролитических Проверка пускового конденсатораОбесточить оборудование Выпаять и разрядить элемент Измерить ёмкость Сравнить с номиналом Если расхождение превышает допустимое — требуется замена. Проверка керамического конденсатораКерамические — неполярные. Режим измерения сопротивления Предел — МОм Показание >2 МОм → исправен Для точной оценки ёмкости нужен специализированный прибор. Можно ли проверять без выпаивания?В большинстве случаев — нет. Причины: параллельные цепи искажают показания диоды и транзисторы могут симулировать КЗ измеряется суммарная ёмкость Допустимо проверять: электролитические >1 мкФ только на КЗ или обрыв Для точной диагностики рекомендуется выпаивание. Когда лучше заменить, чем проверять?Если наблюдаются: вздутие утечка электролита сильный перегрев значительное отклонение ёмкости В таких случаях замена быстрее и надёжнее ремонта. ВыводПроверка конденсатора мультиметром — эффективный способ диагностики короткого замыкания, обрыва и грубых отклонений ёмкости. Для точных измерений малых ёмкостей и оценки ESR требуется специализированное оборудование.
