on 06-21-2010 8:16 AM
hi experts,
I installed Enterprise portal 7.01 sp06, Oracle Database 10.2.0.4.0 and kernel 7.01 PatchLevel 75592.
now jlaunch is catching cpu almost 100%.
server is 2 core, 2.93Ghz and 8G mem.
I attach JVM parameter.
===========================================
-Xms2048M
-Xss2M
-XX:MaxNewSize=341M
-XX:NewSize=341M
-XX:MaxPermSize=512M
-XX:PermSize=512M
-XX:ReservedCodeCacheSize=64M
-XX:CodeCacheMinimumFreeSpace=2M
-XX:CompilerThreadStackSize=4096
-XX:SurvivorRatio=2
-XX:TargetSurvivorRatio=90
-XX:SoftRefLRUPolicyMSPerMB=1
-XX:+HandlePromotionFailure
-XX:+UseParNewGC
-XX:+DisableExplicitGC
-XX:+UseTLAB
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Dsun.io.useCanonCaches=false
-Djava.awt.headless=true
-Djco.jarm=1
-Dorg.omg.CORBA.ORBClass=com.sap.engine.system.ORBProxy
-Dorg.omg.CORBA.ORBSingletonClass=com.sap.engine.system.ORBSingletonProxy
-Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sap.engine.services.ts.jts.ots.PortableInterceptor.JTSInitializer
-Djavax.rmi.CORBA.PortableRemoteObjectClass=com.sap.engine.system.PortableRemoteObjectProxy
-Djava.security.policy=./java.policy
-XX:+PrintClassHistogram
-XX:+HeapDumpOnCtrlBreak
======================================================================
is it possible the problem relate with window update?
server is ready to updata now.
I dont nkow why happen
please any idea.
thanks and best regards
jun
Hi Jun,
I am sorry, I did not undertand your latest comments. You mean that you increase the server heap size to 3GB but the problem still persists? What is the jdk version you use? Iti s recommended to use 1.4.2_26 (see note 716604)
Regards,
Blanca
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi Raghu,
I don understand "facing internet"...
the problem is happened when I just start EP service.
commonly, when EP service running, jlaunch`s cpu usage is very low but still 100% in my case.
there was nothing to huge any load in EP server.
I will update window server 2003....
thanks and regards
jun
Yes, the last experiments showed that it is no problem to use 3GB heap.
Regards,
Blanca
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi all,
I did not test max heap 3G yet ...may be later..
I check pslist again
===================================================================
3804 15 206835309 Wait:Resource 1:00:59.843 4:41:51.265 11:48:38.093 <--EDC
2748 10 431 Wait:UserReq 0:00:00.000 0:00:00.000 11:48:38.093
4764 15 206956945 Ready 1:01:07.734 4:41:15.093 11:48:38.093
4468 10 27 Wait:UserReq 0:00:00.000 0:00:00.000 11:48:38.093
3536 10 27 Wait:UserReq 0:00:00.000 0:00:00.000 11:48:38.093
3972 9 852 Wait:UserReq 0:00:00.062 0:00:00.000 11:48:38.093
3376 11 1874 Wait:UserReq 0:00:00.031 0:00:00.078 11:48:38.093
7116 15 206538474 Running 1:01:11.750 4:43:08.500 11:48:38.093
5076 9 2573 Wait:UserReq 0:00:00.062 0:00:00.031 11:48:38.093
=====================================================================
mapping server 0 dump
=============================================================================
"SAPEngine_System_Thread[impl:5]_118" prio=10 tid=0x0000000010ab1530 nid=0xedc runnable [0x000000002168f000..0x000000002168fb80]
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:333)
at java.io.File.getCanonicalPath(File.java:513)
at com.adobe.util.Utilities.deleteRecursive(Utilities.java:168)
at com.adobe.service.Service.expandNativeZip(Service.java:674)
at com.adobe.service.Service.start(Service.java:388)
at com.sap.engine.core.service630.container.ServiceRunner.startApplicationServiceFrame(ServiceRunner.java:214)
at com.sap.engine.core.service630.container.ServiceRunner.run(ServiceRunner.java:144)
at com.sap.engine.frame.core.thread.Task.run(Task.java:64)
at com.sap.engine.core.thread.impl5.SingleThread.execute(SingleThread.java:83)
at com.sap.engine.core.thread.impl5.SingleThread.run(SingleThread.java:109)
==================================================================================
what is "Wait:Resource" in pslist ? It means memory allocation?
how can I do?
cpu is still 100%..
thanks and regards
jun
Hi Jun,
400 is a very high value, please lower it to 200. Have you restart the instance after that?
I see the server heap size is set to 2048M, if the problem persists after recommendation above I would increase the server heap size to 3GB, please, try it. After that you have to make an instance restart.
Regards,
Blanca
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jun,
Have you checked that there are enough application threads? Please, increase it:
Configtool->Cluster-data-> Global Server configuration->
ThreadManager/Application Thread Manager -> MaxThreadCount
I hope this helps you.
Regards,
Blanca
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
If your high CPU consumption is during startup (up to 20 minutes or more) and if If you use windows (you did not tell your OS), try to disable temporarlly the on access antivirus.
By experience we found out that the J2EE stack startup time is halved with the antivirus disabled.
Then check with your security team if it is acceptable to only keep periodic antivirus scans.
Regards,
Olivier
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jun,
I would also recommend you to be sure you are using an updated JDK. Fow Windows the recommended version is 1.4.2_26, so if you are not using this version install it, this can resolver the CPU issue you are having.
I hope this helps you.
Regards,
Blanca
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi
I dont update java yet
but I check Note 743207 - Analyzing High CPU usage by the J2EE Engine: Windows
pslist -d 2456
==============================================
jlaunch 2456:
Tid Pri Cswtch State User Time Kernel Time Elapsed Time
3552 8 17674 Wait:DelayExec 0:00:00.062 0:00:00.046 8:46:18.671
2948 8 3 Wait:Executive 0:00:00.000 0:00:00.000 8:46:18.609
2656 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 8:46:18.609
4104 8 31544 Wait:DelayExec 0:00:00.031 0:00:00.015 8:46:18.578
4108 9 2 Wait:Executive 0:00:00.000 0:00:00.000 8:46:18.578
4120 11 139 Wait:UserReq 0:00:00.078 0:00:00.015 8:46:18.468
4140 15 123658 Wait:UserReq 0:01:35.906 0:00:01.265 8:46:18.437 102C
4144 15 119257 Wait:UserReq 0:01:35.484 0:00:00.953 8:46:18.437 1030
4160 9 158481 Wait:UserReq 0:00:57.000 0:00:01.343 8:46:18.406
4164 15 141336 Wait:UserReq 0:00:40.187 0:00:00.093 8:46:18.406
4168 11 1382369 Wait:UserReq 0:03:53.390 0:00:06.937 8:46:18.406 1048 <-- 4168 hex value
======================================================================
4168 thread had most cpu time so I check server 0 thread dump.
I found thread 0x1048
======================================================
"Finalizer" daemon prio=9 tid=0x00000000007ea2e0 nid=0x1048 in Object.wait() [0x0000000006fbf000..0x0000000006fbfb80]
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000095c7fce0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
- locked <0x0000000095c7fce0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
=============================================================
so how can solve ??
thanks and best regards
jun
Try to read Note 743207 - Analyzing High CPU usage by the J2EE Engine: Windows.
Are you trying to reboot the server first ?
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
83 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.