Postgresql性能优化 （三）
查询类：shared_buffers参数
大家都很熟悉的参数吧，共享内存的大小当然是越大越好啦。先别急，再仔细想想。
读数据时：
数据库先在共享内存里查找，找不到的话，再检索磁盘。检索磁盘时先查OS的缓存，找不到的话才会实际扫描磁盘。然后把数据放到OS的缓存，再返回给数据库，也就是放到共享内存里面。
按照这个逻辑，同一份数据，同时存在于OS的缓存和数据库的共享内存里面。 如果OS的缓存太小的化，就会放生swap，把数据放到磁盘里，当然效率也就会降低了。
写数据时：
和读数据相反，先更新共享内存里面的内容，攒到一定数量或者到了一定时间段，再把更新的数据反应给OS。OS也是先更新到缓存，再实际更新到磁盘里。
如果需要更新的数据超过了OS的缓存，更新处理会等OS整理缓存以得到可利用的空间。
更新处理比较多的数据库，或者vacuum处理的时候，需要占用大量OS缓存。一定时间内无法确保到需要的空间时，数据库服务也有可能会停止。
综上所述，共享内存的值与OS的缓存一致是比较安全的。
如果以检索为主的话，共享内存大一些也没什么问题吧。当然前提是数据库基本都能放到共享内存里。
查询类的几个参数可以用以下的关系表示。
物理内存 ＝ work_mem " 最大同时连接数" 平均使用work_mem数 ＋ shared_buffers ＋ effective_cache_size
以上公式只适用于数据库专用服务器的场合。
大家都很熟悉的参数吧，共享内存的大小当然是越大越好啦。先别急，再仔细想想。
读数据时：
数据库先在共享内存里查找，找不到的话，再检索磁盘。检索磁盘时先查OS的缓存，找不到的话才会实际扫描磁盘。然后把数据放到OS的缓存，再返回给数据库，也就是放到共享内存里面。
按照这个逻辑，同一份数据，同时存在于OS的缓存和数据库的共享内存里面。 如果OS的缓存太小的化，就会放生swap，把数据放到磁盘里，当然效率也就会降低了。
写数据时：
和读数据相反，先更新共享内存里面的内容，攒到一定数量或者到了一定时间段，再把更新的数据反应给OS。OS也是先更新到缓存，再实际更新到磁盘里。
如果需要更新的数据超过了OS的缓存，更新处理会等OS整理缓存以得到可利用的空间。
更新处理比较多的数据库，或者vacuum处理的时候，需要占用大量OS缓存。一定时间内无法确保到需要的空间时，数据库服务也有可能会停止。
综上所述，共享内存的值与OS的缓存一致是比较安全的。
如果以检索为主的话，共享内存大一些也没什么问题吧。当然前提是数据库基本都能放到共享内存里。
查询类的几个参数可以用以下的关系表示。
物理内存 ＝ work_mem " 最大同时连接数" 平均使用work_mem数 ＋ shared_buffers ＋ effective_cache_size
以上公式只适用于数据库专用服务器的场合。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/378235/viewspace-680763/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
Postgresql性能优化 （二）
下一篇：
Postgresql性能优化 （四）
请登录后发表评论
登录
全部评论
