使用HammerDB-v4.3脚本(schema_tpcc.tcl和test_tpcc.tcl )为多个跟踪捕获NOPM值。多个试验之间的预期性能偏差应该小于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
>>cat schema.tcl的HammerDB脚本
#!/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 |
发布于 2021-12-03 11:41:35
这个问题在HammerDB discussions上已经有了一个全面的答案。
您假设PostgreSQL将针对特定类型的256个逻辑CPU上的密集型OLTP工作负载进行线性扩展。但是,如果工作负载遇到高争用,则由于锁定和锁存,特定硬件/软件组合的性能将不会达到预期-这是意料之中的。在不同的硬件(具有相同的数据库)和/或不同的数据库(在相同的硬件上)上,您的体验可能不同。例如,您可能会发现更高的核心计数会导致较低的性能,因为额外的核心会增加争用,从而降低吞吐量。
您需要遵循讨论帖子中的建议,使用SQLV4.3图形指标查看器或直接使用HammerDB分析等待事件。这将引导您准确地找到争用的原因(使用特定的硬件/软件组合- LWLock在查看器中以粉色突出显示,或者在查询输出中查找)。如果这不能让您直接诊断问题,则有必要聘请PostgreSQL顾问为您解释问题。
https://stackoverflow.com/questions/70194728
复制相似问题