db2内存功能配置深入分析 再回首 - 3

tubietubie

package cache



中文的直译是程序包缓存。

但是这个缓存恰恰不是程序包缓存，而只是动态和静态sql语句的缓存。

以及相应的语句的执行的查询计划和db2的为之设置的查询路径。



我们都知道，在我们的oltp的使用场景中，其实我们执行的sql语句总是比较集中的，也是符合我们的社会的比较普遍的28定律的。

所以，package cache的设置还是比较重要的。



这个内存是在db初始化的时候分配，

在数据库关闭的时候释放该内存给操作系统。

可以在线配置并且可以立即生效。



如果这个值设置成-1，曾经有我的用户认为设置成-1是代表无限大，

其实这里又恰恰相反。

-1只是代表该值是maxappl*8*data page的这样的一个值。









所以

此时我们再回首一下

db2的共享内存是包括以下：

bufferpool

util_heap_sz

dbheap

locklist

pckcashezs

sheapthres

另外

再加上

10%的消耗。



在这里，

我要建议所用还在使用32bit实例的db2的用户，

请立刻将你们的实例升级到64bit

32bit实例的共享内存只能使用1.97gb左右，显然，这是对于我们目前的大多数的生产系统是远远不够的。

我有个金融用户，居然实例还是在32bit。

但是他们的机器居然配置了64gb的内存，但是db2的性能很差，cpu大量wait,disk io负荷很高。

所以，强烈建议他们立刻升级到64bit。

当然升级完之后的应用的测试是很重要的。







应用程序共享内存   application shared memory



app_ctl_heap_sz

app control heap



这个东西，我的学员很多时候都迷糊，我如果有段时间不摸db2的话，我也会比较晕。

虽然数据库这玩意发展到今天，算是一个比较成熟的东西了，但是我发现随着我的研究深度越深，我发现这里面的概念和知识就会越多。

所以，就会越熟悉，越惶恐。



我们都知道，在实例范围，

应用程序向db2的engine发请求的时候，这些请求时由agent这样的组件来进行转发。

那么agent是什么？

代理？

代理后面是什么？

我们总不希望知道agent就是一个用来转发请求的代理这个东西？



这样的解释似乎不够。

后来，db2一个老外从美国来北京公干，我约他和喝咖啡的时候向他请教了这个问题，

原来db2底层还有个专门用来处理请求的底层组件，叫  engine dispathable unit

简称  EDU

那么agent就是这个组件的进程或者线程。



app control heap这个内存堆实际属于为每个单独的应用程序来服务的。

在应用程序链接到db2的时候被分配，应用程序结束的释放。



这样的内存堆是被同一个应用程序的所有的并发代理和子代理来共享。

主要用来存放同一个应用程序中的所有的代理来共享彼此之间的协调处理请求的信息。



最少的对这个堆的使用时非分区的数据库的最大并发的请求是一个的情况。









sortheap



毫无疑问，

当我们的程序在做大量的sql计算和排序的时候会使用这个sortheap。

比如sql中的order,group等等情况。

db2会在我们制定sortheap大小的内存中来将相应的数据进行缓存，并进行各种排序和计算，然后将正确的结果集返回给客户端，

所以这样的内存一般是在olap的场合中会使用很多的内存，

在oltp的场景应用中很少使用。

原本是这样。

可是现在的oltp也不是再是单纯的oltp了，

也会夹杂着很多很变态条件的查询，

但是接下来的更多的系统性能的考虑和架构考虑却不管了。

所以

我总是看到，用户的动不动就是ibm p670,p690的机器加上ibm的大型的存储，甚至是在欧洲很诟病的shark，

但是呢

性能很差，惨不忍睹

其实就是数据库架构的问题，应用功能的问题，当然还有其他的设计和配置的问题。

总之

目前我的伟大的祖国

我的伟大的祖国的硬件的基础建设已经相当好了。

从各个城市的高楼大厦到各个机房的建设到道路建设到。。。





但是

我说实话

全中了美国人的圈套

正如《货币战争》所说

这就是我们的所谓的现代化

我们不懂构成现代化的所有的根本，我们似乎享受到了现代化。

但是回头发现我们的财富没有了。

这是发生在这个星球上的最荒诞和无耻的忽悠和掠夺。



所以

我们躺在最好的硬件上面

却不知道如何更好地利用和使用，

不知道如何更好地利用来产生价值。

这是体制的问题。

我无可奈何。

希望这次的经济阵痛来的更猛烈些，更摧枯拉朽。









statement heap



顾名思义

这肯定是用来存放sql语句的。

不同的是，这个内存堆是在sql语句在预编译和绑定过程中使用的。

在说的透明一点

这个内存堆就是sql预编译的工作台。

对于每个静态sql的处理，

内存的释放是随着预编译或者绑定的结束而释放。

这个参数我觉得不是很重要。

因为我们知道大部分的程序是嵌入式程序，sql早就预编结束，程序改动很少。

动态的sql其数量还是很少的。

原文链接：  http://www.ituren.org.cn/html/jishusuibi/200807/03-93.html