有时候一本书不是每一章或者每一部分都写的让你觉得可以仔细的阅读后能得到什么, 本期出于这个状态, 书中的第一句中提到 effecitve cache size 应该进行评估,评估的标准系统的系统的内存怎么能满足操作系统中磁盘的caching 和 当数据库在正常运作后的内存的使用. 整体来说对于postgres来说这个值在50% - 70% 与之有关的设置例如 random_page_cost 的值,会影响index scan 或 sequential scans 在数据查找中的到底更偏向于那个.默认是4.0 在使用 san/nas 技术可以将其调整为3 SSD的使用可以将其调整为1.5 到2.5.
实际上在读完这段,粗体部分个人能力,我没有太明白他要表达什么.
所以下面的文字,是针对上面粗体的扩展
举一个例子, 例如我们有100G的内存,我们到底能有多少的EFFECTIVE_CACHE_SIZE, 我们有2G 供给应用系统, 3GB 给postgresql来运行自己的processes, 剩下的, 就是供给postgresql 的shared buffers 和FILESYSTEM CACHE
Share buffers 和 filesystem cache 主要的作用就是缓存数据, 通过缓存数据来满足数据处理时,具体的信息一定在内存中存在.
其实到这里有两点是模糊的, 1 连接到POSTGRESQL的SESSION 是否需要内存, 2 数据的排序和临时表等等的内存释放包含在 effective_cache_size 也就是ORACLE 中的 SGA PGA的含义,在PG中是否有明确的区分.
这些都是本期要弄一个清楚的问题.
另外要明确的是,effective_cache_size被设置的意义在哪里, 还是回到根本上,数据库的性能,有效的配置和设置effective cache size 真正的意义是提高数据库运行时的性能.
有效能承载这些数据,让查询优化器能识别这些,更有效的利用这些内存, 在源代码中有一段注释
实际上Postgresql 的内存也和其他数据库分为两块, 这里PG 内存主要由 local memory area 和 shared buffer pool 组成, shared buffer pool 其中就包括 share buffer wal buffer commit log 几部分, 而local memory area 主要由 work_mem maintenance work mem , temp buffer 组成.
其中CLOG是提交日志(CLOG)保存所有事务的状态，是并发控制机制的一部分。提交日志被分配给共享内存，并在整个事务处理过程中使用。
到此,上面的两个问题就很清晰了
1 share buffer 的分配很重要, 他提供了数据库服务中到底有多少数据库可以hit buffer , 这严重影响数据库对外服务的性能和质量.
2 work_mem 的分配, 一个连接将使用一个work_mem 来进行数据的处理,连接数 * work_mem 就是你的local memory area 中的使用 内存的大头.
例如
我们支持500个连接, 每个连接最大使用 4MB的work_mem 则 500* 4MB ,将近会有2000MB在这一项中被使用.
所以这就引出另外的一些问题, 如果索引数据会驻留在 share buffer中, 则使用什么样的 index type 更有利于查询,并节省内存, 这在POSTGERSQL 中是可以探讨的, 因为PG支持的索引的TYPE 多,并且部分类型在部分应用场景中索引可以变得很小,这一定是有利于系统的性能的和节省内存.
另一个部分就是 work_mem的设置, work_mem给的较大,则会在连接数较大的时候,浪费过多的内存, 而设置的过小,则也会影响系统查询的性能. 这也是一个见仁见智的问题, 例如你的系统是 OLAP OR OLTP , 则在这个这个设置上也会有不同的做法.
这里对于pg初始时有一个压测工具,便于对你当前的postgresql 的系统性能进行一个初步的理解.
