【文章內(nèi)容簡介】 moduleERROR: [java] : PermGen space: PermGen spacePermGen space 解決過程： ，加到2G后依然提示內(nèi)存溢出，依然無法解決。 將環(huán)境變量參數(shù)export ANT_OPTS=Xmx512m XX:MaxPermSize=512m，生成EJB正常，問題解決。AIX環(huán)境出現(xiàn)的問題： 環(huán)境描述： 在AIX操作系統(tǒng)下，進行nc自己中間件的ejb的生成，生成過程中，報錯部署失敗。:[java] : PermGen space。 分析： Jdk的permgen的參數(shù)沒有設置導致生成ejb的時候出錯。 解決辦法： 部署前設置環(huán)境變量 export ANT_OPTS=Xmx512m XX:MaxPermSize=512m后，部署成功。28:WAS每天都要重新啟動上十次問題表現(xiàn)：上海某項目：NC5011版本,接連幾天，WAS每天都要重啟上十次分析：（1）：從生成的javacore可以發(fā)現(xiàn)基本上都是如下原因引起的：Exception = Source = probeid = 290Stack Dump = at (Native Method)at .init(:114)at $(:60)（2）：javacore文件中還有類似如下信息：Free Java heap size: 154,578,232 bytes——內(nèi)存足夠Allocated Java heap size: 536,870,912 bytesCurrent Thread : WebContainer : 1111Number of classloaders in Java heap : 7,997Remended Xmxcl setting : 9,496 or greater 問題問題：經(jīng)過分析，發(fā)現(xiàn)并不是因為內(nèi)存不足了，即內(nèi)存足夠，但classloader不夠了，在IBM JVM9 SR5以下版本中，默認的classloader是8192，如果升級到SR5及以上版本，就沒有了這個限制。（以上錯誤中我已經(jīng)將classloader在參數(shù)中設置成了15000，還頂不住，即代碼中可能存在循環(huán)中反復加載類的問題）解決問題： 最后的解決辦法是，將JVM升級到FP11包，此時其版本是SR5了，然后此問題過掉。 （或者設置Xmxcl50000，也能緩解或過掉此問題）29:WAS宕機問題問題表現(xiàn)：廣東某項目：NC5011+was6107,原來是windows 32位系統(tǒng)，一個月出現(xiàn)12次“java/lang/OutOfMemoryError”:“Failed to fork OS thread”導致系統(tǒng)down機；自從4月建議改成64位windows操作系統(tǒng)后，一天系統(tǒng)經(jīng)常down掉23次,生成的javacore文件中都是如下錯誤信息： Cause of thread dump : Dump Event uncaught (00008000) Detail java/lang/OutOfMemoryError received Free Java heap size: 1,135,932,888 bytesAllocated Java heap size: 1,275,069,440 bytes ——實際上，freememory還有很多；而此時，操作系統(tǒng)任務管理器中可以看到此進程的內(nèi)存占用已經(jīng)到2G（最大設置Xmx1280m)，在這種情況下，對應java進程一直占用一個cpu到100%，NC系統(tǒng)已經(jīng)無法登陸分析：分析有可能是此版本java虛擬機與操作系統(tǒng)匹配間存在問題，如內(nèi)存泄漏或gc線程回收存在問題解決辦法：將java虛擬機升級到FP11包，目前已經(jīng)觀察了近1個月，系統(tǒng)已經(jīng)穩(wěn)定，此問題未再重現(xiàn)30:某項目IBM AIX系統(tǒng)+WAS的效率問題系統(tǒng)配置 硬件環(huán)境：IBM AIX服務器 軟件環(huán)境：NC5011， 數(shù)據(jù)庫：Oracle 10g RAC 應用服務器有2臺： WAS主服務器 〔dmgr,node,master,ncmem01,單獨iufo〕 WAS從服務器 (ncmem02,ncmem03) ERP NC與IUFO在服務器上表現(xiàn)為2個不同的JAVA進程。 問題現(xiàn)象 經(jīng)常磁盤%busy達到100%,PgspIn,PgspOut達到400，CPU的wait達到20%,內(nèi)存%p達到98%，Page space 被占用20%以上。問題分析 %p代表的是計算頁面占內(nèi)存的百分比。這個值的升高必然會引起虛擬內(nèi)存調(diào)用的。過多的使用虛擬內(nèi)存，會導致頁交換的頻繁發(fā)生。因為swap在磁盤上，必然會導致磁盤的繁忙。磁盤過于繁忙，會有很多進程等待處理，導致CPU的wait升高。處理方案 通過svmon Pt15 | perl e ‘while(){print if($.==2||$amp。amp。amp。!$s++)。$.=0 if(/^+$/)}’方法對使用內(nèi)存多的前１５個進程進行排序。發(fā)現(xiàn)前面幾個都是來自was。對ｗａｓ中各個進程內(nèi)存情況進行查看，發(fā)現(xiàn)nodeagent的jvm參數(shù)設置的不太合理，但我們先不進行調(diào)整。關閉所有ｗａｓ應用，包括IUFO，用rmss c方法對內(nèi)存進行測試，結(jié)果是不跑任何應用，內(nèi)存大約需要２Ｇ。 , 對各個JVM的內(nèi)存進行規(guī)劃。IUFO?。保?，nodeagent２５６Ｍ，master 728,ncMem01 1G，ｄｍｇｒ平時不啟動。將NC的日志輸出關閉，減少文件讀寫。對AIX的系統(tǒng)參數(shù)進行優(yōu)化，盡量減少計算型頁面交換。修改的參數(shù)如下： vmo p o lru_file_repage=0 默認１ vmo p o minperm%=5　　　默認２０ vmo p o maxclient%=90 　默認８０ vmo p o maxperm%=90 默認８０ 修改說明：當您將這個參數(shù)設置為 0 時，它將告訴 VMM，您希望它僅替換文件頁面，而不是計算頁面。如果您的 numperm 小于 minperm 或者大于 maxperm，這種情況會發(fā)生變化，這正是您希望將 maxperm 設置得較高而將 minperm 設置得較低的原因。測試結(jié)果以下是對內(nèi)存ｃｐｕ監(jiān)控１０分鐘的情況，時間上午１０：３０，系統(tǒng)正常。一上午測試的結(jié)果都差不多。(后經(jīng)電話確認，系統(tǒng)一周內(nèi)一直很穩(wěn)定。) vmstat 10 60System configuration: lcpu=8 mem=5342MBkthr memory page faults cpu r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 1256483 85151 0 0 0 0 0 0 15 3250 1406 0 0 99 0 0 0 1256488 85145 0 0 0 0 0 0 16 3230 1414 0 0 99 0 0 0 1256489 85144 0 0 0 0 0 0 9 3255 1415 0 1 99 0 1 0 1256576 85057 0 0 0 0 0 0 23 3526 1789 2 1 97 0 1 0 1256578 85055 0 0 0 0 0 0 12 3283 1481 0 0 99 0 1 0 1257583 84049 0 0 0 0 0 0 44 3556 1494 1 1 99 0 0 0 1260945 80685 0 0 0 0 0 0 37 3466 1472 1 1 99 0 1 0 1260949 80681 0 0 0 0 0 0 29 3249 1423 0 0 99 0 0 0 1260954 80675 0 0 0 0 0 0 31 3219 1414 0 1 99 0 ……. 0 0 1261029 80553 0 0 0 0 0 0 6 3216 1390 0 0 99 031:Windows+WAS 語言集選項亂碼問題現(xiàn)象： 解決辦法： 1：打開was控制臺 2：不管是不是集群，可以先修改某個server的通用JVM參數(shù)選項， =server1 =GBK =GBK =GBK 3：重新啟動此server 4：加上此server對應的端口進行訪問，并測試。32: SP1部署不成功環(huán)境: windows 2003++現(xiàn)象：打代碼補丁后，部署ejb不成功，后臺報錯 [java] Tue Apr 08 19:08:00 CST 2008 正在生成部署代碼 [java] Tue Apr 08 19:08:02 CST 2008 Deploying jar [java] Tue Apr 08 19:08:02 CST 2008 正在生成部署代碼 [java] Tue Apr 08 19:08:03 CST 2008 Deploying jar [java] Tue Apr 08 19:08:03 CST 2008 正在生成部署代碼 [java] Tue Apr 08 19:11:45 CST 2008 /: 由于項目的構(gòu)建路徑不完整，所以未構(gòu)建該項目。找不到 的類文件。修正構(gòu)建 路徑，然后嘗試構(gòu)建此項目 [java] Tue Apr 08 19:11:45 CST 2008 /: 由于項目的構(gòu)建路徑不完整，所以未構(gòu)建該項目。找不到 的類文件。修正構(gòu)建 路徑，然后嘗試構(gòu)建此項目[java] Tue Apr 08 19:18:06 CST 2008 Shutting down workbench. [java] Tue Apr 08 19:18:06 CST 2008 Execution Halted: Compilation Errors Reported [java] Tue Apr 08 19:18:06 CST 2008 2 Errors, 0 Warnings, 0 Informational Messages [java] Tue Apr 08 19:18:06 CST 2008 ADMA5007I: EJBDeploy 命令在 D:\IBM\profiles\Dmgr01\wstemp\wstemp\app_1192db5a5c5\dpl\ 上完成了 [java] Tue Apr 08 19:18:06 CST 2008 ADMA5008E: EJBDeploy 在 D:\IBM\profiles\Dmgr01\wstemp\wstemp\app_1192db5a5c5\dpl\ 上失敗了：: ADMA0063E: EJB 部署中 發(fā)生錯誤 [/: 由于項目的構(gòu)建路徑不完整，所以未構(gòu)建該項目。找不到 的類文件。修正構(gòu)建路徑，然后嘗試 構(gòu)建此項目, ejbModule/nc/itf/uap/rbac/(9): 無法解析類型 。從必需的 .class 文件間接引用了它] [java] Tue Apr 08 19:18:08 CST 2008 ADMA5011I: 清除應用程序 nc50 的 temp 目錄已完成。 [java] ADMA5014E: 應用程序 nc50 安裝失敗。 [java] Install application failed [java] Saving session ... [java] Please manually restart the server and then start the application.解決辦法：檢查modules\uap下面所有子目錄，如果有METAINF目錄，刪除此目錄。 打補丁時習慣把代碼壓縮備份在當前目錄，一般 在\classes 目錄下面不能有備份的壓縮文件，把備份移到代碼根目錄之外，讓客戶做好文檔管理， 再次部署成功下面是類似的一個部署錯誤的例子: 某項目生成成功,部署失敗,報錯誤信息如下/ufsoft/nchome/modules/uapqe/ has the same module name with module at: file:/D:/ufsoft/nchome/modules/backup/uapqe1225bak/ [Thread9] 2008/01/15 09:09:12 [] ERROR file:/D:/ufsoft/nchome/modules