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表现差别不大