Проблемы с производительностью SELECT в postgresql 9.1

Я создаю большую базу данных postgres 9.1 на Ubuntu 12.04 с одной таблицей, которая содержит около 80 миллионов строк или около того. Всякий раз, когда я запускаю оператор SELECT:

SELECT * FROM db WHERE ID=1;

Выполнение запроса, возвращающего всего несколько тысяч строк, занимает почти 2,5 минуты. После запуска нескольких диагностик дискового ввода-вывода я думаю, что проблема не в этом, но на всякий случай ниже приведены результаты диагностики. (У меня 2 ГБ ОЗУ). Я не совсем уверен, что здесь хороший результат, но кажется приблизительным, учитывая статистику, найденную для других серверов в Интернете.

time sh -c "dd if=/dev/zero of=bigfile bs=8k count=500000 && sync"


500000+0 records in
500000+0 records out
4096000000 bytes (4.1 GB) copied, 106.969 s, 38.3 MB/s

real    1m49.091s
user    0m0.248s
sys     0m9.369s

Я значительно изменил postgresql.conf, увеличив эффективный_кэш до 75% оперативной памяти, общие_буферы до 25%, сегменты контрольных точек до 15, рабочую_память до 256 МБ, автоочистку, SHMMAX в ядре и т. д. У меня было некоторое увеличение производительности, но не более чем на 5% лучше. Сеть не должна быть проблемой, так как даже на локальном хосте она занимает много времени. Я планирую добавить еще больше данных, и время запроса, похоже, быстро растет с увеличением количества строк.

Кажется, я должен иметь возможность запускать эти операторы SELECT за несколько секунд, а не за несколько минут. Любые предложения о том, где может быть это узкое место?


person froot93    schedule 25.11.2012    source источник
comment
Покажите нам план выполнения запроса и включите определение таблицы (create table...). См. также здесь: wiki.postgresql.org/wiki/Slow_Query_Questions   -  person a_horse_with_no_name    schedule 25.11.2012
comment
Что вы сделали с автовакуумом?   -  person kgrittn    schedule 25.11.2012


Ответы (1)


извините, если это непростительно очевидно, но есть ли у вас индекс столбца ID?

Кроме того, хотя я не виню диск, вы просто протестировали последовательную пропускную способность, что очень мало говорит вам о задержке. хотя я должен сказать, что 38 МБ / с не впечатляет даже для этого показателя ...

person markhahn    schedule 25.11.2012
comment
У меня не было индекса, спасибо за предложение. Я надел один, и теперь запросы сократились примерно до 70 секунд. Хотя все же намного дольше, чем хотелось бы. Мысли о погоде проблема с дисковым вводом-выводом? - person froot93; 25.11.2012
comment
Вы запускали VACUUM ANALYZE после создания индекса? Сколько строк на самом деле имеют id =1 ? Сколько нет? - person wildplasser; 25.11.2012
comment
около 8000 строк имеют id=1 (есть составной ключ с отметкой времени), а остальные нет (99,99%). Я создал второй индекс (это плохой стиль?) только для столбца идентификатора вместо составного ключа. Теперь запрос выполняется за 4 секунды. Спасибо!!! - person froot93; 25.11.2012
comment
@ froot93: В каком порядке был ваш составной ключ? Если id был первым, второй индекс не нужен (сохранение индекса требует времени на вставки). 4 секунды все еще звучит медленно. Может быть, вы сделаете то, о чем просил a_horse_with_no_name в своем комментарии. - person j.p.; 26.11.2012