Linux Ubunty, PostgreSQL 9.3




Данные достаются запросом:

SELECT data, start_time FROM chunks WHERE series_id = ? AND start_time >= ? AND start_time <= ? order by start_time ASC

План хороший, время выполнения запросов, когда данные в shared_buffers 0.5-2 ms.

ПРОБЛЕМА: PostgreSQL потребляет огромное кол-во CPU. По факту, прикладная система на Java забирающая данные и работающая на 3 процах, загружает на 70% 6-и процессорную машину с PostgreSQL. В чем может быть проблема, как отмониторить потребление CPU PostgreSQL ?

Соединения берутся из пула соединений, поэтому (надеюсь), все JDBC запросы должны быть server side prepared.

Shared_buffers достаточно небольшой (1 Gb), т.ч. пока подозреваю потерю CPU на обращение к cache OS (по факту 5-7 Gb). Но все равно, потребление CPU просто огромное до безобразия.


ПРОБЛЕМА N2.
Как я понимаю, тип данных bytea передается по сети как hex ((( Кто как с этим борется? Трафик же по сети в два раза больше, чем нужно (((

Как я понимаю, переход на стандартные BLOB'ы тоже не вариант, т.к. выиграем в трафике, проиграем в round trip'ах

qwwqкаким пулом ? жабовским ?
Да

Вывел в лог isUseServerPrepare() после небольшого прогрева - всегда true. Т.ч. должны быть отпарсенные
qwwqбы из запроса сделал SQL--language храникму -- она бы работала как "сервер сайд препаред" независимо от типа пула и настроек.
Хорошая идея. Как не парадоксально, мне в голову не приходила.

Возможно попытаюсь, о результатах отпишусь.(это не быстро, т.к. нужно вфигачить патч в приложение+развернуть на серверах)

Но вопрос по Subj остатеся. Т.к. даже в случае, если запросы не prepared, не очень понятно, почему такое потребление CPU. Оно реально какое-то огромное.

Maxim Boguk3)какой средний размер этой самой Bytea?
4)какой сетевой траффик с базы (сервера) получается?

Около 50 - 70 Kb на запись
Сетевой трафик max 55.8 MBps.

[quot Maxim Boguk]
5)машина - реальный сервер или очередная недо-виртуалка?

И то и то виртуалка на одном хосте.Вроде что-то типа KVM (не уточнял)

Плюс сам PostgreSQL и приложение на Java развернуты в виртуалке в docker container'е.

Maxim Boguk7)поставьте pg_stat_statements и покажите что он показывает в топовых запросах по времени.

Завтра постараюсь поставить и ответить на другие вопросы.

===

Мне пока не нравятся след вещи:
1. Hex кодировка при передаче bytea между СУБД и клиентом. Я так понимаю, это врожденная травма PostgreSQL ((( Может ли она давать overhead по CPU? Можно ли ее как-то исправить?
2. Как я понимаю, TOAST по умолчанию пытается компрессировать данные. Насколько сильно это сказывается на CPU ? БД (табличка) > 170 Gb т.ч. выдать Alter table не так уж просто

Maxim Boguk6)ssl on или off на сервере?

ON

Maxim Boguk7)поставьте pg_stat_statements и покажите что он показывает в топовых запросах по времени.

--
Maxim Boguk
www.postgresql-consulting.ru

СПАСИБО.
Ларчик просто открывался. CPU жрал совсем другой запрос, правда странно, что в active statement он ни разу не показался. Когда пофиксили (добавили индекс) - упало с 60% до 10-12% + скорость приложения выросла на 30%.