人力资源-NC常见环境问题(第5版).docx

NC常见环境问题（第5版）
NC技术支持部 2009-06
WAS+部署常见问题：
1：安装WAS时需要注意事项
安装WAS时，WAS的windows环境默认安装路径“c:\program files\IBM\Websphere”，这个默认安装路径是不被NC应用所支持，NC应用要求安装简单，不要有空格，不要有下划线，不要有连接线等特殊路径。所以WAS不能安装到默认路径下。通常情况下下列特殊符号包括“`”“~”“!”“@”“#”“$”“%”“^”“&”“*”“(”“)”“-”“_”“+”“=”“{”“}”“[”“]”“\”“|”“;”“:”“””“’”“,”“.”“/”“?”“中文”不能命名成安装路径。
安装WAS的另一个要求是网络设置。通常情况下要保证网络链接。如果服务器上有2块或更多网卡，这些网卡如果被启用了，要保证正确分配了IP地址，有正常的网络连线链接。如果某块网卡没有物理连线或正常IP地址设置。就要将该网卡设置为禁用状态。
设置合理的IP地址，一般部署NC应用的服务器需要设置成固定IP地址，固定IP地址有利于以后的管理和访问。同时正确维护hosts文件。Unix/Linux环境下，维护hosts文件由为重要。正确维护hosts文件才能保证WAS的正常启动与访问。
主机名称要简单简介。通常情况下不要特殊符号命名主机名称。特殊符号包括“`”“~”“!”“@”“#”“$”“%”“^”“&”“*”“(”“)”“-”“_”“+”“=”“{”“}”“[”“]”“\”“|”“;”“:”“””“’”“,”“.”“/”“?”“中文”。
安装好WAS建立了profile了，又进行了主机名变更，会出现WAS无法正常启动问题，这个profiles已经坏掉了。用户需要重新建立一个profiles来使用。这一点在今后的维护中需要注意。
2：NC502部署时出现IBMUTC应用
Was部署完，界面显示部署成功。但是在was的控制台中只能看到一个IBMUTC的应用，nc50的应用没有。该问题在windows及AIX下都出现过.  删除应用，重启was,多次部署之后就可以出现nc50的应用，或者不用删除IBMUTC应用,接着直接部署一次或多次,也可以部署成功,此时IBMUTC的应用也同时部署上去了,将IBMUTC删除。
该问题是WAS的BUG,需要多部署几次即可
3：Windows Server2008上安装WAS后补丁打不上问题

某遇到的WAS问题是:针对客户的Windows Server2008 Enterprise SP1 64位和Intel Xeon 3.6GHz(正式环境)或Inter(R)Core(TM)2 DUO CPU T6570 @2.10GHz(测试环境),相应的补丁更新程序不匹配.使用集团提供的补丁更新程序"download.updii.61013.windows.amd64" 来安装,提示“ 操作系统未通过必备软件检查”，如果不管操作系统的检查结果，点下一步强行安装，安装完后，更新程序的启动程序“update.bat"找不到，更新不了WAS补丁。
解决方法：

方法:1.从其它机器上拷贝一个update.bat,然后运行打补丁.2.用32位的补丁安装工具download.updii.61013.windows.ia32.zip安装后再打补丁,该工具仅仅是个补丁安装工具,打补丁时使用WAS64的补丁即可.
4：APACHE访问出错问题
问题现象：
HTTPSERVER+WAS水平集群
登录http://127.0.0.1时报错：
The server has encountered an error. Please refer to the event log for more detail information. Please contact the server administrator …………

问题分析:

\Plugins\logs\websrv1\http_plugin.log: 中看的下面的错误:
[Fri May 22 12:06:03 2009] 00001738 00001020 - ERROR: ws_common: websphereExecute: Failed to create the stream
[Fri May 22 12:06:03 2009] 00001738 00001020 - ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to 'jxzbwas02Node01_server1'on host 'jxzbwas02'; will try another one
[Fri May 22 12:06:03 2009] 00001738 00001020 - ERROR: ws_common: websphereWriteRequestReadResponse: Failed to find an app server to handle this request
[Fri May 22 12:06:03 2009] 00001738 00001020 - ERROR: ESI: getResponse: failed to get response: rc = 2
……………………………
上面的jxzbwas02Node01_server1是因为下图中”应用程序服务期 server1”,
没有删除造成。在\Plugins\config\websrv1\plugin-cfg.xml也有生成的
jxzbwas02Node01_server1的信息。 但是在NC的prop.xml文件中没有该服务
server1的信息. 所以plugin-cfg.xml中含有的应用服务和prop.xml中的不一致，造成访问APACHE出现上面的问题.

问题解决方法：

将上图中的两个server1删除。 在WAS管理控制台重新生成插件和传播插件.
然后重现启动APACHE后正常。
另外，在下图中的应用程序DefaultAplication,PlantsByWebSphere和SamplesGallery也要删除掉。否则也会造成访问不了NC问题.

5：HTTPServer 的80端口访问慢问题
第一种方法：WAS集群，访问http://IP:80端口时，访问非常慢。但是访问其它端口则正常。通过观察发现D:\IBM\HTTPServer\logs\ access.log文件达到1到2G左右，于是将apache.exe停止，删除掉access.log文件，再重新启动，访问80端口即可。
第二种方法：
该方法是网上找的，没有测试。
下面是关闭apache的 error.log,access.log日志方法：
找到文件D:\IBM\HTTPServer\conf\httpd.conf
vi http.conf
ErrorLog logs/error.log
#
# LogLevel: Control the number of messages logged to the error.log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn
#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog logs/access.log common
在前面加“#”号应该就可以了。
解决Apache日志文档ACCESS.LOG日益膨胀的一个办法：
将httpd.conf中CustomLog logs/access.log common 改成
CustomLog "|c:/apache/bin/rotatelogs c:/apache/logs/%Y_%m_%d.access.log 86400 480" common
重启Apache
6:Was启动时乱码且关闭不了问题
WAS中间件在AIX下,
用Xmanager登录后, 设置export LANG=Zh_CN.GB18030或 export LANG=Zh_CN的情况下启动./satartServer.sh server1后,进入NC系统发现增加凭证等许多节点都乱码,且用./stopServer.sh server1则不能停止中间件
估计是使用的Xmanger中没有合适的字符集造成的.
然后用telnet登录后, 启动和关闭was, 一切正常

7:32位操作系统之广西某项目WAS宕机问题

一、 问题总述：
某项目信息中心对was中的java虚拟机大小进行了调整，据称原来只有768M，调整为了1280M。可是was死机的情况愈加频繁，问题更加严重。

二、 问题分析：
这个问题比较复杂，后台会出现两类的内存溢出现象。这类问题在其他大量项目也出现过类似问题。不过某项目集团正好把两个问题均碰到了。

第一种现象内存溢出：
我所拿到的javacore中没有该类报错，不过第一次技术顾问到现场可能看到的是这种现象。
在javacore文件最上面会出现内存溢出的信息如下图

在后面的内存信息部分，free内存已经没有了，说明内存资源已经不足，导致was宕机。

第二种现象线程无法创建：
这个现象是我4月拿到的was宕机的javacore，这类问题是线程无法创建问题。
在javacore文件最上面会出现内存溢出的信息如下图，但是除了outofmemory之外还附带了一个信息：failed to fork OS thread ,这个信息很重要,这个信息表明是操作系统无法创建线程。

再查看在后面的内存信息部分，free内存还有很多剩余，说明内存资源还没有被完全使用，说明不是内存不足导致宕机。

三、 技术说明：
第一种情况：
Java设置的虚拟机最大内存（-Xmx 768m），在实际生产环境中根据数据量不同有可能导致java内存不足，最后导致宕机。所以需要把虚拟机内存参数设置比较大，最好到2G。

第二种情况：
线程无法创建，说明这个问题前我们要说明一下java在32位系统上的线程最大使用。
每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。

这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。

给出一个有关能够创建线程的最大个数的估算公式：

(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

对于jdk1.5而言，假设操作系统保留120M内存：
1.3GB JVM: (2GB-1.28Gb-120MB)/(1MB) = ~600 threads
768MB JVM: (2GB-768MB-120MB)/(1MB) = ~1120 threads

四、 结论以及解决建议：
结论：
当内存被从768m设置为1280m后导致能创建的线程由1100个左右降低到只有600个左右了，这样导致线程无法创建的几率增加。
也就是上面说的两个宕机问题，在32位操作系统上是一对矛盾，设置太多的java虚拟机内存会导致操作系统线程无法创建，设置太低的内存会导致业务使用内存不足。

建议：
1. 最终解决办法：升级操作系统到64位，因为这个问题如果到64位操作系统上内存寻址空间扩大就不会出现该问题了。
2. 暂时解决办法：
l Java虚拟机最大内存暂时降低到1024m，释放一定的操作系统内存。
l 将jvm升级到11补丁来缓解频繁出现failed to fork thread错误。
l 操作系统 加/3G 参数，可以让用户进程最大内存扩充至3G，这时操作系统只能占用最多1G的虚存。那样应该可以让JVM创建更多的线程。
3. 用友现在已经发版了最新的5.5版本，该版本新加了一些系统监控功能，并且此版本解决了501版本中诸多bug，更稳定可靠，并且很多节点效率得到了比较大的产品优化。
8:WAS安装不了问题.
在京粮集团安装WAS集群时遇到WAS服务不能启动。查看日志提示与IP有关。用户为了冗余每台机器配置了两块网卡、两个IP地址。
后来我将两台机器的网卡分别禁用一块，重装WAS后一切正常。
9:如果主机名被更改,was的运行与访问可能会出现问题.
现象:访问应用时可能会出现无法访问的情况.
分析:was是主机名相关的
解决办法: 重建WAS Profiles或重装WAS 。
10:was集群模式下NC部署不成功问题:
现象:最新的NC5.01sp1无法部署成功
分析:NC标准的5.01可以部署在Was6.1patch03及其以下补丁版本,但不能部署在patch07版本上.而4月24号后最新的NC5.01sp1只能部署在patch07这个版本上.
解决办法:将was升级到patch07
11:NC成功部署到集群后通过浏览器访问出现的是ibm httpserver的页面.
现象:NC模块在was里面已经正常起来了,但访问页面依然是ibm http的页面.
分析:NC模块没有与webserver进行关联
解决办法: （1）：启动apache，在was管理界面中查看Webserver是否已经启动，如图：
（2）：点击nc50，进入nc50，点击模块下的管理模块
（3）：在管理模块下，如图，
A：在集群与服务器中，有两行，分别为集群与web服务器，全部选中（蓝色表选中）
B：在下面的模块中全部选中
C：点击集群与服务器右边的应用
D：点击最下方的确定按钮即可。
E：验证：最右边服务器列中是否已经将web服务器加了进去：

12:NC部署后访问页面是ibm httpserver页面.
表现: NC已经成功部署并且webserver也已经关联,插件也重新生成,但访问时依然是
ibm httpserver页面.webserver与关联都没有问题,但页面依然是ibmhttpserver页面.
分析:可能是ibm httpserver与插件关联部分出现问题. 进入httpd.conf配置文件下查看,发现其WebSpherePluginConfig "d:\IBM\H….”指向的路径为旧的plugin.xml路径
解决办法:进入httpd.conf配置文件修改WebSpherePluginConfig指向的路径,使其指向新的plugin.xml路径
13:WAS集群环境NC登陆页面很长时间才出来.
表现: 在WAS集群环境下,每次重启浏览器进入NC,NC的公司登陆页面都要很长时间才出来.
NC的第一个欢迎界面很快,但其后的登陆页面很慢.
分析:经过查看java控制台中信息,发现每次都重新下载很多*.jar的信息.即每次登陆时都要重新下载一次相关代码(大约十几兆)
解决办法:需要清除掉对应nchome/bin下的两个以.cache结尾的文件(dist.cache,version.cache);再重启was.
14:WAS日志中出现内存溢出
表现:was进程down掉,日志中有内存溢出信息.
分析:可能是分配给was进程的内存不够;也可能是对应程序存在内存溢出或申请大量内存.
解决办法:对于第一种情况,在was中修改对应java进程参数:

对于第二种情况,需要对应环境重现,相关开发人员跟踪定位.
15:有关功能异常, 日志中出现无法从jndi找到相关模块或资源.
表现:相关功能无法正常使用,日志中报找不到相关资源或模块信息.
分析:一是的确缺少相关资源,如缺少了相关类;二是相关功能点用到的ejb没有被正常打包并部署到was上.
解决办法:
对于第一种情况,查看对应路径下相关资源是否存在,没有的话将相关资源补充;对于第二种情况,选中模块,重新生成ejb并部署.
16:集群模式部署时部分应用服务器，ear包中的jar没有拷贝全
表现：登陆页面有时候出错有时候没有问题。
分析：发现有一个服务端口无法访问，后台报错，发现installedApps中的nc50.ear中的jar程序不全。
解决办法：手动拷贝过来后重起后就可以使用了。
17:集群模式部署后进行集群映射到其他服务器过程中无法映射成功：
表现：在做应用和nc的映射（企业应用程序ànc50à选择所有服务器进行映射映射
）时，如果直接映射时有bug，不会出现保存按钮。
正确操作：
1.先选择企业应用程序，选择nc50应用，虚拟主机，选择
NC WEB default_host
hrss.war default_host
portal.war default_host
确定后先别保存
2.选择管理模块，做mapping操作。确定后保存。这样是完整的mapping操作。nc应用和hr应用和portal应用都会正确映射。
18:AIX主机添加内存后，应用服务器再无法正常启动:
现象：AIX主机添加内存后，应用服务器再无法正常启动
分析：
a)检查native_stderr.log,发现错误信息:
JVMSHRC030E The Shared Class Cache you are attaching has invalid header.
JVMSHRC031E The Shared Class Cache you are attaching has incompatible JVM version.
JVMSHRC025E error attaching shared memory
JVMSHRC017E Error code: -308
解释：无法使用共享内存，
b)增加内存后，系统内存地址发生变化。如果重启客户使用的是WAS6.1, JDK是J2RE 1.5.0 20061001, 各个JVM在启动时,会使用shared classes,以加快启动速度.而此系统中,第二个启动的server在试图使用第一个server的Cached class时,出现了不一致的情况.从而造成第二个server不能启动.
解决方案：
修改所有的服务器server.xml中的内容,增加JVM参数 –Xshareclasses:none,重启所有服务器即可。

或者登录到was管理控制台在界面中修改:
Deployment Manager > 进程定义 > Java 虚拟机
    单元 > caipxNode01 > nodeagent > 进程定义 > Java 虚拟机
应用程序服务器 > server1 > 进程定义 > Java 虚拟机
   JVM通用参数参数 末尾加上参数：-Xshareclasses:none
19:主机名中不能包含下划线等特殊字符:
现象：was报安装成功，但无法成功创建profiles
分析：主机名中包含特殊字符如nc_app1，导致创建profiles失败
解决办法：修改主机名为ncapp1，问题解决

20:将was安装盘从widows下上传到unix，无法正常安装:
现象：将unix安装盘在windows下读出通过ftp上传到unix下后安装，无法正常安装成功，报找不到jvm或其他文件等
分析：unix安装盘在windows下读出来时发现没有了大小写区别，而unix是大小写敏感，导致安装失败。
解决办法：（1）：将安装盘unix光驱下读出即可
（2）：或将正常的安装tar包而不是光驱目录文件从windows上传。
21:NC501标准版无法部署到was6107上:
表现：was打上6107补丁后，NC501版本（07年2月份发版的）无法部署成功，报：
[07-6-26 19:06:14:359 CST] 0000005e DeployEJBTask I ADMA0158I: [EJBDeploy] java.lang.RuntimeException: 属性未找到：IComponentCreationDataModelProperties.PROJECT_NAME
分析：NC新版的501sp1版本在部署这块基于was6107补丁做了修改。因此，原来nc501只能部署在was6103及以下版本中，不能部署在was6107补丁版本上。反之，nc501sp1可以部署在was6107上而不能部署在was6103及其低版本下。
解决办法：对应好nc与was的版本。
22:NC＋WAS集群时主机名导致的问题:
表现：
出现问题时，Websphere一切正常，对应的NC server正常；直接访问对应的server端口如9080，NC欢迎界面能出来，访问IUFO应用，正常；访问NC应用，系统一直白屏，登陆界面出不来，NC集群中所有server情况都与之类似。

分析：
在NC系统出现问题时，系统后台日志中，报如下信息：
probeid = 89
Stack Dump = nc.bs.framework.exception.FrameworkIOException: Remote request error
at n.cli.JavaURLCommunicator.request(JavaURLCommunicator.java:71)
at n.cli.ClientProxyImpl.a(ClientProxyImpl.java:166)
at n.cli.ClientProxyImpl.invoke(ClientProxyImpl.java:123)
at $Proxy2.getConfigParser(Unknown Source)
at nc.vo.sm.login.LoginRequestInfo.getLoginUIType(LoginRequestInfo.java:166)
at com.ibm._jsp._login._jspService(_login.java:181)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:85)
Caused by: java.io.IOException: Server returned HTTP response code: 408 for URL: http://NCAPP1:9080/ServiceDispatcherServlet
at .www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1179)
at n.cli.JavaURLCommunicator.request(JavaURLCommunicator.java:62)
... 6 more
即java程序通过主机名＋端口访问web服务资源时出现问题，导致无法正常获取登陆信息。即在国美当前环境下，后台系统jvm通过DNS系统解析主机名时会出现问题，导致登陆失败。

解决办法：
在NC配置文件中nchome/ierp/bin/prop.xml中修改主机名为ip访问，避免系统通过DNS访问NC系统。
23:Was中间件NC正常启动部署，无法登陆问题
表现:
重新安装was后，概要文件重新建立，各集群的节点也重新建立且和原来的不是同一个名称。
这样一来，部署完成后启动NC后，出现如下错误界面

分析:
经过检查发现，主服务器中的 servicerun.xml 文件没有对应修改为新建立集群节点后的节点名，导致NC系统服务没有启动成功。所以登陆不成功。
解决办法:
纠错：servicerun.xml 将此文件修改为 和现有节点对应的。比如：
<?xml version="1.0" encoding='gb2312'?>
<root>
<enableBgThread>true</enableBgThread>
<runAt>
<server>ncMem01</server>
<service>fip</service>
<service>DBTrans</service>
<service>IPreAlertConfigService</service>
</runAt>
</root>

另外：节点名称不一建议使用master 节点，避免给master 节点增加过多的压力。
24:Xmanager工具登录启动和关闭WAS问题
表现:
WAS中间件在AIX下的问题: AIX安装了Zh_CN.GB18030字符集. 在没有设置参数export LANG=Zh_CN.GB18030的情况下启动satartServer.sh server1后,进入NC系统发现增加凭证等许多节点都乱码;如果在export LANG=Zh_CN.GB18030的环境下启动satartServer.sh server1则看到的启动信息是乱码,启动成功后进入NC系统各节点乱码不再出现,各功能节点显示正常,但是在停止中间件服务时,用stopServer.sh server1则不能停止中间件,系统则出现速度明显下降.

分析:

用户使用的Xmanager登录AIX进行启动和关闭was. 由于用户的Xmanager中没有和AIX字符集相匹配的字符集. 导致出现乱码. 特别是关闭时,停止的速度非常慢.用telnet登录后,设置export LANG=Zh_CN.GB18030或Zh_CN启动和关闭was正常. 启动后,访问NC也正常.
解决办法:

可以用telnet等登录启动和关闭was. 或 Xmanger安装上合适的字符集合.
25:卸载安装不成功的WAS

WAS在AIX或LINUX下的安装不成功的卸载方法
WAS安装不成功或安装目录被误删除.
此时,常规的卸载方法是卸载不掉的
如果继续安装新的WAS,必须更改安装目录.

卸载方法如下：
删除掉WAS在系统的注册文件,同时将WAS的安装目录删除掉。
然后重新安装即可.
建议删除前,先备份一份.

AIX下注册位置为:
/usr/.ibm/.nif/.nifregistry

Redhat下为: (.ibm为隐藏文件,需要用ls -la 看到)
/opt/.ibm/.nif/.nifregistry
26:ehr的部署问题

在ehr安装时,薪资模块和福利模块要同时安装,如果只安装其中一个模块,
在生成和部署时,会报错部署失败.
27:LINUX/UNIX下部署时内存溢出问题
NC中间件在REDHAT LINUX AS 5 下的环境问题1.

问题描述：
应用环境为redhat linus as 5 32位,4G内存，jdk版本为1.5.0_17 for linux，
使用NC中间件安装正常，NC502全模块（含生产制造+工程数据）
当进行nc中间件配置工具（ncSysConfig.sh）进行生成ejb操作时，不能正常生成ejb，内存溢出。

报错信息为：
va] jar_task:
[java] [jar] Building jar: /nchome/dist/modules/uapweb/META-INF/lib/nc.impl.webbase.WebbaseEJB_PROXY.jar
[java] [iterate-call] The following error occurred while executing this line:
[java] [iterate-call] /nchome/bin/buildnc.xml:4: Could not create type property due to java.lang.OutOfMemoryError: PermGen space
[java] copy_descriptor:
[java] [copy] Copying 58 files to /nchome/dist/ejbXMLs
[java] deploy:
[java] java.lang.OutOfMemoryError: PermGen space
[java] Exception in thread "Thread-1" java.lang.OutOfMemoryError: PermGen space
[java] Exception occurred during event dispatching:
[java] java.lang.OutOfMemoryError: PermGen space
[java] Exception occurred during event dispatching:
[java] java.lang.OutOfMemoryError: PermGen space
[java] Exception occurred during event dispatching:
[java] java.lang.OutOfMemoryError: PermGen space
[java] Exception occurred during event dispatching:
[java] java.lang.OutOfMemoryError: PermGen space
使用ncdeploy的时候抱错如下：
[java] [main] 2000/03/12 07:17:04 [anonymous] DEBUG - componentName: nc.itf.hr.pub.HRPubEJB Property[26]: iFunctable : nc.itf.hr.wa.IFunctable
[java] itf[0]:nc.itf.hr.wa.IFuncreg
[java] itfs size :1
[java] [main] 2000/03/12 07:17:04 [anonymous] DEBUG - componentName: nc.itf.hr.pub.HRPubEJB Property[27]: iFuncreg : nc.itf.hr.wa.IFuncreg
[java] itf[0]:nc.itf.hr.tools.IDbTool
[java] itfs size :1
[java] [main] 2000/03/12 07:17:05 [anonymous] DEBUG - componentName: nc.itf.hr.pub.HRPubEJB Property[28]: iDbTool : nc.itf.hr.tools.IDbTool
[java] itf[0]:nc.itf.hr.tools.IExcelDisplayBuilder
[java] itfs size :1
[java] [main] 2000/03/12 07:17:05 [anonymous] DEBUG - componentName: nc.itf.hr.pub.HRPubEJB Property[29]: iExcelDisplayBuilder : nc.itf.hr.tools.IExcelDisplayBuilder
[java] Generating EJB proxy moduleERROR:nc.itf.hr.pub.HRPubEJB
[java] java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: PermGen space
PermGen space

解决过程：
经修改buildnc.xml下的memoryMaximumSize项，加到2G后依然提示内存溢出，当时的内存剩余为2.9G左右，依然无法解决。
将环境变量参数export ANT_OPTS="-Xmx512m -XX:MaxPermSize=512m"，生成EJB正常，问题解决。

AIX环境出现的问题：

环境描述：
在AIX操作系统下，进行nc自己中间件的ejb的生成，生成过程中，报错部署失败。在服务器nc的sysconfig.log上报错信息:[java] java.lang.OutOfMemoryError: PermGen space。 分析：
Jd