Печальная история со счастливым концом. Часть 1 Начало. PostgreSQL stat collector

Все описанное имеет отношение к версии PostgreSQL 8.3

На днях случился… Ну как бы сказать… «Эпический фейл». Заключался он в том, что у нас просто «упали» все базы. Сразу хочу сообщить, что PostgreSQL тут совершенно не причем, во всем виновата наша халатность. Так вот почему это случилось и с чего началось я и хотел бы рассказать.

Сейчас у нас все хорошо, и что самое главное… Выводы сделаны!

Когда-то давно, когда мы только начали использовать PostgreSQL (писать правильно нужно именно так) в качестве СУДБ, мы обратили внимание на странный процесс который постоянно вызывал дисковую активность: postgres: stats collector process

Если очень коротко, то этот процесс собирает информацию и отчетность о серверной активности (серверной в смысле PostgreSQL) и сбрасывает эту информацию в файл по-умолчанию /global/pgstat.stat.

Причем, судя по исходным кодам (да, пришлось посмотреть из любопытства) делает это довольно часто:

pgsql/src/backend/postmaster/pgstat.c

/* ----------
* Paths for the statistics files (relative to installation's $PGDATA).
* ----------
*/
#define PGSTAT_STAT_FILENAME "global/pgstat.stat"
#define PGSTAT_STAT_TMPFILE "global/pgstat.tmp"

/* ----------
* Timer definitions.
* ----------
*/
#define PGSTAT_STAT_INTERVAL 500 /* How often to write the status file;
* in milliseconds. */

И все вроде бы не плохо, но судя по анализу команды atop происходит попытка записи данных и сразу же идет отмена. Возникло подозрение, что активность процесса обратно пропорциональна его полезности. Кроме того напрягало постоянное высокое значение параметра avio. Одной из возможных причин высокого значения параметра avio нам показалась как раз активность процесса stats collector.

Начался процесс поиска информации с помощью Google 🙂 Ничего вразумительного мы в принципе так и не нашли. Тогда я решил попросить помощь зала.

http://archives.postgresql.org/pgsql-general/2009-12/msg00903.php

Вот текст сообщения:

From: Лев Ласкин
To: pgsql-general@postgresql.org
Subject: stats collector process: WRDSK = WRDSK_CANCEL?
Date: Tue, 22 Dec 2009 12:30:05 +0300
Message-id: <4B30919D.9030903@gmail.com>

Hi.
We have installed Postgresql 8.3.3. When we see the output of atop-d, we see just such a string
db0: ~ # atop 15
ATOP - db0 2009/12/22 12:14:29 15 seconds elapsed
DSK | sda | busy 50% | read 72 | write 207 | avio 27 ms |

PID RDDSK WRDSK WRDSK_CANCEL DSK CMD 1 / 2
11296 0K 185.0M 185.0M 97% postgres

db0: ~ # ps auxww | grep postgre
postgres 11296 4.3 0.1 24244 13028? Ss Nov24 1734:25 postgres: stats collector process
Why WRDSK = WRDSK_CANCEL? So it should be? Perhaps we were wrong in the settings.
Who can help anything in this matter?

Откликнулся комрад Magnus Hagander (один из «коммитеров» патчей для PostgreSQL). Он ответил следующее

WRDSK_CANCEL is data that was written, but deleted before it was
flushed to disk. That is normal behaviour for the stats temp file,
which is written and deleted within half a second.

8.4 will do a lot less writes here, but on 8.4 it's perfectly normal.

Все бы здорово Magnus, но на тот момент PostgreSQL 8.4 вышел, а вот патчей для адаптации 1С нет. Поэтому у нас без вариантов…Как оказалось Magnus еще в 2008 «запаривался» 🙂 на эту тему и предложил вот такой вариант:

http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg110417.html

This would make it possible to symlink or mount that directory off to a
ramdrive (for example).

It’s not a perfect solution, but it would at least give a better tool
than we have today, no?

//Magnus
Чтож, мы так и сделали: ln -s /dev/shm/globdal /pgsql/global

Более stats collector process нас не мучал.

Ps
Продвинутые товарищи уже догодались что же все таки у нас случилось, но об этом в следующий раз..

Печальная история со счастливым концом. Часть 1 Начало. PostgreSQL stat collector: 1 комментарий

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *