IPS专家秘籍第六期:AIX ulimit设置2

想客户所想，解决客户问题是IPS服务部门一贯遵循的宗旨。在此非常时期，我们真心感谢您长期以来对Power服务器的信任，特意推出客户关怀计划，希望与您同心协力，共克时艰。

IPS专家秘籍是IPS的服务专家通过多年客户IT运维的丰富实战经验，总结出的“系统调优及故障排除文档”。希望通过IPS服务专家们的经验分享，助力客户/合作伙伴排除故障，优化性能，确保IT系统高效、平稳运行。

01 PART 问题现象及初步分析

本期内容主要针对AIX ulimit设置中不合适的stack_hard设置可能造成性能问题：

?AIX环境下，/etc/security/limits关于stack的限制有两个参数，分别是：

?其中stack是软限制（当前限制值），而stack_hard是硬限制（最高可设置的软限制值）。stack_hard取值一般直接采用系统默认值。

?本案例中，客户误将stack_hard设置为-1，造成sqlplus进程启动时，系统CPU消耗显著上升，系统整体性能受到了影响。从如下truss截图可以看到，执行sqlplus历时近41毫秒：

02 PART 详细分析

?在stack的硬限制为-1的情况下，如果64位进程把stack的软限制先通过setrlimit系统接口API先改小，再改成-1/RLIM_INFINITY，就会触发系统分配大量stack segments(4096个)以满足stacksize limit扩充的需求。

?如果stack软限制始终保持为默认的-1，则不会触发（系统默认初始分配16个stack segments，用完再分配新的segments）。

?从trace跟踪看，oracle11gR2 sqlplus会调用setrlimit先改小stacksize(把soft limit设置成32MB)，再改大stacksize(此次size参数取值为当前环境ulimit -s的实际值，在案例的环境中为-1)，正好符合了上述模式。因此触发了大量stack segments分配。

?这样一来，启动、退出sqlplus的过程耗时将会显著增加（fork时分配segments，exit时销毁segments）。如果正好有大量sqlplus进程创建、退出，可能造成极高的sys CPU消耗，影响系统效率。

03 PART 系统工具truss追踪示例

?如下是一个truss 输出片段（第二个参数是指针，使用dbx跟踪可以观察到指针指向的具体值，有兴趣可以自行尝试）：

04 PART 解决方法

?系统配置参数stack_hard不应当设置为-1。通常我们只要求对oracle用户设置stack为-1(软限制)，而stack_hard硬限制默认为8388608blocks，也就是4GB，即16个stack segments (每个segment大小为256MB)。

?Stacksegments 主要存储调用栈信息以及临时变量等等。16个segments对于stack来说已经绰绰有余，即使是负载很重的64位进程，一般也最多只用到几个stack段。因为通常主要的内存数据都集中在共享内存段、数据段、以及文本段。比如Oracle环境下，内存数据主要集中在shared memory segments(比如SGA)、data segments(比如PGA)、和client segments(比如访问的文件)。

?完成修改后，可以看到执行sqlplus的时间从41毫秒缩短为2毫秒。

05 PART 配置检查建议

?Oracle安装手册说明了只建议stack=-1（Soft Limit），并没有要求设置stack_hard为-1(Hard Limit).

?建议检查/etc/security/limits里，是否误添加了“stack_hard=-1”的设置，如果存在，删除即可，后续用户重新登录时即可生效。

?特别说明：

?如果是32位程序，按地址分布规则，最多只能有一个stack segment，因此不存在上述问题。

?Oracle11gR2 sqlplus会先把stacksize limit改小成32MB，然后再改回环境实际的ulimit-s值。这个行为应当与Oracle bug 12547243的修复方法有关。

更多IPS专家秘籍，请关注“浪潮商用机器”微信公众号