Linux Performance Observability Tools. Sysstat.

Продолжаем обзор инструментов для наблюдения за производительностью. Сегодня я бы хотел рассказать о таком наборе утилит как sysstat. Это очень интересный пакет. Прежде всего он интересен тем что позволяет вести историю производительности. Это актуально если у вас небольшое количество хостов и вы не хотите развертывать отдельную систему мониторинга. Кроме того sysstat предоставляет несколько утилит для online наблюдения за системой. 

PostgreSQL и WARNING: pgstat wait timeout.

pgstat wait timeout

Сегодня я бы хотел рассказать о такой ошибке как "pgstat wait timeout". Довольно малоинформативное сообщение, не так ли?

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

Давайте попробуем разобраться почему это происходит.

Linux Performance Observability Tools. Top.

Linux Performance Observability Tools. Top.

Есть такая картинка Linux Performance Observability Tools. На первый взгляд она может показаться непонятной, поэтому давайте разберемся что здесь изображено. На этой картинке в очень упрощенном виде отражена структура ОС Linux, а каждый компонент структуры подписан инструментом который позволяет отслеживать работу этого компонента. Эти инструменты очень полезны в случае когда сервер "тормозит" и нужно определить какой из компонентов вызывает тормоза. Cистемный администратор или инженер должен уметь пользоваться большинством из тех инструментов что отражены на картинке. Как вы видите, инструментов очень много, какие-то могут быть вам знакомы, а какие-то - нет. Некоторые из этих инструментов довольно просты в обращении, а какие-то наоборот требуют высокой квалификации и дополнительных знаний. В последующем цикле статей я постараюсь рассмотреть наиболее популярные и интересные утилиты и рассказать о том как читать информацию которую они предоставляют и как использовать её в дальнейшем. 

English version available here.

И еще один блог.

И снова здравствуйте!

Небольшая новость. После долгого перерыва я вновь решил писать в блог, делиться опытом, рассказывать всякие истории профессионального плана, иногда буду постить howto-ролики с ютуба. Однако это не все. Теперь дополнительно я буду автором еще одного блога. Встречайте, блог нашей компани PostgreSQL Consulting. Статьи там будут преимущественно на английском языке. Да, да завоевываем новые рынки))). Поэтому добро пожаловать. 

Здесь же я по-прежнему будут выкладывать статьи на роодном русском языке! Так что не спешите удалять меня из своих RSS лент;) До скорых встреч.

PostgreSQL stand-by promote

PostgreSQL: Как превратить stand-by в master

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

1. через перезапуск postgresql
2. через создание триггер файла
3. через утилиту pg_ctl

О них и пойдет речь в статье.

PostgreSQL query planning time and statistics target.

Влияние размера статистики на время планирования запроса в PostgreSQL.

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

Network problem emulation with Iptables and Iproute2

Network problem emulation with Iptables and Iproute2

Однажды мне понадобилось в Zabbix сделать мониторинг потери пакетов между мастером и репликами (репликация плохо себя чувствует если канал не очень хороший). Для этого, в Zabbix есть встроенный параметр icmppingloss, на удаленный хост отправляется серия ICMP пакетов и результат фиксируется в системе мониторинга. И вот параметр добавлен, триггер настроен. Казалось бы задача выполена, однако как говорится "Доверяй, но проверяй". Осталось проверить что триггер сработает когда потери действительно будут. Итак, как сэмулировать потерю пакетов? Об этом, да и не только, пойдет речь под катом.