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

Привет всем, у меня есть один вопрос
- теперь я использую индекс джина для jsonb с jsonb_path_ops
но не работает поиск по индексу, конечно, я использовал оператор оператора@> но не работает.

но это хорошо работает, если таблица будет иметь только один столбец (столбец jsonb), но если будет иметь другие столбцы, не индекс, только сканирование seq. Я работаю над Postgresql 12.2

Мне нужна ваша помощь. Спасибо

ясно, спасибо за помощь

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

я не понимаю, почему тогда переключение на mq-deadline роняет утилизацию до 0 (при этом приложение никак не страдает)

Реально туда пишется-читается что-то интенсивно?
Хотя при околонулевом iowait вряд ли.

потому что начинает работать менеджер очереди, который равномерно нагружает контроллер

И зря 10.3 — обновитесь (последняя minor версия 10.13).
Далее, похоже на то, что сразу несколько соединений пытаются выполнять:

alter database "ejabberd" set standard_conforming_strings='off';

И мне кажется, что какой-то такой bug был в старых версиях... но даже если обновление не поможет — в принципе, ничего особо страшного в этой ошибке нет... скорее странно, что приложение пытается это делать (эта настройка вообще deprecated, вроде, а уж пытаться её менять на уровне базы в каждом (?) соединении — и вовсе ненормально).

иногда помогает обновление прошивки для nvme. Но нужно быть аккуратным

alter database "ejabberd" set standard_conforming_strings='off';

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

Скорее всего, это значит, что PostgreSQL считает, что не использовать индекс — выгоднее.
Проверьте с "SET enable_seqscan = false;"

реально насколько я могу судить туда почти ничего не пишется (20 op/s записи, 0 чтения)

ну и в байтах какие-то жалкие килобайты

> поднять базу я не могу, увы.

Почему (тут кто-то, вроде, рассказывал, как docker прекрасен для подобных вещей)? ;)
Будь это любой обычный дистрибутив, это было бы тривиально, just FYI.

> И эти ошибки блочат мне базу. Приложение не работает наше.

Можете поискать, какого почему оно это делает (эти ALTER-ы) — может, это можно как-то отключить в этом приложении?

да, я пропустил возможно важную деталь - 2 nvme диска собраны в софтварный рейд. Утилизация 100% для партиций, которые под рейд выделены

Скорее всего вот оно значит
https://unix.stackexchange.com/questions/517667/nvme-disk-shows-80-io-utilization-partitions-show-0-io-utilization

видел этот пост
> to a kernel bug which will be solved in kernel-3.10.0-1036.el7
4.19 на сервере. Я пропустил какие-то другие важные сведения?

не так давно вроде пофиксили

Вариант 1: могли вполне себе багфикс в апстрим не отправить ещё.
Вариант 2: помню какие-то были приличные изменения в ядре на границе 4 и 5 мажорных версий как раз на тему аккаунтинга всяких счётчиков. Но, ЕМНИП, погнулито дело немного уже именно в 5.0

спасибо, вы имеете в виду postgresql автоматически управлять индексом для больших данных?
если было бы лучше не использовать индекс для небольших данных, он использует seq scan.
если было бы лучше использовать индекс для больших данных, он использует индекс. правильно?