autovacuum Archives - Data Egret

Я ищу сервис для обслуживания моей базы данныхМне нужна помощь с миграцией моей базы данныхУ меня есть проблема с базой данных, и мне нужна помощьЯ ваш клиент, и мне нужна помощьЯ хочу работать в Data Egret

Далее

Контакты

Заполните, пожалуйста, форму ниже, чтобы мы могли с вами связаться в ближайшее время. Если вопрос срочный, напишите об этом в поле Комментарий.

Указанные данные будут использованы Data Egret исключительно для обработки вашего запроса. При необходимости ознакомьтесь с нашей Политикой конфиденциальности.

Спасибо за Ваше сообщение

Мы скоро свяжемся с Вами. Если вы предпочитаете обсудить ваше обращение голосом, звоните нам на +7 (495) 481 49 61.

Указанные данные будут использованы Data Egret исключительно для обработки вашего запроса. При необходимости ознакомьтесь с нашей Политикой конфиденциальности.

Спасибо!

Мы внимательно ознакомимся с вашим резюме и ответим вам в ближайшее время!

Что нужно будет делать:

разворачивать и наливать реплики,
вносить изменения в схему под нагрузкой без остановки работы проекта,
анализировать медленные запросы,
правильно создавать/подбирать индексы для оптимизации запросов,
разворачивать и настраивать PostgreSQL на новых серверах,
выполнять Failover/Switchover,
настраивать резервное копирование и проводить восстановление из резервной копии,
разбираться, что работает не так и почему оно не так работает,
рассказывать клиентам, что вы сделали и что надо сделать клиенту, если проблема не на стороне базы.

Мы ждем, что Вы:

имеете опыт администрирования нагруженных баз данных PostgreSQL от 2-х лет (включая настройку репликации, оптимизацию производительности, настройку мониторинга и т.д.),
имеете опыт оптимизации сложных SQL-запросов,
можете и любите работать в самостоятельном режиме, когда задача поставлена в самых общих чертах («сделать всё хорошо и красиво»),
уверенный пользователь Linux и умеете его администрировать (Ubuntu/Debian/RedHat),
представляете себе в общих чертах теорию баз данных,
владеете основами программирования на shell (скрипт на пару экранов, в котором через пару месяцев сможет разобраться другой админ и Вы сами),
можете написать сложный (и очень сложный) SQL-запрос,
разберетесь с документаций на английском языке,
можете рассказать клиенту (текстом), что вы только что сделали по задаче, почему и зачем,
не боитесь нового и любите разбираться в технологиях.

Плюсом будет, если Вы:

знакомы с Patroni,
знакомы с какими-либо DevOps средствами (Ansible/Docker/Kubernetes),
программируете на C / имеете опыт анализа проблем с использованием perf/strace/gdb,
имеете опыт администрирования облачных платформ,
владеете свободным разговорным английским.

Что получите Вы:

станете частью одной из самых опытных команд DBA в мире,
возможность прокачать свои навыки PostgreSQL на разнообразных задачах и разнообразном окружении (год за пять).

Условия:

удаленная работа,
официальная зарплата от 200 000 руб. — по результатам собеседования, потолок определяется только вашим уровнем и работоспособностью,
рабочий день — гибкий 8-часовой (конкретный график обсуждается; как вариант, с 06:00 ч до 14:00 ч, с 16:00 ч до 24:00 ч, или любые промежутки с перерывами, но требуется минимум 4-часовое пересечение с основной командой в интервале с 09:00 ч до 21:00 ч MSK),
оплачиваемые поездки на конференции (как позволят внешние обстоятельства).

Готовы работать у нас?

Отправить резюме

Хотели бы стать частью нашей команды? Возможно одна из открытых сейчас вакансий будет подходит именно вам? Ознакомьтесь с нашим предложением ниже и присылайте ваше резюме.
Мы ответим вам в ближайшее время!

01
Администратор баз данных /
Senior DBA (PostgreSQL)

Возникли вопросы? Просто напишите нам.

Связаться с нами

Семинары по PostgreSQL

Когда в вашей команде уже есть PostgreSQL DBA, иногда возникает необходимость в повышении уровня их компетенции в определенных темах в работе с СУБД. Обучающие семинары от профессиональных DBA Data Egret могут стать подходящим решением с точки зрения эффективности и экономии времени и ресурсов.

Официальная документация PostgreSQL и другие полезные онлайн-ресурсы являются отличным началом для изучения СУБД, но зачастую времени на это у членов команды недостаточно.
Наши DBA ежедневно обслуживают десятки баз данных и в курсе самых последних новинок и трендов развития PostgreSQL, а также популярных ошибок в работе с ней.

Стоимость семинаров рассчитывается индивидуально.

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

Популярные темы семинаров:

Основы PostgreSQL
Средства диагностики
Оптимизация производительности
Администрирование PostgreSQL
Масштабирование и отказоустойчивость
Продвинутый SQL и не только

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

Семинары проводятся на территории заказчика либо в форме вебинара для групп 10-20 человек.

Посмотреть примеры обучающих семинаров можно на нашем YouTube-канале:

— семинар «Новинки PostgreSQL 13», который проводил Алексей Лесовский,

— семинар «Recovery conflict. Пул транзакций в pgBouncer. NOTIFY_LISTEN», проведенный Алексеем Козловым.

Аудит

Аудит от Data Egret представляет собой единовременное погружение наших специалистов в вашу базу данных, с целью проведения анализа, выявления неполадок или “узких” мест и предоставления отчета с рекомендациями по оптимизации работы БД.

В процессе Аудита проводится:

анализ настроек (pgbouncer) PostgreSQL;
поиск медленных SQL запросов;
анализ схемы данных;
анализ настроек ОС и оборудования;
аудит производительности;
анализ процесса резервного копирования.

Письменный отчет содержит рекомендации:

по изменению настроек на более эффективные;
по оптимизации обнаруженных медленных запросов;
по оптимизации процесса резервного копирования;
общие рекомендации по архитектуре, связанные с оптимизацией производительности.

Стоимость пакета Аудит может варьировать в зависимости от индивидуальных требований клиента и определяется индивидуально.

Настоящее предложение не является офертой.

Указанные условия, включая стоимость оказываемых услуг в рублях РФ, не являются офертой, и могут быть изменены в зависимости от согласованных в дальнейшем существенных условий договора и предпочтительной для клиента валюты платежа.

Консультирование PostgreSQL

Администрирование баз данных (БД) часто ложится на плечи системных администраторов и разработчиков. При этом работа с БД требует как специфических знаний, так и значительного опыта, особенно, если речь идет о работе с высокой нагрузкой.

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

Приобретая пакет консалтинговых часов, вы можете обратиться к нам для решения как горящих, так и плановых задач, получения помощи в масштабировании БД и консультаций по архитектуре. Заявки на консультации принимаются с 09:00 по 18:00 МСК.

Что мы делаем в процессе консультирования:

настраиваем PostgreSQL;
сопровождаем в процессе миграции на PostgreSQL;
улучшаем производительность БД;

уменьшаем время отклика сервисов;
настраиваем процесс резервного копирования;
решаем архитектурные задачи;
налаживаем процесс мониторинга.

Минимальный пакет 2 часа.
Услуга не подразумевает SLA. Для систем с жестким временным режимом мы рекомендуем наши пакеты Поддержки.
Сервера с устаревшими версиями PostgreSQL (9.6 и ниже), а также сервера под управлением ОС Windows тарифицируются по ставке на 50% выше.

Указанные условия, включая стоимость оказываемых услуг в рублях РФ, не являются офертой, и могут быть изменены в зависимости от согласованных в дальнейшем существенных условий договора и предпочтительной для клиента валюты платежа.

Поддержка от Data Egret — это сочетание регулярных проверок (Health Checks), круглосуточная доступность команды DBA для ответа на аварийные обращения и решение рутинных задач по оптимизации работы баз данных, включая:

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

Что такое регулярные проверки (Health Checks):

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

Цель проверок — своевременное выявление неполадок и оптимизация работы системы.

Базовый	Премиум	Enterprise
До 10 серверов	До 40 серверов	До 100 серверов
Чат, аварийный телефон	Чат, аварийный телефон	Чат, аварийный телефон
до 10 часов работы DBA/месяц*	до 25 часов работы DBA/месяц*	до 60 часов работы DBA/месяц*
SLA проблема — до 1 ч., стандартные работы — до 8 ч.	SLA проблема — до 1 ч., стандартные работы — до 3 ч.	SLA проблема — до 1 ч., стандартные работы — до 3 ч.
24/7 SLA на аварии — 1 ч.	24/7 SLA на аварии — 1 ч.	24/7 SLA на аварии — 30 мин
Автоматические Health Check	Автоматические Health Check с рекомендациями от DBA	Индивидуальная проверка ваших БД нашими DBA
Цена может варьировать в зависимости от индивидуальных требований клиента и обсуждается индивидуально. Настоящее предложение не является публичной офертой.Возможно платное увеличение лимита часов на базовые работы.При выработке лимита часов, включенных в пакет, дополнительные часы оплачиваются по дополнительному тарифу. По предварительной договоренности возможно увеличение лимита часов, включенных в пакет, по сниженному тарифу. Указанные условия, включая стоимость оказываемых услуг в рублях РФ, могут быть изменены в зависимости от согласованных в дальнейшем существенных условий договора и предпочтительной для клиента валюты платежа. Минимальная длительность контракта — 6 месяцев.*

Не уверены, какой пакет вам подойдет? Остались вопросы? Напишите нам и мы найдем для вас подходящее решение!

Запустите наш SQL запрос, скопировав код ниже.
Вывод даст вам понять, какой версией вы пользуетесь и надо ли вам перейти на более новую.

Скопировать код

select case when setting::bigint < 90600
              then 'Вы используете старую версию PostgreSQL, которая более не поддерживается сообществом.'||chr(10)||
                   'Рекомендуем вам перейти на последнюю актуальную версию как можно скорее.'
            when setting::bigint < 100000
              then 'Вы используете старую версию PostgreSQL, которая пока что поддерживается сообществом.'||chr(10)||
                   'Рекомендуем вам перейти на последнюю актуальную версию.'
            when setting::bigint < 110000
              then 'Вы используете достаточно современную версию PostgreSQL, которая активно поддерживается сообществом.'||chr(10)||
                   'У вас все неплохо, но можно обновиться и на последнюю актуальную версию при возможности.'
            when setting::bigint < 140000
              then 'Вы пользуетесь одной из самых последних версий PostgreSQL.'||chr(10)||
                   'У вас все отлично.'
            else 'Вы используете версию которая находится в разработке,'||chr(10)||
                 'если это production, то рекомендуем вам перейти на стабильную версию PostgreSQL.'
       end as "Проверка мажорной версии PostgreSQL"
     , case when setting::bigint between 130002 and 139999 or
                 setting::bigint between 120006 and 129999 or
                 setting::bigint between 110010 and 119999 or
                 setting::bigint between 100015 and 109999 or
                 setting::bigint between 90620 and 90699
              then 'У вас стоит один из последних патчей PostgreSQL для вашей версии.'||chr(10)||
                   'Похоже вы следите за обновлениями PostgreSQL. Это хороший факт.'
            else 'Похоже вы не обновляли PostgreSQL, после установки/последнего мажорного обновления, совсем.'||chr (10)||
                 'Это плохо, рекомендуем вам обновиться до последней актуальной версии PostgreSQL.'
       end as "Проверка минорной версии PostgreSQL"
     , 'Актуальные версии на данный момент следующие, в порядке убывания актуальности:'||chr (10)||
       '13.3, 12.7, 11.12, 10.17, 9.6.22' as "Список актуальных версий"
  from pg_settings
 where name = 'server_version_num';

Переход на новые версии PostgeSQL зачастую требует опыта, который приходит при постоянной работе с различными версиями PostgreSQL, поэтому это то, что обычно откладывается в долгий ящик.

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

У наших специалистов огромный опыт в переводе баз на более актуальные версии PostgreSQL, и они с удовольствием вам помогут осуществить безупречный переход к новой версии.

Обращайтесь!

Переход на новые версии PostgreSQL зачастую откладывается на потом, ведь система уже работает, к чему что-либо менять?

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

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

Проверить свою версию PostgreSQL

Если вы регулярно видите процессы автовакуума — в одной и той же таблице (часто), или же работающие слишком долго — вам необходимо принимать меры и конфигурировать базу.

Запустите наш SQL запрос, скопировав код ниже.

Скопировать код

SELECT (clock_timestamp() - xact_start) AS ts_age,
                            state, pid, query FROM pg_stat_activity
                            WHERE query ~ 'autovacuum' AND NOT pid=pg_backend_pid();

Скрипт покажет все активные в данный момент процессы автовакуумa и время их работы.

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

Обращайтесь!

Вакуумирование — важная процедура поддержания хорошей работоспособности вашей базы.

Если вы видите, что автовакуум процессы всё время работают, это значит, что они не успевают за количеством изменений в системе.
А это, в свою очередь, сигнал того, что надо срочно принимать меры, иначе есть большой риск “распухания” таблиц и индексов — ситуация, когда физический размер объектов в базе очень большой, а при этом полезной информации там в разы меньше.

Проверить оптимальность работы автовакуума

Запустите следующий SQL запрос:

Скопировать код

SELECT now()-pg_postmaster_start_time() "Uptime",
now()-stats_reset "Minutes since stats reset",
round(100.0*checkpoints_req/checkpoints,1) "Forced
checkpoint ratio (%)",
round(min_since_reset/checkpoints,2) "Minutes between
checkpoints",
round(checkpoint_write_time::numeric/(checkpoints*1000),2) "Average
write time per checkpoint (s)",
round(checkpoint_sync_time::numeric/(checkpoints*1000),2) "Average
sync time per checkpoint (s)",
round(total_buffers/pages_per_mb,1) "Total MB written",
round(buffers_checkpoint/(pages_per_mb*checkpoints),2) "MB per
checkpoint",
round(buffers_checkpoint/(pages_per_mb*min_since_reset*60),2)
"Checkpoint MBps"
FROM (
SELECT checkpoints_req,
checkpoints_timed + checkpoints_req checkpoints,
checkpoint_write_time,
checkpoint_sync_time,
buffers_checkpoint,
buffers_checkpoint + buffers_clean + buffers_backend total_buffers,
stats_reset,
round(extract('epoch' from now() - stats_reset)/60)::numeric
min_since_reset,
(1024.0 * 1024 / (current_setting('block_size')::numeric))pages_per_mb
FROM pg_stat_bgwriter
) bg

Запрос покажет статистику по контрольным точкам с момента, когда она в последний раз обнулялась.
Важными показателями будут минуты между контрольными точками и объем записываемой информации.

Большое количество данных за короткое время — это серьезная нагрузка на систему ввода-вывода. Если это ваш случай, то ситуацию нужно однозначно менять!

Обращайтесь!

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

Для того, чтобы понять правильность настройки, надо обратить внимание на следующие отклонения в поведении базы данных:

в мониторинге приложения или базы будут видны пики во времени ответа с хорошо прослеживаемой периодичностью;
в моменты «пиков» в логе базы будет отслеживаться большое количество медленных запросов (в случае, если логирование таких запросов настроено).

Следуйте нашим инструкциям, чтобы проверить настройки контрольных точек.

Для работы над медленными запросами необходимо их прежде всего идентифицировать. Существует как минимум три варианта, как это сделать:

найти проблемные запросы в мониторинге
просмотреть лог базы на наличие долгих запросов (включается опцией log_min_duration_statement)
проверить view pg_stat_statements

После идентификации запроса необходимо посмотреть его план. Скопируйте код ниже, который добавит `EXPLAIN (analyze)` в начало вашего запроса, потом запустите запрос.

Будьте осторожны с запросами, которые меняют данные т.к. они будут исполнены!

Скопировать код

explain (analyze) select 10/2;
                            /* Вместо select 10/2 вставьте пожалуйста ваш запрос который работает медленно */

При выводе вы получите два параметра — время планирования и время исполнения запроса, например:

Planning time: 3667.361 ms

Execution time: 1.652 ms

Если время планирования сравнимо или же превышает время выполнения — проблематичный запрос нужно оптимизировать.

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

Обращайтесь!

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

Необходимо исследовать причину, по которой планировщик долго работает, и устранить её.

Следуйте нашим инструкциям, чтобы идентифицировать проблематичные запросы.
Найти проблематичные запросы

Настоящая Политика конфиденциальности (далее — Политика) действует в отношении всей информации, которую ХП «ДЕЙТА ИГРЕТ ГРУП», действующий под брендом Data Egret (далее – Оператор), может получить о Пользователе во время использования Веб-сайта Оператора dataegret.ru

Использование Веб-сайта означает безоговорочное согласие Пользователя с настоящей Политикой и указанными в ней условиями обработки собираемых данных. В случае несогласия с условиями настоящей Политики Пользователь должен немедленно прекратить использование Веб-сайта.

Информация Пользователя

В рамках настоящей Политики под информацией Пользователя понимаются:

информация, которую Пользователь предоставляет о себе самостоятельно в процессе использования Веб-сайта, в том числе персональные данные;
данные, которые собираются автоматически в процессе использования Веб-сайта, в том числе IP-адрес, информация из cookies, информация о браузере Пользователя, время доступа, адрес запрашиваемой страницы;
иная информация о Пользователе.

Оператор не проверяет достоверность предоставленной Пользователем информации и не осуществляет контроль за его дееспособностью. Оператор исходит из того, что Пользователь предоставляет достоверную и достаточную информацию, необходимую в процессе использования Веб-сайта.

Цели сбора и обработки информации Пользователей

Оператор собирает и хранит только ту информацию, которая необходима для исполнения соглашений и договоров с Пользователем.

Информацию Пользователя Оператор может использовать в следующих целях:

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

Условия обработки информации Пользователя и ее передачи третьим лицам

Оператор хранит информацию Пользователей в соответствии с внутренними регламентами.

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

Оператор вправе передать информацию Пользователя третьим лицам в следующих случаях:

Пользователь выразил свое согласие на такие действия;
Передача необходима в рамках оказания Пользователю определенных услуг;
Передача предусмотрена законодательством Российской Федерации.

При обработке информации, являющейся персональными данными Пользователей, Оператор руководствуется Федеральным законом № 152-ФЗ «О персональных данных».

Изменение Пользователем информации

Пользователь может в любой момент изменить (обновить, дополнить) предоставленную им информацию или ее часть.

Пользователь вправе запросить удаление предоставленной им информации посредством электронного письма, направленного на контактный адрес электронной почты Оператора.

Меры безопасности

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

Заключительные положения

Оператор имеет право вносить изменения в настоящую Политику конфиденциальности.

Новая редакция Политики вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Политики. Действующая редакция Политики конфиденциальности всегда находится на Веб-сайтах по адресу: https://dataegret.ru/#_privacyPolicy.

К настоящей Политике и отношениям между Пользователем и Оператором, возникающим в связи с применением Политики, подлежит применению право Российской Федерации.

Category: autovacuum

Automated index bloat management: How pg_index_watch keeps PostgreSQL indexes lean.

Please welcome Pg_index_watch — a utility for dealing with index bloat on frequently updated tables.

VACUUM на часто обновляемых таблицах

Ускоряем VACUUM в PostgreSQL

Vacuuming update-heavy tables

Accelerating VACUUM in Postgres