Медленное последовательное сканирование PostgreSQL на RDS?

У меня есть экземпляр RDS PostgreSQL, который выполняет простые запросы, намного медленнее, чем я ожидал, особенно последовательное сканирование, такое как копирование таблицы или подсчет таблицы.

Eg. create table copied_table as (select * from original_table) or select count(*) from some_table

Запуск count(*) для таблицы размером 30 ГБ занимает ~ 15 минут (с индексами сразу после вакуума).

Это RDS db.r3.large, 15 ГБ памяти, 400 ГБ SSD. Наблюдая за журналами метрик, я никогда не видел, чтобы IOPS при чтении превышал 1400, а обычно это около 500, что намного ниже моей ожидаемой базы.

Конфигурация: work_mem: 2 ГБ, shared_buffers: 3 ГБ, effective_cache_size: 8 ГБ wal_buffers: 16 МБ, checkpoint_segments: 16

Это ожидаемое время? Должен ли я увидеть более высокий IOPS?


postgresql amazon-web-services rds
person jastr    schedule 29.09.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы мало что можете сделать с запросами простого подсчета, такими как в Postgres, за исключением версии 9.6, в которой реализовано параллельное последовательное сканирование, которое пока недоступно в RDS.

Впрочем, есть несколько советов, которые вы можете найти здесь. Обычно рекомендуется попробовать заставить Postgres использовать сканирование только индекса, создав индексы и столбцы в проекции.

SELECT id FROM table WHERE id > 6 and id <100;
-- or
SELECT count(id) FROM table ...

Таблица должна иметь индекс по этому столбцу.

Запросы, которые вы представили в качестве примера, не избегают последовательного сканирования. Для CREATE TABLE, если вам не важен порядок в таблице, вы можете открыть несколько бэкэндов и импортировать их параллельно, фильтруя по диапазону ключей. Кроме того, единственный способ ускорить это на RDS - увеличить количество операций ввода-вывода в секунду.

person 3manuek    schedule 09.10.2016
comment
Спасибо, но я хочу подтвердить, что мой PostgreSQL настроен правильно и что я получаю от RDS необходимую производительность. - person jastr; 13.10.2016