NC常见环境问题(第5版)

NC常见环境问题（第5版）NC技术支持部2009-06WAS+部署常见问题：1：安装WAS时需要注意事项安装WAS时，WAS的windows环境默认安装路径“c:\programfiles\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：WindowsServer2008上安装WAS后补丁打不上问题某遇到的WAS问题是:针对客户的WindowsServer2008EnterpriseSP164位和IntelXeon3.6GHz(正式环境)或Inter(R)Core(TM)2DUOCPUT6570@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水平集群登录时报错：Theserverhasencounteredanerror.Pleaserefertotheeventlogformoredetailinformation.Pleasecontacttheserveradministrator…………问题分析:\Plugins\logs\websrv1\http_plugin.log:中看的下面的错误:[FriMay2212:06:032009]0000173800001020-ERROR:ws_common:websphereExecute:Failedtocreatethestream[FriMay2212:06:032009]0000173800001020-ERROR:ws_common:websphereHandleRequest:Failedtoexecutethetransactionto'jxzbwas02Node01_server1'onhost'jxzbwas02';willtryanotherone[FriMay2212:06:032009]0000173800001020-ERROR:ws_common:websphereWriteRequestReadResponse:Failedtofindanappservertohandlethisrequest[FriMay2212:06:032009]0000173800001020-ERROR:ESI:getResponse:failedtogetresponse: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集群，访问端口时，访问非常慢。但是访问其它端口则正常。通过观察发现D:\IBM\HTTPServer\logs\access.log文件达到1到2G左右，于是将apache.exe停止，删除掉access.log文件，再重新启动，访问80端口即可。第二种方法：该方法是网上找的，没有测试。下面是关闭apache的error.log,access.log日志方法：找到文件D:\IBM\HTTPServer\conf\httpd.confvihttp.confErrorLoglogs/error.log##LogLevel:Controlthenumberofmessagesloggedtotheerror.log.#Possiblevaluesinclude:debug,info,notice,warn,error,crit,#alert,emerg.#LogLevelwarn##Thefollowingdirectivesdefinesomeformatnicknamesforusewith#aCustomLogdirective(seebelow).#LogFormat%h%l%u%t\%r\%s%b\%{Referer}i\\%{User-Agent}i\combinedLogFormat%h%l%u%t\%r\%s%bcommonLogFormat%{Referer}i-%UrefererLogFormat%{User-agent}iagentCustomLoglogs/access.logcommon在前面加“#”号应该就可以了。解决Apache日志文档ACCESS.LOG日益膨胀的一个办法：将httpd.conf中CustomLoglogs/access.logcommon改成CustomLog|c:/apache/bin/rotatelogsc:/apache/logs/%Y_%m_%d.access.log86400480common重启Apache6:Was启动时乱码且关闭不了问题WAS中间件在AIX下,用Xmanager登录后,设置exportLANG=Zh_CN.GB18030或exportLANG=Zh_CN的情况下启动./satartServer.shserver1后,进入NC系统发现增加凭证等许多节点都乱码,且用./stopServer.shserver1则不能停止中间件估计是使用的Xmanger中没有合适的字符集造成的.然后用telnet登录后,启动和关闭was,一切正常7:32位操作系统之广西某项目WAS宕机问题一、问题总述：某项目信息中心对was中的java虚拟机大小进行了调整，据称原来只有768M，调整为了1280M。可是was死机的情况愈加频繁，问题更加严重。二、问题分析：这个问题比较复杂，后台会出现两类的内存溢出现象。这类问题在其他大量项目也出现过类似问题。不过某项目集团正好把两个问题均碰到了。第一种现象内存溢出：我所拿到的javacore中没有该类报错，不过第一次技术顾问到现场可能看到的是这种现象。在javacore文件最上面会出现内存溢出的信息如下图在后面的内存信息部分，free内存已经没有了，说明内存资源已经不足，导致was宕机。第二种现象线程无法创建：这个现象是我4月拿到的was宕机的javacore，这类问题是线程无法创建问题。在javacore文件最上面会出现内存溢出的信息如下图，但是除了outofmemory之外还附带了一个信息：failedtoforkOSthread,这个信息很重要,这个信息表明是操作系统无法创建线程。再查看在后面的内存信息部分，free内存还有很多剩余，说明内存资源还没有被完全使用，说明不是内存不足导致宕机。三、技术说明：第一种情况：Java设置的虚拟机最大内存（-Xmx768m），在实际生产环境中根据数据量不同有可能导致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)=Numberofthreads对于jdk1.5而言，假设操作系统保留120M内存：1.3GBJVM:(2GB-1.28Gb-120MB)/(1MB)=~600threads768MBJVM:(2GB-768MB-120MB)/(1MB)=~1120threads四、结论以及解决建议：结论：当内存被从768m设置为1280m后导致能创建的线程由1100个左右降低到只有600个左右了，这样导致线程无法创建的几率增加。也就是上面说的两个宕机问题，在32位操作系统上是一对矛盾，设置太多的java虚拟机内存会导致操作系统线程无法创建，设置太低的内存会导致业务使用内存不足。建议：1.最终解决办法：升级操作系统到64位，因为这个问题如果到64位操作系统上内存寻址空间