Тут проблема в том, как работает поиск в сбалансированных деревьях. Когда в индексе ищут одно значение или диапазон - все прекрасно. А вот когда куча разрозненных значений - то все болеет. Ещё можно попробовать ваш массив идентификаторов упорядочить, но в моем понимании поиска это вряд ли даст выигрыш по скорости. Тут, вероятно, параллелить

вообще вся таблица 57Gb, индексы по другим полям 2-3Gb. какого размера примерно лучше делать шарды?

Я бы по миллиону строк для начала поделил

Если сделаете, пишите)

мониторил весь, ничего такого как вчера не нашел. Я делал доп оптимизации в БД, плюс тех регламентые обслуживание типа вакуум и аналайз. Жду пока вылезет ошибка и запишется проблемный запрос в лог.

мониторил весь, ничего такого как вчера не нашел. Я делал доп оптимизации в БД, плюс тех регламентые обслуживание типа вакуум и аналайз. Жду пока вылезет ошибка и запишется проблемный запрос в лог.

Хорошо. Я помню вашу странную историю)

такая штука была давно, как решил тоже не помню, но там тоаст разрос до 60гб

не мог даже сделать дапм базы

что хранили там, без понятие, есть подозрение, что весь мусор снесли там и стало норм

что хранили там, без понятие, есть подозрение, что весь мусор снесли там и стало норм

Крайне интересно узнать, что 1С туда сохраняет. Картинки? Внешние обработки? Шаблоны на базе документов Word?

такая штука была давно, как решил тоже не помню, но там тоаст разрос до 60гб

Кстати, а если отслеживать тяжёлые запросы, среди них вашего, вызвавшего ошибку нет? Ну или посмотреть план с произвольным параметром

я честно говоря незнаю, 1С на уровне админа, поставить, ребуты и тд. Я в основном по серверу и БД(по работе в основном Oracle)

надо попробовать сделать произвольный от балды любое значение и проверить, count он делает быстро, вот считать все, насилует диск и все долго очень

Я предлагаю не просто произвольное, но по которому больше всего найдётся строк

учитываю, что запрос попадает FileName, то они все уникальны, только что проверил

если не указывать BinarData колонку, то запрос норм идет

А можно explain analyze с binardata?

Ну и размер этого поля в запрашиваемой строчке

всем привет, как хранить ссылки на картинку в таблице? не могу примерно даже создать таблицу с каким типом поле. Спасибо

varchar? или речь не о ссылке, а о самой картинке?) тогда bytea

хм, точно, тупо адрес можно же в фс хранить

"Index Scan using config_pkey on config (cost=0.41..8.43 rows=1 width=360) (actual time=0.021..0.022 rows=1 loops=1)" " Index Cond: (filename = 'versions'::mvarchar)" "Planning time: 0.109 ms" "Execution time: 0.060 ms"

"Index Scan using config_pkey on config (cost=0.41..8.43 rows=1 width=360) (actual time=0.021..0.022 rows=1 loops=1)" " Index Cond: (filename = 'versions'::mvarchar)" "Planning time: 0.109 ms" "Execution time: 0.060 ms"

Это с бинарными данными?

угу

explain analyze SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName = 'versions' ORDER BY PartNo

Вот подозреваю, что в некоторых строках лежат здоровенные бинарники, а в некоторых - маленькие. Посмотрите, какое максимальное значение размера бинарника среди строк. Мне кажется, на нем ошибка и проявится

вот как это сделать то?

в оракле я знаю, тут нет

Вроде length - https://www.postgresql.org/docs/8.2/static/functions-binarystring.html

аа, точно, вчера же мне дали, а забыл посмотреьт результат

length 10 млн это ноорм?

SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName = 'b2930bfd-5ede-4392-ae73-c4b28e5365fa.0' ORDER BY PartNo

выполнялся 17 секунд

учитывая там достаточно таких строк, неудивительно, что так долго

Я не знаю, в чем измеряется length (надо посмотреть), но 10 млн - до черта))

в символах наверняка

Выполните octet_length - он в байтах

Конечно нужно обновить сервер - это вы только клиент для подключения (psql )обновили.

Конечно нужно обновить сервер - это вы только клиент для подключения (psql )обновили.

т.е. этот файл /etc/postgresql/9.6/main/postgresql.conf он для клиента?

нет, для сервера

Выполните octet_length - он в байтах

те же цифры

Нет, он для сервера. Просто 9.6 при наличие 9.5 поднимается на не стандартном порту 5433

получается 10мб на ячейку

да, так есть, два инстанса tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 6494/postgres tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN 6495/postgres

Нет, он для сервера. Просто 9.6 при наличие 9.5 поднимается на не стандартном порту 5433

Короче, вы не туда подключились) добавьте в psql -p 5433

получается 10мб на ячейку

А сколько таких ячеек вытаскивается запросом?

понял, спасибо

А сколько таких ячеек вытаскивается запросом?

24

больше 1мб - 56

Можете ещё раз бросить вывод explain analyze для запроса на 17 сек

"Index Scan using config_pkey on config (cost=0.41..10.24 rows=2 width=360) (actual time=0.027..0.030 rows=2 loops=1)" " Index Cond: (filename = 'b2930bfd-5ede-4392-ae73-c4b28e5365fa.0'::mvarchar)" "Planning time: 0.164 ms" "Execution time: 0.067 ms"

Он закэширован? Что-то быстро сейчас

всегда так

я вчера увеличил кэш для БД до 2гб

если делать обычный запрос, а не просмотр плана - долго

почему то план и реальный запрос отличается

почему то план и реальный запрос отличается

Это результат "explain" или "explain analyze" ?

аналайз

почему то план и реальный запрос отличается

Так всегда будет

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

"Index Scan using config_pkey on config (cost=0.41..10.24 rows=2 width=360) (actual time=0.027..0.030 rows=2 loops=1)" " Index Cond: (filename = 'b2930bfd-5ede-4392-ae73-c4b28e5365fa.0'::mvarchar)" "Planning time: 0.164 ms" "Execution time: 0.067 ms"

Похоже на план для select count(*) вместо плана для select * - нет доступа к строкам, только к индексу

Вообще бред, 17 секунд считывать строку в 10 мб. У вас с дисками, где лежат таблицы все ок? Скорость чтения?

По индексам он ссылку на строку находит мгновенно

Вообще бред, 17 секунд считывать строку в 10 мб. У вас с дисками, где лежат таблицы все ок? Скорость чтения?

разжатие - unescaping - одно ядро

там же toast, оно блоками по 8кб хранит и собирает из осколков

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

бинарный данные как увидишь то? там абракадабра

бинарный данные как увидишь то? там абракадабра

Согласен, отбой. Коллеги выше дельные мысли сказали

дисковая подсистема не айс, рейд интел с материнки 1

ERROR: S client not available

какой было, такой и сделали

А ядер сколько?

Посмотрите через iostat что происходит с дисками в момент запроса. И через htop - с ядрами

тут виндоус стоит)

4 ядра + 4 потока

E3 1230

странность в том, что нагрузки ядра и диска не вижу

странность в том, что нагрузки ядра и диска не вижу

А вот это неожиданный поворот, который меня поставил в тупик. А что тогда болеет?

вот пытаюсь понят

Сбросьте кэш/выполните запрос с другим ключом - может оно в системный кэш ещё лазит сейчас

Может ещё сеть. Если клиент не на сервере, а где-нибудь подальше, то передача >10МБ по сети дело тоже не быстрое.

Если нет CPU affinity то на 4 ядра + 4 потока средне-ровная загрузка всех восьми HT-ядер на 1/8 как раз даст ОДИН во всю работающий процесс

сеть не грузится, кэш сбросил, также выполняется

какая мистика блин

а что если сделать стораж с extented на external ?

какая мистика блин

Я через час посмотрю - было расширение, которое позволяет залезть на низком уровне в таблицы и индексы. Может, там накопаем ответ. Но звучит крайне бредово. Даже если 10 мб состоит из раскиданных по всему диску чанков по 8кб, то должна быть нагрузка на диск. Да и все равно это слишком долго - 17 с

сеть не грузится, кэш сбросил, также выполняется

Клиент для базы данных локальный или удаленный?

я делаю локально

черз psql или pgadmin3

я делаю локально

ОК

В момент выполнения долгого запроса в process list есть Postgres который есть 100% CPU?

неа

очень страано

iowait?

тоже ничего

толи винда гонит, толи какие то непонятные вещи происходят

смотрел в process explorer

единственное что больше становится это сеть 5мбайт

я посмотрел документацию. когда создаем таблицу с toast, для него создается вспомогательная таблица. в ней даные порезаны на чанки и собираются по идентификатору файла и порядку следования. вот эта таблица нас и интересует. посмотрите, как она называется и сколько планировщик идет в ней строк запросом select relname, reltuples from pg_class where oid = (select reltoastrelid from pg_class where relname = 'config');

relname | reltuples —---------------+---------— pg_toast_341721 | 259795 (1 строка)

данные в этой таблице вы можете посмотреть запросом select * from pg_toast.pg_toast_341721;

и посмотреть, как быстро оттуда выбирается ваш 10мб бинарник