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

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

Утилита pg_dump может делать дампы в трёх форматах - plain, custom, directory. Plain - обычный текст. Самый медленный формат, но самый удобный в плане дальнейшей работы с ним. Из него можно вытащить отдельную таблицу, проверить какое-то содержимое, обрезать и т.д. По умолчанию он вообще не сжимается. Сжатие можно добавить настройкой pg_dump или через пайп пропустить.

Формат custom - это уже бинарный дамп. Он жмётся по умолчанию. При сопоставимых настройках сжатия по скорости он +- такой же, как palin. Это наиболее популярный формат для дампов, так как из него можно восстанавливаться в несколько потоков, что значительно быстрее формата plain. Тот в восстановлении очень медленный.

Формат directory я вообще никогда не использовал. На первый взгляд он выглядит не очень удобным для обработки и длительного хранения. Но у него есть важное отличие - процесс создания дампа может быть многопоточным. И это серьёзно ускоряет его, если у вас все данные не лежат в одной большой таблице, так как создание параллелится на уровне таблиц. Я у себя потестировал на сервере с 16 ядрами дампить в 10 потоков. Прирост скорости примерно в 2 раза при одинаковых настройках сжатия по сравнению с plain и custom. То есть на ровном месте ускорил снятие дампов в 2 раза.

# sudo -u postgres /opt/pgpro/1c-15/bin/pg_dump -U postgres -Fd -Z6 -j10 -f /tmp/zup-baza01 zup-baza01

Почитал документацию и увидел параметр --compress=method[:detail]. По умолчанию используется сжатие gzip с уровнем компрессии 6, этот параметр его может изменить. Мне не особо критично сильно сжимать. Хотел ещё ускорить процесс и заменить медленный gzip на lz4 или zstd. И так, и сяк указывал параметры - ничего не помогает. Пишет, что неверное значение параметра. Сразу у ИИ спрашивать не стал, думал, уж с такой простой задачей справлюсь сам. Но увы, не справился.

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

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#postgresql #backup

Хотите стать пентестером и предотвращать кибератаки? 👀

Запишитесь на курс «Профессия Пентестер» от Академии Кодебай! Стартуем 25 мая — регистрация здесь.

Что вы получите?
🔸 Научитесь атаковать сети, WEB-сайты, ОС и устройства и проводить внутренний и внешний пентест
🔸 Освоите полный цикл пентеста: от Kali Linux до написания эксплойтов и обхода антивирусов.
🔸 Сможете участвовать в Bug Bounty программах или построить карьеру в информационной безопасности

Полный цикл обучения:
⌨️ от освоения Kali Linux и администрирования, до написания эксплойтов и шелл-кода, обхода антивирусных решений
⌨️ от сетевой разведки до эксплуатации уязвимостей, повышения привилегий и закрепления в сети

Присоединяйтесь к Академии Кодебай – защищайте мир от угроз, находя уязвимости и предотвращая кибератаки!

Подробнее о курсе📵

Реклама, АНО ДПО «Академия цифровой защиты», ИНН 9706049526.

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

Я в основном сейчас использую 2 нейросети:

▪️Бесплатный Qwen для быстрых вопросов и поиска в интернете.
▪️Платный z.ai в режиме агента в opencode. Мне очень нравится, как он работает. Делал ещё один заход в openclaw, но опять не пошло. Не нравится он мне. На очереди claude agent, но не хватает времени на него, чтобы плотно заняться.

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

Я не так давно пересобрал один старый системник, который работал как обычный рабочий комп под виндой. Воткнул в него все старые диски, что лежали без дела и стал туда свои бэкапы лить. Кстати, посмотрел стоимость дисков сейчас 😱 Они пипец как подорожали. Всё моё б.у.шное барахло, что я туда воткнул, потянуло на 100 т.р.

Системник был на 100% рабочий, проблем с ним не было. Я его продул, обновил термопасту, воткнул диски, накатил PVE. Какое-то время он поработал и начал аварийно перезагружаться без каких-либо видимых причин. Явных ошибок в логах нет, тем более перед ребутами. Ничего подозрительного не видно.

Решил скормить syslog нейронкам, чтобы они там покопались и вынесли свой вердикт. Заморачиваться не стал, отдал в opencode весь лог на 12 МБ и попросил проверить. Он нашёл там некоторые моменты, типа ошибок в SMART одного из дисков и ошибки сетевой карты Realtek. Это известная тема, они глючат в Linux, и в PVE в частности. Я уже писал об этом не раз (1, 2). Сталкивался много раз с этим, но к аварийным перезагрузкам это никогда не приводило. Вряд ли в этом дело.

Это днём было, а вечером я вайбкодил и решал некоторые задачи. Зашёл в статистику по токенам и заметил, что днём куда-то 1,1 млн. токенов улетели. Это не сказать, что много, но лично у меня незаметно столько не улетает. Задачи относительно простые и короткие. Потом уже сообразил, что это анализ лога столько сожрал.

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

В итоге агенты дали два разных решения. Первый сказал, что виноват диск, надо его отключить. Второй предложил установить другой драйвер на сетевуху, обвинив его в ребутах. Ни то, ни другое не помогло. Причина не в этом. Скорее всего просто железо устало. Материнка старая (14 лет), пора в утиль. Хотя под виндой работала стабильно. Может просто совпадение и время пришло именно сейчас, а может реально с современным линуксом у этого железа какой-то конфликт.

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

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#ai

Небольшой совет из практики настройки мониторинга, а конкретно - графиков. Если используете классический график с осями координат, следите за тем, чтобы отсчёт был от нуля. В подавляющем большинстве случаев вам будет полезен именно такой график, начинающийся от нуля. Это актуально как для Grafana, так и Zabbix.

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

Ниже пример, когда слева - настройки осей по умолчанию в Zabbix, автовычисляемые значения, а справа я выставил вручную ограничения от 0 до 100, что соответствует минимальному и максимальному значению. Визуально по правым графикам проще оценить реальную итоговую загрузку CPU и Memory на узле, которая по факту очень ровная, но по графикам слева так сразу не скажешь.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#мониторинг #совет