Блог

Главная - Вопросы по программированию - Есть ли какой-либо способ уменьшить отклонение производительности PostgreSQL между несколькими итерациями?

Есть ли какой-либо способ уменьшить отклонение производительности PostgreSQL между несколькими итерациями?

postgresql

#postgresql

Вопрос:

Значения NOPM, полученные с помощью скриптов HammerDB-v4.3 (schema_tpcc.tcl и test_tpcc.tcl ) для нескольких трасс. Ожидаемое отклонение производительности между несколькими испытаниями должно составлять менее 2%, но наблюдается больше.

Конфигурация оборудования

 Architecture        x86_64
CPU op-mode(s)      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              256
On-line CPU(s) list: 0-255
Thread(s) per core:  2
Core(s) per socket:  64
Socket(s):           2
NUMA node(s):        8
L1d cache:           32K
L1i cache:           32K 
L2 cache:            512K
L3 cache:            16384K
OS: RHEL8.4
RAM SIZE:512
SSD:1TB

Postgresql.conf

 autovacuum_max_workers = 16
autovacuum_vacuum_cost_limit = 3000
checkpoint_completion_target = 0.9
checkpoint_timeout = '15min'
cpu_tuple_cost = 0.03
effective_cache_size = '350GB'
listen_addresses = '*'
maintenance_work_mem = '2GB'
max_connections = 1000
max_wal_size = '128GB'
random_page_cost = 1.1
shared_buffers = '128GB'
wal_buffers = '1GB'
work_mem = '128MB'
random_page_cost = 1.1
effective_io_concurrency = 200

Сценарии HammerDB
>> cat schema.tcl

     #!/bin/tclsh
    dbset db pg
    diset connection pg_host localhost
    diset connection pg_port 5432
    diset tpcc pg_count_ware 400
    diset tpcc pg_num_vu 50
    print dict
    buildschema
    waittocomplete

ЗАПУСТИТЕ ТЕСТ, т.Е. Начните с 1VU, затем 2, 4 и т. Д

   | Virtual Users | Trail-1(NOPM) | Trail-2(NOPM) | %diff   |
  |---------------|---------------|---------------|---------|
  | 12            | 99390         |     92913     | 6.516752|
  | 140           | 561429        |    525408     | 6.415949| 
  | 192           | 636016        |    499574     | 21.4526 |
  | 230           | 621644        |    701882     | 12.9074 |

Комментарии:

1. Ожидаете ли вы, что кто-то купит машину, подобную вашей, установит HammerDB, повторит ваш эксперимент и проанализирует случай?

2. Воспроизведение вопроса будет практически невозможно, и неясно, что это за вопрос и его обоснование.

Ответ №1:

В обсуждениях HammerDB уже есть исчерпывающий ответ на этот вопрос.

Вы делаете предположение, что PostgreSQL будет линейно масштабироваться для интенсивной рабочей нагрузки OLTP на 256 логических процессорах определенного типа. Однако, если рабочая нагрузка испытывает высокую конкуренцию, производительность не будет такой, как ожидается, для конкретной комбинации аппаратного / программного обеспечения из-за блокировки и блокировки — этого следовало ожидать. Ваш опыт может отличаться на разных аппаратных средствах (с одной и той же базой данных) и / или с другой базой данных (на том же оборудовании). Например, вы можете обнаружить, что более высокое количество ядер приводит к снижению производительности, поскольку дополнительные ядра увеличивают конкуренцию, снижая пропускную способность.

Вам нужно следовать совету в сообщении «Обсуждения» и анализировать события ожидания с помощью средства просмотра графических показателей HammerDB v4.3 для pg_active_session_history или напрямую с помощью SQL. Это направит вас к точной причине конфликта (с определенной комбинацией аппаратного и программного обеспечения — LWLock выделяется розовым цветом в средстве просмотра или найдите это в выходных данных запроса). Если это не позволяет вам напрямую диагностировать проблемы, тогда потребуется нанять консультанта PostgreSQL, чтобы объяснить вам проблему.

Метки: