PostgreSQL VACUUM / CLUSTER / UPDATE磁盘为100％但仅为5MB /秒

Question

我的行为非常奇怪PostgreSQL 9.4。当它在大型表上运行UPDATE或执行大型表的VACUUM或CLUSTER时，它似乎会挂起很长时间。事实上，我最终会在第二天杀死这个过程。奇怪的是，CPU处于空闲状态，同时磁盘活动为100％但是它只报告4-5 MB /秒的读写时间（参见nmap的屏幕截图） ＆amp; atop）。

我的服务器是24CPU，32GB RAM和RAID1（2个SAS 15K x 2）。通常，当磁盘处于100％利用率时，它给出了120-160 MB / s的组合读/写，这几乎可以无限期地保持在> 100MB /秒的持续IO。

即使是终端命令行，系统也变得非常迟缓。我猜它与共享内存和虚拟内存有关。发生这种情况时，PostgreSQL会消耗最大配置的共享内存。

我已禁用交换vm.swappiness=0。我没有玩vm.dirty_ratio，vm.dirty_background_ratio等。禁用系统大页面vm.nr_hugepages=0。

以下是我的postgresql.conf设置：

shared_buffers = 8200MB
temp_buffers = 12MB
work_mem = 32MB
maintenance_work_mem = 128MB
#-----------------------------------------------------
synchronous_commit = off
wal_sync_method = fdatasync
checkpoint_segments = 32
checkpoint_completion_target = 0.9
#-----------------------------------------------------
random_page_cost = 3.2      # RAIDed disk
effective_cache_size = 20000MB  # 32GB RAM
geqo_effort = 10
#-----------------------------------------------------
autovacuum_max_workers = 4
autovacuum_naptime = 45s
autovacuum_vacuum_scale_factor = 0.16
autovacuum_analyze_scale_factor = 0.08

当磁盘只做5MB /秒时，磁盘怎么能达到100％？即使是最耗费时间的随机读/写程序仍然应该更快一些。它必须与PostgreSQL处理映射/共享内存的方式有关。 postgres 9.1也没有发生这种情况。

我正在努力教育自己的磁盘/内存行为，但此时我需要PRO的帮助。

Answer 1

经过长时间的调查，我发现磁盘饱和度与低读/写速度和IOPS数之间存在相关性。 IOPS的数量越大，IO饱和带宽越低。我的问题中的一个截图有＆＃34;转移/秒＆＃34;。当数字变高时，传输速率会下降。

遗憾的是，在数据库配置方面无法做很多事情。 PostgreSQL在很大程度上依赖于共享内存映射文件到内存页面。当需要将一些/所有内存页面同步回磁盘时，对于具有大型表的数据库，可能需要数十/数十万个脏页面才能同步。它会导致大量随机磁盘访问和大量小型原子IO。

由于在我的情况下既不安装SSD也不启用writeback是一个选项，我必须通过从不同的角度接近它来解决问题。我个别地处理了每个案件。

我所拥有的UPDATE语句每次运行时都会影响一半以上或表记录。我没有进行更新，而是每次都重新创建表。这几乎翻了一番。

CLUSTER - 表会导致重建所有表索引，但执行群集的索引除外。对于具有许多索引的大型表，这是在执行群集时牢记这一点的重要考虑因素。

我还将VACUUM替换为ANALYSE，这似乎不会影响表格性能，但运行速度明显快于VACUUM。