Заметка выходного дня. Прослушал старую песню времён блокировок Telegram от группы Дореволюционный советчик. Удивительно, как получилось. В наши дни эта песня стала актуальна даже больше, чем в то время, когда записывалась. Это своего рода гениальность и заявка на классику.

Например, за репосты раньше чисто гипотетически можно было пострадать, а сейчас готова полноценная юридическая база под это дело. Есть реестр блогеров с 10к+ подписчиками. Если какой-то канал не добавил себя в этот реестр, то репостить его публикации нельзя. Какие там ссанкции уже не помню, но они чётко обозначены без неоднозначных толкований.

Ожидаем блокировки Вотсапъ и Порнхабъ. Пишу, кстати, из деревни, VPN включен. У песни отличное исполнение и текст. Мне очень нравится.

Которыя сутки не грузитъ страницы, 
Процессоръ скрипитъ, словно старый сарай. 
Настройте же прокси, креаторъ Голицынъ, 
Админъ Оболенскій, раздайте вай-фай.

Сидятъ черезъ SOCKS баринъ и пролетарій - 
Народъ на Руси оказался непростъ, 
Но въ чатахъ публичныхъ не спятъ комиссары, 
И могутъ тебя посадить за репостъ.

Но какъ же намъ, право, безъ дѣвичьей ласки, 
Безъ теплыхъ эмодзи, шальныхъ телеграмъ? 
Манагеръ Голицынъ, а можетъ быть въ Аську?
Генъ. диръ. Оболенскій, давайте въ ТАМЪ-ТАМЪ.

Сатрапы режима, холопы системы
Заблочатъ Вотсапъ и закроютъ Порнхабъ, 
Куда теперь постить забойные мемы
И кто проорётся съ моихъ фотожабъ…

Сидимъ съ VPN-номъ въ глухой деревенькѣ. 
На синемъ экранѣ сіяютъ скрипты. 
Предатель Голицынъ раздайте печеньки,
Масонъ Оболенскій, пишите посты.

#юмор

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

Есть MySQL сервер, у которого, как мне показалось, очень большая нагрузка по CPU. Проект немного стух, записи в базу должно быть мало и мне было странно видеть высокую нагрузку от СУБД. Решил разобраться, в чём там дело.

Для начала просто посмотрел нагрузку через top. Mysql почти постоянно кушает одно ядро и периодически остальные дёргает. Дополнительно смотрю в iotop и pidstat и вижу постоянно запись со стороны службы mysqld с pid 19535:

# iotop -obPat
# pidstat -p 19535 -d 1

В таких случаях часто помогает strace. Можно подцепиться к процессу и посмотреть, что он пишет:

# strace -e trace=write -p 19535

В моём случае я не получил результата. В выводе просто было пусто. Я не понял, почему. Стал разбираться дальше. Смотрю потоки процесса:

# ps -L -o spid,%mem,%cpu,cmd 16005

Вижу, что CPU нагружает сильно больше всех остальных один поток с SPID 19547. Смотрю по нему информацию:

# cat /proc/19535/task/19547/stat
# cat /proc/19535/task/19547/status

В выводе только цифры и отсылка к основному потоку mysqld. То есть вообще не понятно, что там реально происходит.

Тут до меня доходит подцепиться к потоку через strace:

# strace -p 19547

Вижу системные вызовы futex (синхронизацией потоков), io_submit (асинхронные операции ввода-вывода) и некоторые другие.

Смотрю, в какие файлы пишет mysqld:

# inotifywait -m /var/lib/mysql

Это ib_logfile0 и xb_doublewrite. Никак не могу понять, почему он туда активно пишет, когда запросов к базе особо нет. И вот тут я как раз и затупил. Я смотрел запросы через mytop и SHOW FULL PROCESSLIST; И там их было очень мало. Эти команды показывают запросы в моменте.

А на серваке выполнялись десятки простых SELECT за считанные миллисекунды или ещё быстрее. Не отслеживал. И они тупо не попадали в вывод. И я думал, что запросов мало, а их было дохрена. Они и давали нагрузку на CPU.

Запросы увидел так. Не перезапуская сервер выполнил в консоли mysql:

> SET GLOBAL general_log = 'ON';
> SET GLOBAL general_log_file = '/var/log/mysql/general.log';

Так же это было видно в выводе:

> SHOW ENGINE INNODB STATUS;

В разделе I/O. Эти потоки отвечают за асинхронные операции ввода-вывода (AIO).

Достаточно было на несколько секунд запустить, чтобы понять всю картину. Потом сразу отключил, чтобы не нагружать диски.

Осталось разобраться, а что на диск то записывается. Вроде как файлы ib_logfile0 это файлы журналов транзакций InnoDB, а разве SELECT вызывает транзакции? Я тут сильно не погружался, но мельком глянул информацию и понял, что всякие очистки устаревших данных, обновление статистики, индексов, хэшей могут тоже провоцировать запись, а точнее обновление этого файла.

xb_doublewrite - это некий буфер InnoDB для повышения надёжности хранения, отключать не рекомендуется, хотя можно.

В общем, время я по сути потратил впустую, если не считать вот эту заметку итоговым результатом. Думаю, она мне ещё понадобится. Времени уже не оставалось дальше разбираться с этой историей. В целом, нагрузка там рабочая, абсолютно некритичная, так что разбираться с ней дальше большой нужды не было. Но я всё равно планирую подумать, как её снизить. И вообще не совсем понятно, почему её так много, с учётом того, что сайт активно кэшируется. Надо будет разбираться.

Отдельно отмечу, что очень активно нагружал этой темой DeepSeek, но он особо не помог. Да, много всякой информации давал и анализировал мои результаты, но фактически я сам догадался в чём причина. Он как-то больше по кругу ходил и всякие команды накидывал.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#mysql #perfomance

Продолжаю пересматривать старые заметки. Нашёл показательную новость от 2020 года, которую скорее всего все уже позабыли.

⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3

Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.

И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.

К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.

Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.

На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.

#совет #security

Хочу сделать предостережение, основанное на личном опыте. Делал рядовое обновление сервера, которое требовало перезагрузку. Сервер далеко, в необслуживаемой серверной. То есть там никого нет вечером, кто смог бы хоть что-то сделать. Как обычно, время выбрал позднее, так как на сервере полезная нагрузка. Его активно используют люди в течении рабочего дня. И кто бы мог подумать, что сервер не выйдет из перезагрузки. 

Нет проблем. Сервер Supermicro, там IPMI, сейчас посмотрим консоль и поймем, в чём там дело. И тут начинаются танцы. Сервер старый, версия BMC древняя. Для подключения к консоли нужна java какой-то старой версии. Апплет не запускается, так как блочится настройками безопасности из-за отсутствия сертификата и актуальной версии TLS. В общем, мрак. Думаю тем, кто используют старые Supermicro, хорошо знакома эта тема. Я давно их не покупаю. Если брать б.у., то предпочту Dell. Там BMC удобный.

Проблемы в итоге решил, подключился и всё сделал. А мораль тут такова –  перед перезагрузкой сервера, проверьте, есть ли у вас доступ к консоли, так что для меня reboot – это всегда потенциальная возможность потерять доступ к серверу. Обязательно проверяю бэкапы перед этим и доступ к консоли сервера. И всегда держу в голове схему, что я буду делать, если сервер не поднимется. А после установки обновления это не такая уж и большая редкость. Я столько всяких историй проходил. Было много примеров, некоторые описывал в статьях:

◽️Yum после обновления упал с ошибкой и не пересобрал initramfs под новое ядро. Спасла загрузка на старом.
◽️У сервера уменьшили на лету размер корневого раздела. После перезагрузки grub его потерял.
◽️Как-то раз просто на всякий случай зашёл в админку хостера проверить, есть ли доступ к консоли. А её не оказалось, просто чёрный экран. Через техподдержку решили вопрос. Был глюк.
◽️У GRUB2 как-то раз вышло обновление, которое приводило к невозможности загрузки.
◽️Как-то раз сервер с большим диском запустил проверку файловой системы во время загрузки. Длилась она пару часов. Останавливать не решился, сидел и ждал, чем закончится. Причём счетчика времени не было. Думал уже что всё, данным кирдык.
◽️Один хостер с арендным сервером высылал доступ к консоли по VNC в момент оформления. Заказчик благополучно всё это где-то потерял, а когда нужно было срочно подключиться, пришлось искать и восстанавливать эти доступы через тех. поддержку. А для этого ещё и VPN настраивать надо было.

Это только то, что бегло вспомнил. Были и другие истории. Если сталкивались с чем-то подобным, то поделитесь своими инцидентами. Можно будет подборку сделать. Мне кажется, их может много набраться.

#совет

Хочу сделать дополнение по мотивам заметки про УПС и проблемы с электричеством. Тема живая получилась. Смотрю, многие сталкивались со схожими проблемами. Сразу забыл написать, а сейчас вспомнил. У меня был необычный опыт в своё время, которым хочу поделиться. Кому-то возможно поможет, если придётся с похожей проблемой столкнуться.

На одном производстве была серверная стойка. В результате серьёзных проблем поблизости надолго обесточили. Речь шла о недели, поэтому решили стойку и остальных потребителей запитать от генераторов. Заранее к подобному не готовились, поэтому набрали обычных генераторов, которые вдвоём-троём таскать можно. Условно бытовые.

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

Пришлось принять решение запустить всё напрямую. Очень боялся за сервера, но на практике с ними ничего не случилось. Всю неделю благополучно отработали от генератора. Когда вернули электричество, переключил на УПС.

Уже позже было любопытно разобраться в этой теме. Поспрашивал электриков, плюс где-то обсуждение на форуме видел. Дело в качестве синуса, или частоты, которую выдаёт генератор. В УПСах чётко прописаны требования по частоте к току в сети. Если частота плавает, синус кривой, то он не запустится. А от бытовых генераторов синус как раз и кривой. То есть выходные параметры электрического тока от генератора не соответствуют требованиям УПСов, поэтому они не включаются.

У большинства электроприборов таких жестких требований к току нет, поэтому они работают. И хотя формально в характеристиках выходного тока генератора и входного тока УПСа могут быть полные совпадения, на деле обычный генератор синус даёт кривой.

Один из наиболее доступных и простых способов решения проблемы – повесить на генератор какую-то постоянную стабильную нагрузку. Например, обогреватель на 1-2 кВт·ч. Это не обязательно, но может помочь выровнять частоту.

На некоторых УПСах отдельно предусмотрена поддержка генераторов. Там есть режим работы от генератора. Шансы того, что УПС заработает от генератора, повышаются, но всё равно не являются стопроцентными. Сам генератор может быть банально хреновым. Если где-то у вас есть для подстраховки генератор и используются УПСы, то лучше заранее проверить, будут ли они от него работать.

Эта проблема, кстати, актуальна и для загородных домов, где часто есть генератор в резерве, а дома некоторая критичная нагрузка, типа насоса или котла, запитана от УПСов.

#железо

Совет-предостережение насчёт systemd, монтирования дисков и некоторых облачных провайдеров. Ситуация, с которой сталкивался сам, а потом встречал ещё не раз. Если не ошибаюсь, последний раз такой механизм видел у хостера Linode.

В Linux есть служба systemd-mount, о которой я уже ранее писал. Хостер может её использовать для автоматического подключения сетевых дисков с разными параметрами. В целом это удобно и для него, и для пользователя. У меня был подключен в точку монтирования один такой диск. Я решил увеличить его в объёме и выбрать более производительный.

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

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

Идут постоянные попытки от systemd отмонтировать раздел, к которому подмонтирован уже НОВЫЙ диск. То есть у него записано где-то (я нашел в /run/systemd/generator), что к этой точке монтирования подключен старый диск. Софт хостера по управлению ресурсами просит systemd отключить старый диск от его точки монтирования, хотя по факту она уже занята другим диском.

Я в итоге не пострадал, так как приложение активно писало на диск и не дало его отмонтировать. Диск удалился без размонтирования. В таких случаях лучше новые диски монтировать в другие точки монтирования, а у приложений менять путь к рабочей директории. Это хоть и более хлопотно, но надёжнее, чем разбираться с тем, как хостинг монтирует и отключает диски.

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

Вчера была рассылка от Mikrotik. Я последнее время их игнорирую, так как продукция явно потеряла былую популярность в России в первую очередь из-за цен. Хотя близких аналогов нет, всё равно Микротики уже не так популярны. Но мимо вчерашней новости не смог пройти мимо, потому что она меня удивила.

Компания выпустила свой сервер - RouterOS enterprise Data Server со следующими характеристиками:

◽️20 слотов под U.2 NVMe диски, с поддежкой M.2
◽️сетевые порты: 2×100G QSFP28, 4×25G SFP28, 4×10G SFP+, 2×10G Ethernet
◽️16-core 2 GHz ARM CPU + 32GB DDR4 RAM

Внутри, как и ожидается – RouterOS в редакции Special ROSE edition с поддержкой в том числе технологии NVMe-TCP для экспорта дисков другим серверам. Это помимо традиционных SMB, NFS, iSCSI.

Компания позиционирует свой сервер как очень быстрое локальное хранилище под нагрузку, запущенную в контейнерах, которые RouterOS 7 поддерживает уже сейчас. В описании явно указаны примеры применения: MinIO, Nextcloud, Shinobi, Frigate и другие.

Неожиданная новинка. Цена всего $1950, что намекает на сегмент малого и среднего бизнеса. И при этом такие скорости, которые там особо не нужны.

Что думаете по поводу этих серверов? Мне кажется, зря они в сервера подались. Лучше бы на сетевых устройствах сконцентрировались, починили баги RouterOS 7, запустили бы наконец Long Term ветку. Представляю, сколько вылезет багов в системе на этом сервере, особенно в работе контейнеров под нагрузкой. Там инструментов для диагностики почти нет, работать с ними неудобно. Я бы не стал.

#mikrotik

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

Звонят сисадмину, но он почему-то не хочет помогать. Нанимают нового, но он ничего не знает, потому что никто не передал дела. Я так пришёл в одну компанию, где сисадмин уволился пару месяцев назад и там его помощник выживал, как мог. Но у него ни доступов, ни понимания, как тут всё работает, не было. Ни желания что-то делать за свою зарплату и должность помощника. Благо хоть учётки у директора были. Админа не стал дёргать, во всём без него разобрался.

Иногда мне пишут люди и просят помочь с какой-то проблемой, потому что сисадмин уволился и никто не знает, что делать. Я не берусь за такие задачи, обычно сразу отказываю. Не хочу связываться с такими делами. Это гарантированно бесконечные поиски информации и подводные камни в решении проблем.

Видео отсюда: https://www.youtube.com/shorts/8ooaojqQ70w
Прикольный, кстати, канал. Вроде ничего особенного, но некоторые вещи забавные.

#юмор (чёрный)