ORACLE在HP-UX下的系列问题处理(40)

　　Oracle 7.3.3 setprivgrp/大文本页错误
　　
　　问题描述
　　
　　在 HP-UX 10.20上的dmesg输出或syslog中发现下面的信息：
　　Process pid num=1 does not have mem locking privileges
　　 ^ or a meaningful PID with PHKL_11902/3
　　 [PHKL_11959]
　　required for using large text pages in this version.
　　See setprivgrp command
　　
　　这是怎么回事?
　　
　　配置信息
　　
　　操作系统 - HP-UX
　　版本 -
　　硬件系统 - HP 9000
　　系列 -H70
　　
　　解决方法
　　
　　这个显示表示执行了一个要求使用大文本页的二进制文件（因为"chatr +pi L" 在二进制文件上运行），用ADB 可以关闭该信息：
　　 echo "allow_superpage_text?W 0" adb -w /stand/vmunix
　　
　　安装了PHKL_12945/6后，就无须再用这种方式关闭（要求重新启动，并且假如重建内核，必须重复执行）。
　　
　　假如不应使用该特性，那么最好用chatr(1)重新设置二进制文件，请求应用缺省的4k 页。假如应当使用该特性，则进程执行时所在的组应当被赋予MLOCK 权限，例如，假如这是一个Oracle进程，Oracle 用户所在的组为dba：
　　setprivgrp dba CHOWN MLOCK
　　为永久性实现这个目的，应当修改/etc/privgroup (位于/sbin/init.d/set_prvgrp: /usr/sbin/setprivgrp -f /etc/privgroup)（如有边要创建该文件，添加一行"dba CHOWN MLOCK"）。但假如使用了Advanced或Online JFS，则必须安装下面的VxFS补丁程序，以避免在装载可导致进程挂起、无法杀死的二进制文件过程中死锁。:
　　PHKL_12945 (s700) 或 PHKL_12946 (s800).
　　背景资料:
　　处理器需要将虚拟地址映射到物理页地址上，它们使用一个硬件TLB (翻译后援缓冲器)来缓冲最近使用的译文。假如译文不在TLB中，就会出现读取页目录和更新TLB的开销。PA-8000 处理器与较老的处理器相比，TLB故障的代价更大，但是它可以处理更大的页面尺寸，所以您需要的TLB登录项可能更少。
　　
　　HP-UX 10.20 内核不能要求装载具有大文本页的二进制文件，因此它必须在exec(2)过程中读一次，然后将其锁入RAM中。只有在进程具有MLOCK 权限的情况下，内核才能进行此项处理，而这个权限是在已经用setprivgrp 赋予当前组的情况下获得的。
　　
　　TLB故障的减少和文本页故障的消除应当能够提高系统性能，代价就是启动时间稍微有些长（启动过程中装载整个的二进制文件），损失可用于其它目的的RAM页（现在内存中驻留整个二进制文件，而不只是最近使用过的页面）。
　　.........following with all English text ....
　　Oracle 7.3.3 setprivgrp/large text pages errors
　　
　　Problem Description
　　
　　On HP-UX 10.20, I see the following message in the dmesg output or syslog:
　　
　　 Process pid num=1 does not have mem locking privileges
　　 ^ or a meaningful PID with PHKL_11902/3
　　 [PHKL_11959]
　　
　　 required for using large text pages in this version.
　　 See setprivgrp command
　　
　　What is happening?
　　
　　Configuration Info
　　
　　Operating System - HP-UX
　　Version -
　　Hardware System - HP 9000
　　Series -H70
　　
　　Solution
　　
　　This message means a binary was exec(2)uted which asked to use large text pages (because "chatr +pi L" was run on the binary file).
　　The message can be disabled with ADB:
　　 echo "allow_superpage_text?W 0" adb -w /stand/vmunix
　　
　　Disabling it this way (which requires a reboot and must be repeated if the kernel was rebuilt) is no longer necessary with PHKL_12945/6.
　　
　　If the feature should not be used,
using chatr(1) to reset the binary to request the default 4k pages is the preferred method. If the
　　feature should be used, the group the process is executing in should be granted the MLOCK privilege, e.g. if this is an Oracle
　　process and the group the Oracle user is in is dba:
　　setprivgrp dba CHOWN MLOCK
　　To do this permanently, /etc/privgroup (which is read in
　　/sbin/init.d/set_prvgrp: /usr/sbin/setprivgrp -f /etc/privgroup)
　　should be edited (create if necessary, add a line "dba CHOWN MLOCK").
　　However, if Advanced or Online JFS is used, the following VxFS patch
　　needs to be installed to prevent a deadlock during the load of the binary that would result in a hung, un-killable process:
　　PHKL_12945 (s700) or PHKL_12946 (s800).
　　Background:
　　Processors need to map virtual to physical page addresses. They use a
　　piece of hardware, the TLB (Transaction Lookaside Buffer) to cache recently used translations. If a translation is not in the TLB,
　　overhead to read the page Directory and update the TLB is incurred.
　　PA-8000 processors have a larger penalty for a TLB miss than older processors, but can handle larger page sizes, so that you may need
　　fewer TLB entries.
　　
　　The HP-UX 10.20 kernel cannot demand load a binary with large text pages, so it has to read it once during exec(2) and lock it into RAM.
　　The kernel will only do that if the process has the MLOCK privilege,which is granted if the current group has been given this privilege with setprivgrp.
　　
　　The redUCtion of TLB misses and elimination of text page faults should increase performance. The cost is a slightly larger startup time (during which the whole binary is loaded) and the loss of RAM pages available
　　for other purposes (the whole binary is now resident in memory, not just the recently used pages)