shared_buffers大小調整：
SELECT
usagecount，count（*），isdirty，
round（（count（*）/ max（total_cache.cnt）:: float * 100）:: numeric，2）as percent_of_total_cache
FROM pg_buffercache，
（select count（*）as cnt from pg_buffercache）as total_cache
GROUP BY isdirty，usagecount
ORDER BY isdirty，usagecount;
usagecount | 計數| isdirty | percent_of_total_cache
------------ + -------- + --------- + ----------------- -------
0 | 44204 | f | 16.86
1 | 39288 | f | 14.99
2 | 18917 | f | 7.22
3 | 10702 | f | 4.08
4 | 39549 | f | 15.09
5 | 109484 | f | 41.76
（6行）
usagecount | 計數| isdirty | percent_of_total_cache
------------ + -------- + --------- + ----------------- -------
0 | 44204 | f | 16.86
1 | 39288 | f | 14.99
2 | 18917 | f | 7.22
3 | 10702 | f | 4.08
4 | 39546 | f | 15.09
5 | 109435 | f | 41.75
5 | 52 | t | 0.02
（7行）
usagecount | 計數| isdirty | percent_of_total_cache
------------ + -------- + --------- + ----------------- -------
0 | 44204 | f | 16.86
1 | 39288 | f | 14.99
2 | 18917 | f | 7.22
3 | 10702 | f | 4.08
4 | 39546 | f | 15.09
5 | 109487 | f | 41.77
（6行）
檢查結果，我發現超過50％的buffercache塊被累積，使用次數高達4.5。
這是一個強有力的證據，我需要增加shared_buffer的值。正如我有一個專用數據庫服務器與32 GBRAM，I增加從值的2 Gb到4GB。
設置shared_buffers太難：
進出postgres的數據塊都通過shared_buffers。只是回顧一下我鏈接到的博客文章，每當在共享內存中使用一個塊時，它就會增加時鍾掃描算法，范圍從1-5,5是極高的使用數據塊。這意味着高使用率塊可能會保留在shared_buffers中（如果有空間），如果需要更高使用率的空間，則低使用率塊將被移出。我們認為簡單的插入或更新會將使用次數設置為1.因此，現在我們看一下當使用次數減少時的差異。
edb postgresql :
亞馬遜配置75%內存，引發的問題。
測試tps：
序號 參數配置 第一次 第二次 第三次 平均值
1 shared_buffers=128MB(默認) 249 126 145 =173
2 shared_buffers=4GB 357 357 373 = 362
3 shared_buffers=8GB 362 363 415 =380
4.shared_buffers=24GB 378 368 397 =381
預熱緩存測試結果：
序號 參數配置 第一次 第二次 第三次 平均值
1 shared_buffers=128MB(默認) 211 194 207 204
2 shared_buffers=4GB 1225 1288 1321 1278
3 shared_buffers=8GB 1176 1291 1144 1203
4.shared_buffers=24GB 1285 1250 1309 1281
當shared_buffers=4GB時，數據不能完全裝下，所以優先預熱索引，將索引加載到緩存的tps和8GB，24GB表現差別不大