Конфигурация производительности кажется неэффективной PostgreSQL

Я не очень опытен в базах данных, и я хочу повысить производительность запросов PostgreSQL с помощью конфигурации. Большая часть запроса занимает около 3.5 секунд, чтобы полностью искать в логах. Затем я проверил файл конфигурации и настройки установлены на относительно низкие значения, поэтому я рассчитал наилучшую возможную конфигурацию и ввел ее в psql:

postgres=# ALTER SYSTEM SET
postgres-#  max_connections = '200';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  shared_buffers = '4GB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  effective_cache_size = '12GB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  work_mem = '20971kB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  maintenance_work_mem = '1GB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  min_wal_size = '1GB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  max_wal_size = '2GB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  checkpoint_completion_target = '0.7';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  wal_buffers = '16MB';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  default_statistics_target = '100';
ALTER SYSTEM
postgres=# ALTER SYSTEM SET
postgres-#  random_page_cost = '4';
ALTER SYSTEM

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

SELECT pg_reload_conf();

Но прогресса по-прежнему не было. Перед настройкой work_mem было 4 MB в то время как maintenance_work_mem было 64 MB и даже после увеличения их на эти цифры время, затрачиваемое на запросы к базе данных, было очень похожим.


Таблица:

Таблица была создана автоматически Django (мой веб-фреймворк), поэтому вот так:

CREATE TABLE tablename (
    "id" serial NOT NULL PRIMARY KEY,
    "some_char" varchar(30) NOT NULL,
);

Создание индекса:

CREATE INDEX trgm_idx ON table USING gist (column gist_trgm_ops);

Планы выполнения (объяснить и проанализировать):

 Bitmap Heap Scan on main_question  (cost=1721.05..20990.16 rows=1786 width=436) (actual time=2634.604..2634.634 rows=9 loops=1)
   Recheck Cond: (attr1 % 'querytext'::text)
   Filter: (char_length(attr2) > 300)
   Rows Removed by Filter: 5
   Heap Blocks: exact=13
   Buffers: shared hit=419319
   ->  Bitmap Index Scan on trgm_idx  (cost=0.00..1720.60 rows=5358 width=0) (actual time=2634.578..2634.578 rows=14 loops=1)
         Index Cond: (attr1 % 'querytext'::text)
         Buffers: shared hit=419306
 Planning time: 0.131 ms
 Execution time: 2634.739 ms
(11 rows)

Журналы запросов:

до конфигурации:

(0.000) SELECT typarray FROM pg_type WHERE typname = 'citext'; args=None
(3.568) SELECT "main_model"."id", "main_model"."attribute1", "main_model"."attribute2" FROM "main_model" WHERE ((CHAR_LENGTH(attribute2) > 350) AND "main_model"."attribute1" % 'querytext'); args=(u'querytext',)

после настройки:

(0.000) SELECT typarray FROM pg_type WHERE typname = 'citext'; args=None
(3.555) SELECT "main_model"."id", "main_model"."attribute1", "main_model"."attribute2" FROM "main_model" WHERE ((CHAR_LENGTH(attribute2) > 350) AND "main_model"."attribute1" % 'querytext'); args=(u'querytext',)

как вы можете видеть, время запроса по какой-то причине очень похоже.


Разве эти настройки не должны увеличивать максимальное использование памяти и, следовательно, производительность? Я делаю что-то неправильно?

1 ответ

Установка максимального количества соединений на 200 - верный признак того, что вы новичок в настройке производительности Postgres. Проверьте вики о производительности или некоторые введения на YouTube. Я могу порекомендовать Кристофа Петтуса: PostgreSQL, когда это не твоя работа.

Другие вопросы по тегам