|
书接上回
应用程序堆
applheapsz
本内存参数主要用来存放某一个应用程序内部的代理及子代理的执行的sql语句的复制,
这样的内存在相应的代理开始工作的时候被分配,在代理结束工作的时候,这样的内存自然释放,
刚开始的只是会初始化一个最小的值出来被使用,随着需要慢慢增加,一直达到applheapsz所设定的值。
你还是很难估计这样的参数应该配置多大的内存来使用,或者db2自己觉得其算计方法比较复杂和难以教授,或者其他的什么的原因,
反正db2说这个参数很难去预计和计算,所以,你就用着吧,不够用报错的时候,你自然去添加就完了。
在分区数据库环境中,用app_ctl_heap_sz这个参数来代替applheapsz参数的职位。
统计参数堆
stat_heap_sz
顾名思义
望文生义
就是统计时候用的内存区域
也就是db2在做runstats的时候所用的内存区域。
runstats工作结束,stat_heap_sz内存释放。
stat_heap_sz内存是隶属于utility heap。
所以stat_heap_sz的上限就是utility heap的最大值。
当我们在使用分布式统计参数的时候就是分区环境的时候可以适当扩大这样的参数。
无足轻重
大不了runstats慢点吧
但是在一些单位的情况下面,核心库就是only one .
乱七八糟的什么事情都是要连这个核心库,这个库显得特别繁忙,
晚上的时候要做日终,报表,统计,清洗,还有数据的同步等等一堆的事情,还要备份,
晚上的时间窗口也是很紧密和很紧迫。
所以在这样的情况下面,runstats也是个要挤时间的事情。
不过我是很喜欢在这样的数据库需求的环境来工作的,这样,技术的专业性才有适合地方来施展。
否则,你在一个无所谓数据库效率的环境中,你跟用户谈这些,用户心理笑话你迂腐。
aslheapsz
application support layer heap
说白了,这个内存就是代理和应用程序之间的通讯缓存。
当代理进程开始为某个应用程序开始启动的时候开始被分配。
当代理进程结束时内存释放。
如果内存不是足够大,那么传输肯定是要被分段。
通常这样的内存是为blocking 游标工作。
计算公式:
aslheapsz>= (sizeof(input SQLDA) +sizeof(each input SQLVAR) +sizeof(output SQLDA) +250) /4096
FCM_NUM_BUFFERS
主要是在分区数据库环境中的内存参数,是实例级别的参数。
用来是各分区节点的互相通讯的缓存,
是从每个数据库分区的内存池里面分得,如果分区都在一个物理节点上面,
那么他们就共享同一个fcm缓存。
utility heap 和 load
load 操作当然要使用utility heap中的一部分。
一般来说,load操作开始就直接从 utility heap中切掉20%
另外的load会直接切掉另外的20%
数据库默认的utilheap一般都比较小。
会影响load操作的性能,会,这是肯定的。
但是不是绝对影响。
因为load命令中还有个data buffer的设置。
utility heap 和 bakcup 和 restore
当我们对磁带进行备份的时候,我一直建议在使用缓存的时候要用4kb的data page 大小。
如果用户对于这样的选择的data page大小的性能不满意的时候,
我们可以更改块的大小,
但是我还是要建议你们用一些比较小的缓存区。
关键的问题是我们都知道磁带总是在保持流带化,
确实我们也知道比较大的块的io确实有一定的性能优势。
但是你有没有想过,备份是个稳定的快速的过程,
当我们的大的缓存在等待数据预取的时候,
我们此时就能明白我们用数量众多的小缓存还是很有好处的。
这是原理的说明,如果要验证的话,本身就是个麻烦的事情,我们需要准备环境,和场景压力和测试基准。
永远不要小看实验。
实验是理解知识消化知识升华知识和发现知识的环境。
我不知道国人为什么如此反感和藐视实验。
其实
我知道这就是一个浮躁的心态。
每人都想迅速出名,上电视被采访,住洋房开养车等等。
但是很多的科学和诺贝尔都是从实验室中诞生的。
在美国,实验室的地位是很重要的。
早期,在西南联大的那个时代,那些大师就非常坚持学生一定要重视实验。
内存的罗嗦到此结束。
希望大家提意见。
老实说,我不是在写普及文章,我是在写面向有一定基础的兄弟姐妹看的东西。
更加详细地和基础地,我实在不想写了,那些东西我已经讲课讲了N次了,再写出来我自己都快烦死了。
反正是瞎写嘛,就有点想到哪写道哪。
大家凑乎着看吧。
赶紧出去抽支烟放松一下。
原文链接: http://www.ituren.org.cn/html/jishusuibi/200807/04-94.html |
|