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

tubietubie · 发表于 2008-8-24 11:11

再回首是我很喜欢的一首歌。那个时候我正青春萌动，血液沸腾，诗性正浓。

每天的快乐就是写点歪诗给女生看，然后看到女生围在一起看，心中很是享受。

对，我少年的时候就是好色，虚荣，且好斗。

哈哈哈哈，我主动承认，你们还有啥好拍的？

这个文章起这个名字是因为这个关于db2的内存问题我的是已经再回首过N次了。

db2内存这个事情也是我每次讲课都要重点讲解的，大家都偏执地认为性能就会跟内存有关，似乎内存，性能问题立刻迎刃而解。

在如今的db2中，或者在如今的系统中，内存的设置从来就不是性能问题的关键，或者对性能问题的影响只会在10%左右。

当然，我再重申，影响性能问题的根本和关键因素是数据库的架构和sql设计。

只是在这2个方面，遇到的制度阻扰，人的观念和行为惯性，协调难度，要大很多，而国内的软件商总是在用户面前矮一头，说话不敢大声，

更不敢或者没有信心或者没有底气去跟用户谈这方面的事情。

事实是什么呢？

事实是用户大都是希望事情能够做好，系统搁在那里3年5年不出任何状况，用户愿意大家把事情做得更好，

问题是用户有用户的表达方式和语言模式和行为习惯。

软件商的项目经理总是看不透其实用户也是人，用户也需要有愉悦的交流和沟通，用户也需要有朋友，用户也需要有个NB的专家让他们可以依赖。

我们的项目经理们总是把自己的无穷的内心摁死在他自己的名片定义上了。

很多场合，很多事情，我是软件商或者承包商请去的，按理说我不能讲话，至少不能随便讲话，但是很多次我在旁边看不下去，

承包商的项目经理抖抖索索，没有信心，知识贫乏，无法提供好的思路和方案给用户，

更重要的是他们根本不了解用户实际要什么，用户实际要达到什么效果就可以了就可以请我们喝酒然后大家散伙了，

目前的中国的用户的心理基本都是希望迅速满足他们的指定it需求，不要让他们跟着我们陪着我们辛苦，他们不想辛苦不想熬夜，他们更不想一个项目

来回倒腾搞了几次还搞不好，那样他们心里会很惊慌和没有信心和惶恐。

所以，想目前的精心准备，是永远必要的和重要的。

我们要在用户面前表现出来的就是像风一样刮过键盘，然后项目结束了，所有验收很顺利，用户心理暗想：总算遇上牛人了，这下踏实了。

所以很多时候，我都按耐不住，挑头组织承包商用户开发商把项目会一开，然后开工。

db2的内存的信息捕获通常是通过snapshot来获得，这在oracle中也是一样，一个动态的时间点捕获一堆消息，然后自己再想办法或者做工具来分析。

db2mtrk

实际上是一种轻量级的snapshot，而且这个工具它将内存的信息单独提纯出来了，总比我们痛苦的研究snapshot文档要轻松很多。

我们通常讨论是db2的内存是3个层面的。

instance

database

agent

实例默认已经打开了所有的这些监控开关，所以我们不再需要去打开新的内存监控开关了。

db2mtrk

这个工具提供了完整的instance,db,agent的内存信息，同时显示了各个存储池的具体的分配信息。

当前大小

最大允许尺寸就是hard limit

最大值，就是高水平线

内存类型就是内存用途

分配内存池的代理

在分区数据库当中，特定分区的db2mtrk只能返回当前分区的内存信息。

db2mtrk的一些options参数

-i 实例内存

-d db内存

-p 私有代理内存

-w 当前尺寸

-m 最大允许尺寸

-v

-r 就是每隔时间间隔的反复执行

我其实是很不喜欢来写任意命令的语法和参数，我认为所有的这些都是固定的阅读工作，没有什么技术含量和技术技巧的，

我觉得一个好的文章应该是生动地去说明工作机制和原理。

bph

我们在使用db2mtrk命令的时候可能会发现一堆缓存堆(bufferpool heap),那是因为每个数据库，db2会因为一些内部环境的需要而创建了4个隐藏的bufferpool，

这四个隐藏的缓冲池相当于地下党，我们不能知道他的存在，但是他们确实存在为db2的工作默默服务，

有个显式的bufferpool就是我们都知道的ibmdefaultbp，

这样我们发现一个db创建了之后，我们在用db2mtrk命令的时候我们就会发现有5个bufferpool heap。

当然，db2也会有自己的gui工具来管理它的内存，但是我是没有这个习惯来使用它

Db2内存的基本模型

当下列事件发生的时候，那么db2会为dbm的每个instance分配内存

Db2start

分配dbm范围的全局内存

数据库的激活

分配数据库范围的全局内存

应用程序的连接

分配应用程序组的内存使用

代理的创建

创建代理的私有内存

缓冲池的单位依然还是page。

但是在底层，当有各种组件对内存有请求的时候，db2是以block为单位从oss那里在pool的范围内来请求内存的。

在早期的db2中，缓冲池是叫logically bound。

我对这个词一直有点不知道该如何理解。

叫逻辑空间地界？

对于bound我一直有点迷糊。所以遇到这种概念的时候我都是迷迷糊糊使用英文单词，可怜我的学员睁大迷茫的双眼看着我，真不好意思。

logically bound，在db2里面的意思就是设置好的尺寸大小就是该存储池的最大尺寸，当前使用的大小是已经分配的底层内存block数量。

但是这样的管理会产生不少地址碎片，显然这种模式的内存管理不是什么好办法，不是长久之计。

所以db2在后来的版本里面将这样的管理改成从地址空间按需分配。

这样就避免了碎片的问题。

应用程序组的内存使用

首先每个应用程序都会从共享内存中分得自己的内存

以下是配置参数中的关于应用程序组的内存

Appgroup_mem_sz

是说从共享内存中分得的给该应用程序组的内存

Groupheap_ratio

是说可以为共享堆所分得的应用程序组共享内存的最大百分比

App_ctl_heap_sz

是说为组里面的每个应用程序分得的控制堆的内存大小

原文链接： http://www.ituren.org.cn/html/jishusuibi/200806/24-88.html