Рис. 4.4.Таблицы с наибольшим количеством обновленных строк

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

Рис. 4.5.Таблицы с наибольшим количеством вставленных строк

Ошибки и нежелательные события

Давайте снова вернемся к pg_stat_database и рассмотрим следующие поля:

•xact_rollback — это поле упоминалось при рассмотрении транзакционной активности. Оно указывает на количество транзакций, завершившихся откатом. Факт отката можно

расценивать как возникновение ошибки (за исключением случаев явного вызова команды ROLLBACK). Следовательно, большое число откатов может сигнализировать об ошибках при выполнении как отдельных запросов, так и транзакций, и xact_rollback можно использовать как счетчик таких ошибок. Типичными примерами могут служить нарушение уникальности при вставке строк, ошибки синтаксиса, неверное указание аргументов функции или обращение к несуществующим объектам. Однако кроме таких ошибок возможны и другие, которые могут возникать по причинам, не зависящим от приложения, но эту информацию можно получитьтолько из журнала СУБД.

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

•deadlocks—взаимоблокировки,их мытакже рассматривали ранее в главе 2.Для разрешения взаимоблокировки какая-то из транзакций завершается принудительно, и это также можно расценивать как ошибку.

•checksum_failures и checksum_last_failure показывают количество ошибок при провер-

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

•sessions_abandoned, sessions_fatal, sessions_killed указывают на количество сеансов с ненормальным завершением. Эти поля мы также обсуждали в главе 2. Они указывают на то, что сеанс завершился ненормально, и это также можно рассматривать как ошибку.

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

•postgres_database_xact_rollbacks_total;

•postgres_database_conflicts_total;

•postgres_database_deadlocks_total;

•postgres_database_checksum_failures_total;

•postgres_database_sessions_total{reason=~"abandoned|fatal|killed"}.

Всамом идеальном случаетакой график должен быть «пустым»,как на рис. 4.6.Любые выбросы должны привлекать внимание администратора БД и служить поводом разобраться с причинами.