調整Postgresql之後，PgBench結果更糟

我在Digital Ocean的8gb Ram/4 CPU/80gb SSD雲服務器上測試PostgreSQL。我最初使用postgresql.conf中的默認設置運行PgBench，然後修改了一些常用設置 - shared_buffers，work_mem，maintenance_work_mem，effective_cache_size - 以反映8GB的RAM。在運行第二組測試後，我注意到我的一些結果實際上更糟。有關這可能是爲什麼的任何建議？我對PgBench比較陌生，一般來說對PostgreSQL進行了調整。調整Postgresql之後，PgBench結果更糟

設置：

的shared_buffers = 2048MB
work_mem = 68MB
maintenance_work_mem = 1024MB
effective_cache_size = 4096MB

測試：

pgbench -i -s 100
pgbench -c 16個-j 2 -T 60 -U postgres的postgres的
pgbench -S -c 16 -j 2 -T 60 -U postgres的postgres的
pgbench -c 16 -j 4 -T 60個-U postgres的postgres的
pgbench -S -c 16 -j 4 -T 60 -U postgres的postgres的
pgbench -c 16 -j 8 -T 60個-U postgres的postgres
pgbench -S -c 16 -j 8 -T 60 -U postgres postgres

這些測試有效嗎？這是採用PgBench的有效方法嗎？我應該如何定製測試以正確反映我的數據和服務器實例？

來源

2013-08-23 Jahkobi Digital

什麼是您的random_page_cost和cpu_tuple_cost？試試r_p_c在1.0，然後用c_t_c在0.05重新測試，然後在1.0重新測試c_t_c。運行之前，pgbench是否會發出ANALYZE？你應該手動做嗎？ – bma

對於任何寫密集型基準測試來說，60秒太短。你必須足夠長的基準以跨越幾個檢查點。此外，你還沒有向我們顯示數字。也許你之前和之後都在誤差範圍之內。您更改的最後3個設置不可能與您正在運行的基準相關。除了shared_buffers之外，您還需要查看checkpoint_segments。最後，改變-j似乎並不是非常有趣，除非你想要測試pgbench代碼而不是數據庫;我只是總是將它設置爲等於-c。 – jjanes

什麼意思是「更糟」？你運行pgbench多久了？對於實際值，這個測試應該至少執行2小時。你有什麼版本的PostgreSQL？

注意：您應該非常小心地解釋pgbench結果。可能你應該優化應用程序的執行，而不是pgbench。 pgbench適用於hw或sw檢查，是優化PostgreSQL配置的不好工具。

上面提到的配置變量是配置的基本配置，你可能不會在那裏出錯（服務器不能主動使用swap，這些變量可以確保它）。

，我使用的公式：

 
-- Dedicated server 8GB RAM 
shared_buffers = 1/3 .. 1/4 dedicated RAM 
effecttive_cache_size = 2/3 dedicated RAM 

maintenance_work_mem > higher than the most big table (if possible) 
         else 1/10 RAM 
         else max_connection * 1/4 * work_mem 

work_mem = precious setting is based on slow query analyse 
      (first setting about 100MB) 

--must be true 
max_connection * work_mem * 2 + shared_buffers 
      + 1GB (O.S.) + 1GB (filesystem cache) <= RAM size

WAL緩衝區大小和檢查點段的一般缺省值是太低了。你可以增加它。

來源

2013-08-24 07:15:55

調整Postgresql之後，PgBench結果更糟

回答

相關問題