關於postgresql的SELECT性能問題9.1

我在Ubuntu 12.04上構建了一個大型的postgres 9.1數據庫，其中一個表格可以容納大約8000萬行左右的數據。每當我運行一條SELECT語句時：關於postgresql的SELECT性能問題9.1

SELECT * FROM db WHERE ID=1;

執行只返回幾千行的查詢需要將近2.5分鐘。在磁盤I/O上運行一些診斷之後，我認爲這不是問題，但以下是診斷的輸出。（我有2GB的內存）我不確定這裏有多好的輸出，但是它給出了在互聯網上其他服務器的統計數據。

time sh -c "dd if=/dev/zero of=bigfile bs=8k count=500000 && sync" 


500000+0 records in 
500000+0 records out 
4096000000 bytes (4.1 GB) copied, 106.969 s, 38.3 MB/s 

real 1m49.091s 
user 0m0.248s 
sys  0m9.369s

我有了很大改進的postgresql.conf，助推effective_cache到RAM中的75％，的shared_buffers至25％，CHECKPOINT_SEGMENTS至15 work_mem爲256MB，自動清理，SHMMAX的內核，等我有一些性能提高，但不超過5％。網絡不應該成爲一個問題，因爲即使在本地主機上運行它也需要很長時間。我計劃添加更多數據，並且查詢時間似乎隨着行數迅速增長。

看來我應該能夠在幾秒鐘內運行這些SELECT語句，而不是幾分鐘。關於這個瓶頸可能在哪裏的任何建議？

來源

2012-11-25 froot93

向我們展示查詢的執行計劃幷包含表定義（'create table' ...）。另請參閱：http://wiki.postgresql.org/wiki/Slow_Query_Questions –

你對自動清理做了什麼？ – kgrittn

對不起，如果這不明顯，但你有一個索引ID列？

另外，雖然我不是在責怪磁盤，但你只是測試了連續帶寬，這個連接帶來的延遲很少。儘管我不得不說，即使對於這種措施，38 MB /秒也是不足的...

來源

2012-11-25 18:00:24 markhahn

我沒有索引，謝謝你的建議。我把一個，現在的查詢下降到70秒左右。儘管如此，仍然比我想要的要長很多。關於天氣問題的想法是磁盤I/O？ – froot93

您是否在創建索引後運行'VACUUM ANALYZE'？實際上有多少行id = 1？多少不？ – wildplasser

大約8000行的id = 1（它有一個帶有時間戳的複合鍵），其餘的不是（99.99％）。我在ID列創建了第二個索引（是那種不好的樣式？），而不是複合鍵。現在查詢在4秒內執行。謝謝！！！ – froot93

關於postgresql的SELECT性能問題9.1

回答

相關問題