Стабильность важнее скорости: №5 обходит №15 на длинной дистанции
Предисловие:
Исследование настройки checkpoint_timeout в PostgreSQL принесло неожиданные результаты. Вместо привычного представления о «золотой середине» выяснилось, что более частые контрольные точки дают системе не пиковую скорость, но что гораздо важнее — стабильность и предсказуемость. Этот отчёт расскажет, почему для современных OLTP-систем иногда лучше быть «умеренным, но постоянным», чем «быстрым, но с провалами».
Операционная скорость СУБД
Сравнительный график операционной скорости СУБД для значений checkpoint_timeout = '15m' и checkpoint_timeout = '5m'
Основные выводы исследования
1. Производительность: пики vs стабильность
При checkpoint_timeout = 15 минут: Система показывает высокую пиковую скорость (до 2,38 млн операций), но страдает от резких провалов — вплоть до 140 операций. Это похоже на гоночный автомобиль, который то резко ускоряется, то неожиданно тормозит.
При checkpoint_timeout = 5 минут: Пиковая скорость ниже (1,98 млн операций), но минимальная — в 4,6 раза выше. Система работает ровно, без глубоких провалов, что критически важно для отзывчивости приложений.
2. Влияние на загрузку системы
CPU и память: Обе настройки нагружают процессор и память почти одинаково, но при 5 минутах нагрузка распределяется равномернее. Очередь процессов становится предсказуемой, а риск перегрузки планировщика снижается.
Диски: Дисковая подсистема в обоих случаях не была узким местом. Однако при 5 минутах запись данных происходит чаще, но мелкими порциями — это снижает пиковую нагрузку на накопители.
3. Паттерны ожиданий и блокировок
Блокировки (Locks): Остаются основной проблемой в обоих сценариях, но при 5 минутах их влияние на общую производительность становится менее значимым.
Буферные конфликты (BufferMapping): Уменьшение интервала контрольных точек снизило количество конфликтов на 50% — система стала эффективнее управлять кэшем.
4. Рекомендация по умолчанию
Для большинства рабочих OLTP-систем рекомендуется значение checkpoint_timeout = 5m. Оно обеспечивает:
✅ Стабильное время отклика
✅ Отсутствие резких провалов производительности
✅ Равномерную нагрузку на диск и память
✅ Быстрое восстановление после сбоя
5. Когда можно выбрать 15 минут?
Более длинный интервал может быть оправдан в системах:
С преимущественно чтением данных
С избыточной мощностью дисковой подсистемы
Где допустимы периодические замедления в обмен на немного более высокую пиковую скорость
Заключение
Настройка checkpoint_timeout — не просто технический параметр, а инструмент балансировки между скоростью и надёжностью. Частые контрольные точки (5 минут) делают PostgreSQL предсказуемым, устойчивым к нагрузкам и готовым к работе в реальном времени. Как показало исследование, в долгой гонке стабильность часто важнее единичных рекордов скорости.
Оптимизируйте с умом, тестируйте на своих нагрузках — и ваша база данных будет работать как швейцарские часы.
В старых руководствах по настройке PostgreSQL можно встретить почти ритуальную рекомендацию: увеличь checkpoint_timeout до 30 минут для повышения производительности. Десятилетиями этот совет кочевал из блога в блог, став аксиомой для многих администраторов. Но времена изменились. Современные диски, новые версии СУБД и свежие экспериментальные данные заставляют пересмотреть догмы. Эта статья рассказывает, почему старая оптимизация была логичной для эпохи HDD, как парадигма сменилась с приходом SSD и почему сегодня, вопреки устаревшим сборникам рецептов, checkpoint_timeout = '5m' с правильной дополнительной настройкой оказывается лучшим выбором для стабильности и производительности.
---------------------------------------
Вопрос нейросети
на чем основана старая рекомендация, вошедшая в сборники рецептов, о целесообразности увеличения checkpoint_timeout для PostgreSQL ?
Ответ нейросети DeepSeek
Старая рекомендация увеличивать checkpoint_timeout (например, до 30 минут) была популярна в эпоху, когда дисковые подсистемы были значительно медленнее современных. Она была основана на стремлении минимизировать негативное влияние частых контрольных точек на производительность системы.
🛠 В чем была суть старой рекомендации?
Основная идея заключалась в следующем:
Снижение частых пиков нагрузки на ввод-вывод (I/O): Контрольная точка — это дорогостоящая операция, при которой все измененные данные ("грязные" страницы) из оперативной памяти записываются на диск. Если она происходит слишком часто (по умолчанию раз в 5 минут), это может создавать периодические пиковые нагрузки на диск, что особенно заметно на медленных HDD. Увеличение интервала между контрольными точками позволяет снизить эту частоту.
Экономия ресурсов WAL: При включенном параметре full_page_writes (по умолчанию — включен) меньший интервал между контрольными точками увеличивает объем записи в журнал предзаписи (WAL). Более редкие контрольные точки теоретически могли сокращать этот дополнительный объем.
🔄 Как изменился современный подход?
Со временем понимание настройки контрольных точек эволюционировало. Сегодня фокус сместился с простого увеличения checkpoint_timeout на комплексную настройку и балансировку нескольких параметров.
Ключевая роль max_wal_size: Сейчас именно этот параметр чаще всего является основным триггером для запуска контрольной точки. Контрольная точка сработает, когда будет сгенерирован объем WAL, приближающийся к значению max_wal_size, — даже если не прошло времени, заданного в checkpoint_timeout. Поэтому настройка max_wal_size стала более приоритетной.
Распределение нагрузки во времени: Для сглаживания дискового ввода-вывода во время контрольной точки используется параметр checkpoint_completion_target (по умолчанию 0.9). Это означает, что сервер старается растянуть запись данных почти на весь интервал между контрольными точками, избегая резких всплесков активности.
Компромисс с восстановлением: Главным недостатком увеличения checkpoint_timeout является рост времени восстановления после сбоя, так как системе потребуется обработать больше журналов WAL. Современные рекомендации всегда учитывают этот компромисс между производительностью при записи и скоростью восстановления (RTO).
Ключевые современные принципы:
Не трогать без необходимости: Не увеличивайте checkpoint_timeout вслепую, следуя устаревшим советам.
Настройка max_wal_size: Увеличивайте max_wal_size так, чтобы контрольные точки в вашей рабочей нагрузке в основном срабатывали по времени (checkpoint_timeout), а не по достижению лимита размера WAL.
Мониторинг предупреждений: Если в логах сервера часто появляется предупреждение от checkpoint_warning, это прямой сигнал к увеличению max_wal_size.
Учет аппаратуры: На системах с быстрыми SSD-дисками негативный эффект от частых контрольных точек гораздо меньше, что делает старые рекомендации еще менее актуальными.
📊 Старая практика vs. Современный подход
Чтобы наглядно увидеть разницу, вот как изменились ключевые акценты в настройке:
Старая практика (упрощенный подход) Основная цель: Избежать пиковой нагрузки на I/O любой ценой. Главный параметр: Значительное увеличение checkpoint_timeout (напр., до 30-60 мин). Риски: Длительное восстановление после сбоя, потенциальный перерасход места под WAL. Контекст: Эпоха доминирования медленных HDD.
Современный подход (сбалансированный) Основная цель: Сбалансировать нагрузку на I/O и время восстановления (RTO). Главный параметр: Настройка max_wal_size в соответствии с реальной нагрузкой. Риски: Сведены к минимуму при корректной настройке группы параметров. Контекст: Быстрые SSD, акцент на наблюдаемость и сбалансированность.
Таким образом, если вы видите в старых руководствах рекомендацию просто выставить checkpoint_timeout = '30min', стоит воспринимать ее как исторический артефакт.
Современная эффективная настройка требует понимания работы связки checkpoint_timeout / max_wal_size / checkpoint_completion_target и мониторинга статистики контрольных точек в вашем конкретном окружении.
но ведь логично, что эффективнее в процессе выполнения checkpoint писать блоки на диск маленькими порциями но чаще , чем писать редко но огромный объем блоков ? Ведь во втором случае нагрузка на IO будет существенно выше в любом случае , дале для медленных дисков.
Ответ нейросети DeepSeek
Вы задаете абсолютно правильный и очень глубокий вопрос. Ваша логика безупречна с точки зрения равномерного распределения нагрузки, и для современных систем она является основополагающей. Однако старая рекомендация родилась в специфических исторических условиях, где эта логика сталкивалась с другими, более жесткими ограничениями.
Давайте разберем, почему ваше утверждение верно в идеале, но почему в прошлом от него отходили.
✅ Ваша логика (современный идеал)
"Часто и понемногу" — это принцип, на котором построена современная настройка checkpoint_completion_target = 0.9. Именно этот параметр заставляет PostgreSQL растягивать запись "грязных" страниц почти на весь интервал между контрольными точками (90%), что обеспечивает максимально равномерную нагрузку на диск. Это прямо противоположно "редко и много".
❓ Почему же тогда ставили огромный checkpoint_timeout?
Это был вынужденный компромисс, обусловленный тремя ключевыми факторами:
1. Катастрофическая стоимость случайных операций записи на HDD. Представьте, что система в фоне постоянно понемногу записывает страницы. Эти страницы разбросаны по всему объему данных. Для HDD с его механической головкой это означало постоянные и крайне затратные "скачки" по всей поверхности диска для поиска нужных блоков. Это убивало производительность всех других операций (SELECT, INSERT, UPDATE), которые в этот момент пытались работать с диском. Лучше было отложить эту работу и выполнить ее одним большим, но последовательным сливом — так голова диска двигалась меньше.
2. Роль кэша операционной системы. Когда PostgreSQL пишет данные, они сначала попадают в кэш ОС. При частой фоновой записи эти "грязные" страницы из кэша ОС постоянно сбрасывались бы на физический диск, мешая другим процессам. Большой интервал позволял накопить изменения в кэше и записать их более управляемым блоком.
3. Влияние на другие фоновые процессы. На старых системах с ограниченными ресурсами параллельные фоновые процессы (например, autovacuum) активно конкурировали за дисковый I/O. Периодическая, но предсказуемая мощная нагрузка от контрольной точки была часто предпочтительнее постоянного "фонового шума", который мешал всем остальным операциям все время.
🆚 Прямое сравнение двух стратегий
Давайте представим это наглядно:
Стратегия: "Редко, но много" (старый подход с checkpoint_timeout=30min)
Нагрузка на I/O: Огромные пики каждые 30 минут. Диск "задыхается" на несколько минут.
Время отклика системы: Плохое только во время пика. В остальное время — стабильно хорошее.
Поведение диска (HDD): Запись большими последовательными блоками (эффективнее для механики).
Поведение диска (SSD): Не имеет значения, но пиковая нагрузка все равно создает задержки.
Время восстановления (RTO):Катастрофически долгое (необходимо прочитать 30 минут WAL).
Стратегия: "Часто и понемногу" (современный подход с checkpoint_completion_target=0.9)
Нагрузка на I/O: Постоянная, ровная, предсказуемая фоновая нагрузка.
Время отклика системы: Стабильно хорошее, без резких провалов.
Поведение диска (HDD): Постоянный "шум" из случайных операций (неэффективно).
Поведение диска (SSD): Идеально, SSD отлично справляется с параллельными операциями.
Время восстановления (RTO):Минимальное (необходимо прочитать всего 5 минут WAL).
🧠 Итог: Почему парадигма изменилась
Ваш вопрос попадает в самую суть. Старая рекомендация была не логичной с точки зрения идеала, а прагматичной — с точки зрения выбора меньшего из зол в условиях старых HDD-систем.
Переход на стратегию "часто и понемногу" стал возможен и правилен благодаря:
Распространению SSD: которые не имеют механических задержек и одинаково хорошо обрабатывают как последовательные, так и случайные операции.
Появлению и правильной настройке checkpoint_completion_target: который реализует эту идею на уровне СУБД.
Росту объема памяти: что позволяет кэшировать больше данных без необходимости их немедленной записи.
Таким образом, вы абсолютно правы: современный подход эффективнее. Старая же рекомендация была адаптацией к несовершенству железа, где редкий, но сокрушительный удар по диску считался меньшим злом, чем его постоянная, мучительная "тряска".
Как размер тестовой базы данных pgbench влияет на производительность СУБД при проведении нагрузочного тестирования с использованием pgbench в качестве инструмента создания нагрузки ?
Ответ YandexGPT:
Таким образом, размер тестовой базы данных существенно влияет на производительность СУБД при нагрузочном тестировании с использованием pgbench. Увеличивая размер базы, можно наблюдать снижение производительности из-за роста времени обработки данных. Важно учитывать все параметры конфигурации и детали окружения для точного анализа и воспроизводимости тестов.
Ответ ChatPPG:
Таким образом, увеличение размера тестовой базы данных может привести к снижению производительности и количества транзакций в секунду, что важно учитывать при настройке и интерпретации результатов тестирования с использованием pgbench.
Ответ DeepSeek:
### 2. **Конфликты доступа (Contention)** - **Маленькая база**: Выше вероятность конфликтов при параллельных обновлениях (например, в таблицах `accounts`). Это увеличивает время ожидания блокировок и снижает пропускную способность. - **Большая база**: Данные распределены по большему числу строк, что снижает конкуренцию за одни и те же записи. Это особенно важно для тестов с высокой долей операций `UPDATE`.
...
Оптимальный размер тестовой базы зависит от целей тестирования. Для оценки максимальной производительности подходит маленькая база, а для имитации реальной нагрузки — база, сопоставимая с продакшеном по объему и структуре.
Приветствую уважаемые Друзья, читатели, коллеги. Поработал я со средой Дракон++.
В двух словах Дракон++ - это графический Алгоритмический язык программирования. Его задача строить понятные структурные алгоритмы работы соответствующих узлов, линий, теплиц, умных зданий, станков и т.д. и конвертировать их в код ПК, ПЛК или ПР.
Пока сама программная среда на стадии разработки. Но есть уже рабочие объекты и можно получить код программы.
Среда. Начало.
Возьмем простой пример Счетчика, делать его код будем для программируемого реле ОВЕН ПР 225.
Начинаем. Будем считать, что всё установили.
Создаём проект.
Называем, выбираем Программируемое реле ОЛ.
Не буду писать подробное руководство, его можно найти по ссылкам выше. Напишу коротко Класс объекта - ЭТО Функциональный блок на ST в ОВЕН ПР225.
Нажимаем Плюсик.
Получаем вот это.
Жмем сюда, и добавляем все необходимые нам переменные (локальные, входные, выходные)
Тут четыре типа переменных (Bool, Uint, Real, Time)
Вот так отображается.
Чтоб добавить ветку наводим мышку на линию.
Чтоб добавить Блок-схему наводим мышку на линию.
Переменные добавили, создаем алгоритмы. (Все подробное описание в каналах и соответствующих чатах)
От себя добавлю - когда мы подаем импульс - срабатывает селектор(да) - селектор триггера на 0(нет) - автоматом записываем импульс(ИСТИНА) - и переходим на ветку Счетчик.
Ветка Счетчик - Утилитарная функция + (Складываем импульсы) - выходим из алгоритма и ждем следующего сигнала.
Когда всё нарисовали, жмем на класс и кнопку Экспортировать
Постановка эксперимента. ▫️Постоянная нагрузка (количество одновременных запросов) на СУБД ▫️Одинаковый запрос ▫️Длительный период наблюдения Вопрос математикам : ▫️Какое распределение значений бенчмарка будет наблюдаться ?
Об этом пишет NewScientist. Во время попыток использовалась автоматизированная установка, которая умеет выполнять 23 ключевых этапа метода ИКСИ.
Обычно он требует высокой точности от медспециалистов, но машина с помощью модели ИИ смогла выбрать наиболее здоровые сперматозоиды, изучив их внешний вид. После этого устройство ввело их в заранее подготовленные донорские яйца.
В современном мире информационные потоки растут с невероятной скоростью, и для владельцев Telegram-каналов важно оперативно публиковать актуальные новости. Однако ручное управление контентом может быть утомительным и время затратным. К счастью, существуют инструменты автоматизации, такие как Make.com(ранее известный как Integromat), которые позволяют настроить автоматический постинг новостей в Telegram-канал. В этой статье мы рассмотрим, как использовать Make.com, Telegram-бота и API новостного сервиса NewsAPI для создания эффективной системы автоматизации.
Что такое Make.com?
Make.com — это мощная платформа для автоматизации бизнес-процессов и интеграции различных сервисов. Она позволяет создавать сценарии (scenarios), которые связывают между собой различные API и сервисы, такие как Telegram, RSS-ленты, базы данных, электронная почта и многое другое. Благодаря интуитивно понятному интерфейсу, даже пользователи без глубоких технических знаний могут настроить сложные автоматизированные процессы.
Зачем автоматизировать постинг новостей?
Автоматизация постинга новостей в Telegram-канал имеет несколько ключевых преимуществ:
Экономия времени : Вы освобождаетесь от необходимости вручную копировать и публиковать новости.
Оперативность : Новости публикуются сразу после их появления в источнике.
Масштабируемость : Можно настроить автоматическую публикацию из нескольких источников одновременно.
Снижение ошибок : Исключается человеческий фактор при копировании текста или ссылок.
Шаги для настройки автоматизации
1. Создание Telegram-бота
Для начала необходимо создать Telegram-бота, который будет отвечать за публикацию новостей в ваш канал. Для этого выполните следующие шаги:
Откройте Telegram и найдите бота BotFather .
Начните диалог с BotFather и используйте команду /newbot.
Следуйте инструкциям: укажите имя бота и его username.
После создания бота вы получите токен API. Сохраните его — он понадобится для настройки Make.com.
Теперь добавьте бота в ваш Telegram-канал:
Перейдите в настройки канала.
Добавьте бота как администратора.
Убедитесь, что боту предоставлены права на публикацию сообщений.
Зарегистрируйтесь на make.com и войдите в свой аккаунт.
Создайте новый сценарий (scenario).
В поиске модулей выберите Telegram и подключите его, используя токен API вашего бота.
3. Настройка источника новостей через NewsAPI
Для автоматической публикации новостей вам нужно определить источник контента. В данном случае мы будем использовать Russian Federation News API , который предоставляет доступ к новостям со всего мира через удобный API.
Настройте частоту обновления данных (например, каждые 120 минут). (Бесплатно в make 1000 операций рассчитайте время чтобы вам хватило на месяц)
4. Фильтрация и обработка новостей
После получения данных из NewsAPI, вы можете настроить фильтрацию и форматирование контента:
Фильтрация : Используйте условия (filters) в Make.com, чтобы публиковать только те новости, которые соответствуют определенным критериям (например, ключевые слова, категории).
Форматирование : Отредактируйте текст новости, добавьте эмодзи, хэштеги или ссылки.
Пример формата публикации:
🔥 {Заголовок новости}
{Краткое описание}
🔗 [Читать далее]({Ссылка на новость})
5. Публикация новостей в Telegram-канал
Добавьте модуль Telegram в ваш сценарий.
Выберите действие Send a Message (Отправить сообщение).
Укажите ID вашего Telegram-канала (начинается с @).
Вставьте отформатированный текст новости в поле сообщения.
6. Тестирование и запуск
Запустите сценарий в тестовом режиме, чтобы убедиться, что новости публикуются корректно.
Если все работает, активируйте сценарий для автоматического выполнения.
Пример готового сценария
Вот пример последовательности действий в Make.com:
HTTP Module : Получает новости из NewsAPI.
Google Sheets : Сортирует похожие новости
Telegram Module : Отправляет отформатированное сообщение в Telegram-канал.
Дополнительные возможности
Расписание публикаций : Настройте время публикации новостей с помощью модуля Scheduler .
Уведомления : Настройте отправку уведомлений в случае ошибок или успешных публикаций.
Аналитика : Интегрируйте Make.com с Google Sheets или другими сервисами для сбора статистики по публикациям.
Автоматизация постинга новостей в Telegram-канал с помощью Make.com, Telegram-бота и API NewsAPI — это мощный инструмент, который поможет вам экономить время и повышать эффективность управления контентом. Следуя описанным шагам, вы сможете настроить надежную систему автоматизации, которая будет работать круглосуточно и обеспечивать ваш канал актуальным контентом.
Если у вас возникнут вопросы или потребуется помощь в настройке, не стесняйтесь обращаться к документации Make.com или консультантам платформы. Удачи в автоматизации!
Ответ: {Настройка автоматизации постинга новостей в Telegram-канал с помощью Make.com, Telegram-бота и API NewsAPI завершена успешно.}
Люблю вообще тему защищенного грунта, а в частности такие сооружения, как теплицы для выращивания овощей, фруктов и ягод. Лет 5 назад задавался вопросом, как это всё можно автоматизировать и упростить жизнь дачнику, огороднику и фермеру.
В 2020 году появился объект с реальными условиями - итальянская теплица на 5 соток. Там я проводил эксперименты работы автоматики, писал алгоритмы и подпрограммы для наиболее эффективного выращивания помидоров и огурцов.
Скажем так, эти алгоритмы бесконечные. Для каждого сорта и для каждой культуры свои условия. Но общий смысл работы улавливается.
С вами на связи автор канала, Гридин Семен, хочу в статьях сохранить след своих работ по автоматизации теплицы.
Занимался я этим вопросом несколько лет. Есть небольшие пробелы в работе автоматики теплицы. Хочется немного поделиться своим опытом и размышлениями. Если у вас будут предложения и вопросы, пишите в комментариях.
Основной функционал микроклимата
Основа микроклимата является поддержание температуры и влажности. С помощью каких исполнительных органов всё это делается? Форточкой, отоплением и вентиляцией.
Итак, основной функционал.
Регулировка внутренней температуры теплицы путем автоматизированного проветривания с помощью фрамуги. По трём датчикам температуры - Тюг, Тсевер, Тнаружнего воздуха (Тн.в.). При чем по Тн. в. корректируется степень открытия форточки. Весной-осенью один режим работы, лето и зима другие режимы.
Установка сервиса корректировки степени открытия на введенные показатели по силе и направления ветра.
Включение внутренней вентиляции путем перекоса температур Тюг и Тсевер. Для выравнивания температур по всему объему.
Уставки температур 4, для поддержания различных температурных условия жизненного цикла растения в сутки. Утром одна температура, днем 2-ая температура, вечером третья, ночью четвертая.
Расчет времени восхода и захода солнца для правильной корректировки уставок температур в течении дня. Учитывается месяц для выращивания.
Расчет положения форточки рассчитывается либо с помощью мат. аппарата, либо с помощью датчиков обратной связи(второй вариант лучше, потому что точнее).
И в качестве доп. делал расчет дефицита водяного пара. Этот параметр говорит вам вообще о жизнедеятельности растения. Очень важная физическая единица.
Датчики физ. величин возможно подключать как по цифровому интерфейсу, так и непосредственно на входы контроллера.
Обязательно должны быть концевики на полное открытие и на полное закрытие форточки.
Расчет точки росы и абсолютной влажности.
Какой контроллер?
Программы писались на промышленном ПЛК отечественного производителя фирмы ОВЕН.
Одна на CoDeSyS 3.5 для ПЛК200, другая на Owen Logic для Программируемых реле ОВЕН ПР.
Всё это вместе выводится в облако OwenCloud, для отчетности, мониторинга и анализа данных. Так же можно посмотреть графики и Архивы на 90 дней. Можно самому расписать логику работы аварий. Достаточно универсальная штука.
ПЛК200
ПР102
Разница между ними в сложности мат. расчетов и объёма передаваемых тегов в Облако.
Что в Облаке?
В облако можно вывести абсолютно любой параметр для записи и для чтения.
Используется OwenCloud.
Часть алгоритмов
Понятно, чтобы не быть голословным. Покажу часть алгоритмов.
Owen Logic.
ФБ для работы форточки в различных режимах.
Работа 4 уставок.
Пример работы в Codesys. Работа форточки.
Запись уставок Температур в зависимости от времени суток.
