问题描述:在HPUX11.23(IA64)平台上,运行tuxedo应用程序,部分程序启动后,其余的程序启动均报告如下错误:
exec schdmgnt_svr -A -r -- -i ../config/schdmgnt.cfg -m schdmgnt :
/usr/lib/hpux32/dld.so: Mmap failed for the
library</prmdev/chnldev/lib/libschdmgnt_appD.sl> : Not enough space.
CMDTUX_CAT:819: INFO: Process id=6864 Assume started (pipe).
......
这个时候,即使是其他的程序也可能有问题,如:
%cvs
/usr/lib/hpux32/dld.so: Mmap failed for the
library</usr/lib/hpux32/libcrypto.so.0> : Not enough space.
Killed
以上的binary分别是用aCC和gcc编译。
[@more@]
解决方法:需要重新链接binary,如果是ld,加参数+as,mpas,如果是cc/aCC,加参数-Wl,+as,mpas,只需重新链接即可。注意:这些参数改变链接器的行为,有可能对程序的性能产生影响。
参考文字[转]:HP-UX上32位程序,由于指针用4个字节表示,因此虚拟寻址空间为4G。在缺省的方式下,HP-UX会把这4G分成4个段,每个1G。其中0x0 - 0x40000000为Text段,其中存放的为程序的可执行代码。从0x40000000到0x7FFFFFFF,为程序的数据段,所有进程私有的数据都将在此段中。所以如果malloc,则得到的地址一定为0x40000000到0x7FFFFFFF之间。其中系统栈从7FFFFFFF向0x4000000涨,而堆则反之。在第3个和第4个段中存放进程之间的共享数据。所有的32位程序将共同占用这2G的虚拟空间。例如进程C有100M的共享内存,虽然这100M和进程A,B毫无关系,此时,A,B也只能利用剩余的1.9G的空间来共享内存。这样的好处是在共享的两个段里面,如果两个共享内存的指针指向同一个虚拟地址,则其指向的物理地址也是相同的,因此在共享内存上无需把不同的虚拟地址映射到一个物理地址,所以在处理上稍稍快一些。因此该种方式叫做SHARE_MAGIC。
因此SHARE_MAGIC的方式下,Text 1G, Data 1G Share Address 2G。在这种方式下用户能使用到的内存只有1G,所以常常有人问为什么1G内存后就报memory fail,就是这个原因。而且在这种方式下由于share address虚拟存储和物理内存的对应关系,因此也不能mmap同样内存两次。
为了能使得用户能够使用更多的内存,HP-UX也提供了其他的内存方式,如:
EXEC-MAGIC,Text和Data两个段给Text和Data共用,Share Address 2G,这样内存可以用到差不多1.7G左右。
SHMEM-MAGIC,Text和Data合用一个段,Share Address占剩下的3G,因此私用内存只能用到700M左右
MPAS (IPF only),把4G内存完全给系统使用,不分类型和大小。这样任何部分都可以用到整个4G的内存,但是share memory的虚拟地址和物理内存的一一对应关系便没有了,因此可以mmap多次了,但是由于地址必须多做一次转换,性能上稍有降低。
以上各种方式都可以在编译时候使用aCC -Wl,+as,share_magic/exec_magic/mpas等获得相应的内存管理方式,也可以用chatr命令来修改可执行程序的内存管理方式。(参见chatr manual)
该贴由system转至本版2014-9-16 15:22:06