svmon查看的内存异常问题！
memory 7962624 7406198 556426 607098 1362844
pg space 2097152 11823
work pers clnt other
pin 335455 0 2753 268890
in use 1362844 22 6043332
由上面可见，clnt客户端存储分页占用的内存太多了。请问如何解决？
6同行回答
487890 db2sysc 342704 68435 0 330852 N N N
PageSize Inuse Pin Pgsp Virtual
s 4 KB 257632 3 0 245780
m 64 KB 1221 181 0 1221
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment (lgpg_vsid=0) L 16 16 0 16
261ace 5 work unused segment s 65536 0 0 65536
2b99d5 6 work unused segment s 65536 0 0 65536
19b81 4 work shared memory segment s 65264 0 0 65264
3c1dfa 7 work unused segment s 46865 0 0 46865
16f0ad d work shared library text m 1221 181 0 1221
231dc4 - clnt /dev/lvdb2log:81 s 11838 0 - -
10e00 c work shared memory segment s 1537 0 0 1537
168d2f 3 work shared memory segment s 971 0 0 971
3699ef 2 work process private s 59 3 0 59
parent=24984b
301362 f work shared library data s 12 0 0 12
parent=2094c3
298551 1 clnt code,/dev/hd1:4220 s 12 0 - -
39d05 - clnt /dev/lvdb2catalog:4111 s 2 0 - -
50c08 8 work unused segment s 0 0 0 0
楼上说得那片文章我也看到过，但是好像不是我的这种状况
1、我的占用内存较高的前20个进程，总量加起来就大约和内存总大小相仿了。几乎全部都是db2sysc
2、我用svmon -p查看，没有大页面啊。只有4K和64K
不知道我理解的对不对，请指教！谢谢！收起
我们最初的想法是内存耗尽与这个应用程序有关。但是，使用性能工具进行检查之后，我们改变了想法。
在印度神话中，有一种名为 Sanjeevini 的药可以治愈几乎所有疾病。topas
就是性能工具中的 Sanjeevini。它提供所有系统资源的概况，可以作为性能分析的起点。对于我们的问题，它提供分析问题的基础。在我们第一次观察到这个问题时，topas 显示计算内存的总使用量达到 99%。与此同时，团队也观察到了执行手工事务时的问题。团队当时只执行与一个应用程序有关的测试。
因此，研究过程的下一步是停止应用程序，再次使用 topas 检查计算内存的状态。这时的计算内存是 78%。考虑到没有其他应用程序在运行，这个数字不正常，它向我们提示了新的思考方向。
有助于分析问题的其他工具还有 svmon、vmstat 和 vmo。
svmon 命令
svmon 命令是一个性能度量工具，它捕捉和分析虚拟内存的快照。
svmon -G 命令显示下面的全局内存报告。它显示系统中真实内存和虚拟内存的使用量和空闲量。
|
|
图 1. svmon 全局内存报告
内存报告表明，总内存量为 1998848 个页面（页面大小为 4K），使用了 1996881 个页面，1967 个页面空闲。
在 上面的报告中，空闲页面数量为 1967，但是不能由此断定存在任何与内存相关的限制或内存瓶颈，因为为了提高 I/O 性能，如果应用程序或内核没有明确请求的话，AIX® 会用尽可能多的空闲内存进行文件缓存。另外，报告表明分页空间总量为3145728 个页面，其中使用的分页空间为 99556 个页面。
svmon -P 命令显示所有进程的内存使用量统计数据。
|
|
图 2. 进程内存使用量报告
进程内存使用量报告表明，一个 Java™ 进程使用的内存为 166690 个页面。把这个报告中所有进程使用的内存量相加，我们发现所有进程使用的内存总量远远小于系统的内存总量。这也说明内存并不是限制因素。
vmstat 命令
另一个性能监视工具 vmstat 用于报告内核线程、虚拟内存、磁盘和 CPU 活动的统计数据。
|
|
图 3. vmstat 报告
vmstat 报告表明，空闲内存大约为 114MB。另外，没有报告页面换出。但是最后五项表明，有一个被阻塞的线程，而且系统中发生了一些 I/O 等待。
vmo
我们还使用 vmo 命令检查性能参数。vmo 命令也显示和调整虚拟内存管理器参数。
|
|
图 4. vmo 命令输出
观察 vmo 命令的输出，我们发现 lgpg_regions 被设置为 256，lgpg_size 被设置为16777216（即 16MB）。AIX 把大页面当作固定内存对待，对于大页面不提供分页支持。存储为大页面的应用程序数据会一直留在物理内存中，直到应用程序终止。对于这个应用程序，这意味着 256 个 16MB 的页面被固定并设置为保留。
如果再看一下 图 1（svmon– G 的输出），会发现对于 16MB 的大页面，池大小为256，因为大页面的内存是固定的，256 个 16MB 的页面无法交换出去。看一下图 2（svmon– P 命令），输出的第一行的最后一列是 16MB，对应的值是'N'。这意味着 PID 为 266372 的进程不使用 16MB 的页面；也就是说，这个应用程序不使用 vmo 命令已经保留的大页面。同样，在同一个报告中检查正在运行的其他进程时，发现没有应用程序使用大页面支持。因此，256*16=4096MB 的内存空间被阻塞，但是根本没有任何进程使用它。
在 图 3 中可以看到，物理内存总量是 7808MB。通过上面的分析很容易看出，其中的 4096MB 为大页面保留。这意味着所有正在运行的应用程序只能使用 7808-4096=3712MB。一大块内存被阻塞并且不能得到使用，这就是内存完全耗尽的原因。
因此，要么不为大页面保留内存，要么确保应用程序利用保留的内存。
配置大页面
可以通过配置让应用程序或系统使用大页面。
应用程序的大页面配置
在ldedit 命令中使用 blpdata 标志让可执行文件能够请求大页面。在 参考资料 中可以找到更多信息。
系统的大页面配置
在默认情况下，系统并不为大页面物理内存池分配任何内存。可以使用vmo 命令的 lgpg_regions 和 lgpg_size 选项配置大页面物理内存池的大小。
通过使用 LDR_CNTRL 环境变量，让应用程序的数据和堆内存使用大页面。
在 参考资料 中可以找到关于使用 vmo 命令配置大页面和 LDR_CONTROL 变量的更多信息。
对于上面的案例研究，把 lgpg_regions 的值改为一个名义值，让应用程序使用大页面，这有助于解决内存问题和提高总体系统性能。
决定 lgpg_regions 的值
对 于 lgpg_regions 和与性能相关的其他调优参数的值，无法给出通用的建议；但是，可以通过研究系统的工作负载决定一个名义值。对于上面的案例研究，当导出 the LDR_CNTRL 变量时，应用程序开始使用大页面。在此之后，再次使用vmstat 命令。
|
|
这个命令显示与大页面部分相关的统计数据，时间间隔为 10 秒。
图 5. 大页面统计数据
输出中有一个大页面部分，提供与大页面相关的详细统计数据。alp 和 flp 字段分别表示活跃的大页面数和空闲的大页面数。对于这个案例研究，alp 的值不超过 80。因此，应该把lgpg_regions 的值从 256 降低到 100。这会把大量内存还给 4K 页面的内存池，增加正在运行的其他应用程序可以使用的内存量，提高系统的总体性能。简而言之，应该研究系统的工作负载，然后调整参数，这是高效地使用系统资源的关键。
附件：
我们最初的想法是内存耗尽与这个应用程序有关.zip (139.9 KB)