EWA Alert A- high ratio of full garbage

Hi All,
I have been receiving "RED" EWA report for pure JAVA stack from past 3 weeks. Earlier also I had got it and then the heap memory size was 1024. I had increased to 3GB and then I started getting a "YELLO" EWA report alert. However, from past 3 weeks I have been getting a red EWA report for full Garbage Collection problem.
I had gone throug some of the threads here and found some usefule info like, Paul mentioned in below link:
[EWA Alert A- high ratio of garbage collection|EarlyWatch Alert A - high ratio of full garbage;
How have gone to th dev_server0 file and saw some of the garbage collections there. I am quite unable to get the details mentioned there like:
1.
Mon Dec 12 07:43:12 2011
796020.432: [GC 796020.432: [ParNew: 319604K->28169K(320128K),
0.0588451 secs] 2671315K->2382219K(3116672K), 0.0589239 secs]
2.
Thu Dec 08 10:40:24 2011
461123.817: [Full GC 461123.817: [Tenured
Thu Dec 08 10:40:25 2011
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor150]
[Unloading class sun.reflect.GeneratedMethodAccessor543]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor220]......
I think the first one is the small garbage collections and the latter one is the "Full GC" as the name itself says.---Correct me if I am wrong.
Can any one help me in understanding the above details?
What should I do to remove this from my EWA alert?
Regards,
Faisal

Hi,
I have gone through the server nodes , std_server<n>.out (I have 3 server nodes) and found that on today's date, there are Full GC written in the logs multiple times. But can any one help me in diagnosing this and reaching out to the cause of this problem?
Regards
Faisal

Similar Messages

  • Full Garbage Collection Problem

    Hi All,
    We are working on NetWeaver Application Server JAVA 7.0
    I am getting an error message in of the the EWA reports for JAVA system. The red alert says as below:
    The maximum ratio of full garbage collections to total garbage collections in the reported interval was higher than 90%.
    In order to solve the above problem, I increased Heap Memory for all JAVA Server nodes to 3072 (earlier it was 2048 for all the server nodes). However, still I am getting same error in EWA report.
    Can any one help me in further analysing and solving the above problem?
    Your help is appreciated.

    Here are links to some of the tools. I have worked with [IBM GC for IBM JVM|http://www.ibm.com/developerworks/java/library/j-ibmtools2/index.html]. You may have to try others that can read Sun JVM's GC log.
    http://www.tagtraum.com/gcviewer.html
    http://www.yourkit.com/overview/index.jsp
    https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPJMETER
    http://java.sun.com/performance/jvmstat/visualgc.html

  • Full garbage collection issue, not releasing/flagging memory

    I have the following problem running on a multi-cpu windows server with Java 1.4.2_05 using WebLogic 8.1:
    During a lifecyle of the web application (under load, but not to heavy) memory usage seems ok and garbage collection is called regularly. Suddenly, the used heap starts to rize very fast and after a while, even a full garbage collection cylce, does not release any memory anymore.
    I am sure that, from our coding, we release memory ok, and normally we should only use about 5 to 10 mb for each user max (with0 normal defnew garbage collections).
    I tried changing the garbage collection parameters, but this does not solve the problem. Best scenario was with the concurrent collector and I got this output at +/- the end:
    [GC 100202K->93511K(115628K), 0.0091472 secs]
    [GC 148480K->139612K(163808K), 0.0225914 secs]
    [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor289]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor290]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor273]
    153750K->133006K(164064K), 1.2434402 secs]
    [GC 148939K->137948K(203264K), 0.0223085 secs]
    [GC 188789K->177116K(203264K), 0.0180729 secs]
    [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor312]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor322]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor309]
    189788K->170264K(203264K), 1.1851945 secs]
    [Full GC 203228K->203227K(203264K), 1.2876122 secs]
    [Full GC 203263K->203233K(203264K), 1.3354548 secs]
    [Full GC 203263K->203258K(203264K), 1.2873518 secs]
    <Jan 17, 2007 9:40:40 AM EST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=33114655,name=console,context-path=/console)] Root cause of ServletException.
    java.lang.OutOfMemoryError
    >
    [Full GC 203263K->203233K(203264K), 1.2814516 secs]
    [Full GC 203233K->203231K(203264K), 1.6029044 secs]
    [Full GC 203263K->203242K(203264K), 1.3081352 secs]
    <Jan 17, 2007 9:41:51 AM EST> <Emergency> <WebLogicServer> <BEA-000210> <The WebLogic Server is no longer listening for connections.>
    [Full GC 203263K->203247K(203264K), 1.3161194 secs]
    [Full GC 203263K->203249K(203264K), 1.2954988 secs]
    [Full GC 203263K->203247K(203264K), 1.6423404 secs]
    <Jan 17, 2007 9:41:57 AM EST> <Alert> <WebLogicServer> <BEA-000218> <Server shutdown has been requested by <WLS Kernel>>
    [Full GC 203263K->203250K(203264K), 1.3161025 secs]
    Another strange item is: I maximized the amount of memory it uses to 512m with the Xmx parameter, I am almost sure that that one is used, but it never gets higher than 203M? Does anyone know why this is?
    Another strange item: the monitoring in the weblogic code indicates 32MB of usage (relative memory usage seems to be ok, but the quanity indication is just plain wrong) with 15 threads running.
    This problem does not exist when using JBoss 4.0.2 or 4.0.3 (standard j2ee settings).
    If anyone has an idea or can help me, I would appreciate it very very much. :)

    Hi ,
    Is this issue resolved ?
    we are facing same problem.
    1. We have checked the CPU and memory utilization everything is normal
    2. GC logs showing FULL GC calls continuously
    3. After restart the resin server system is working normally.
    Environment detail
    Resin ./resin-pro-3.0.18 on suse Linux
    Java JDK1.4.2_08
    Please suggest

  • Short dump while executing job SM:EXEC SERVICES for EWA alert generation

    Hello All,
    I'm getting short dump error while executing job SM:EXEC SERVICES for EWA alert generation.I'm using EHP1@SP22 of Sol Man.
    Please find the logs
    Error in the ABAP Application Program
    The current ABAP program "SAPLDSVAS_PROC" had to be terminated because it has
    come across a statement that unfortunately cannot be executed.
    The following syntax error occurred in program "RDSVASCABAP_TRANS__________073
    " in include "RDSVASIABAP_TRANS__________073 " in
    line 1782:
    "Field "STATEMENT_SUMMARY001019" is unknown. It is neither in one of th"
    "e specified tables nor defined by a "DATA" statement. "DATA" statement"
    The include has been created and last changed by:
    Created by: "SAP "
    Last changed by: "SAP "
    Error in the ABAP Application Program
    The current ABAP program "SAPLDSVAS_PROC" had to be terminated because it has
    come across a statement that unfortunately cannot be executed.
    If anyone came across such kind of dump, please reply asap, due to this, i could not generate EWA report for R/3 system 6.04.
    Thanks,
    Anand.

    >
    Anand Tigadikar wrote:
    > Thx Paul, but i already did checked this note and its not solving my issue
    Dear Anand,
    Did you perform a complete service definition replacement for SDCC/SDCCN as described in the note?
    These are manual steps you need to perform on the system and are not code corrections.
    I would suggest you perform it, if you have not, and check the SDCCN logs to review the process ran cleanly.
    Note: Please make sure SDCC_OSS is functioning and a connection to SAP can be made before
    deleting the service definitions.
    If you have already replaced the service defintions on the Solution Manager system, then no point doing it again. However checking a note and applying it are not the same thing. So I am uncertain if you replaced the service definitions or not. The dump you are getting in SM:EXEC SERVICES suggests its due to a problem with the service definitons. The recommendation is to replace them according to the process described in SAP Note 727998. If you have not done so please do so.
    If you have successfully replaced the service definitions are you still getting the same dump, or has it possibly changed?
    Regards,
    Paul

  • EWA alert report for java system shows wrong data

    Hi,
    In our solman system, EWA alert reports are configured every week for all the production systems (both ABAP and JAVA). Recently oracle database was upgraded from 10g to 11g in all the production systems. The EWA alert report for ABAP systems is correctly taking the 11g database details and is suggesting parameter changes. Unforunately the EWA alert report for Java systems is still pointing to 10g database and is suggesting the parameter changes for 10g only but the systems are on 11g.
    In SMSY, the database of the java systems is maintained as 11g only and not 10g. STill we are not sure where the data is being fetched from.
    Please help me in finding the issue.
    Regards,
    Ragav

    Hello,
    iNote 1482818 would be iapplicable if not java checks are being made. You are not reporting no java checks, you are reportijng the check is being performed, but has the wrong value. When you updated the database dis you perform Solman_setup, Mnaaged system setup?
    The reason I ask s that is what prepares the java side for EWA. For isntance if you had on old version of ST-SER such as 700_2008_2 then it does not know about Oracle 11.2....but that is on the ABAP side, you would need ST-SEr 701_2010_1 to
    recognize ORacle 11.2 on the ABAP side.
    So while I am not 100% sure in this specific instance, it seems logical that if the Java side isn't recognizing the Oracle Database version ( which means it is making this check) then you may need to run the Solman_setup, Mnaged system setup to pick up the ability to detect a new version of Oracel on the Java side.
    It is certainly worth the try.
    Regards,
    Paul

  • Can I force full garbage collection?

    Hi, my program is memory bound , as users load more files more memory is required , if the user decides to load a very large number of files they will eventually run out of memory. So I am trying to detect when there is less 15% of heap memory left, then force garbage collection and if it cant free up more than 15% of the heap I will stop the user from loading any more files. But the problem is though I call System.gc() to try and force a full garbage collect it rarely
    retrieve enough memory to get below the 15% limit. But using the Yourkit Profiler I can select the Force GarbageCollection option and this always manages to free up more memory to get the figure under the 15% limit. in support of this I found that sometimes my program stop me loading more files when there is still quite a bit available.
    So my questions are.
    1. I know System.gc() is only hint to garbage collect, but the docs imply it only replys after the garbage collection (if any) has been done, is this right or do I have to wait.
    2. Is there any way to Force complete Garbage Collectionas profiler appears to do.
    3. is there a VM option I could set instead to force the JVM to completely garbage collect at say 83% so that if I then polled that 85% of heap was being used I would know that it really was, and I wouldnt need to bother trying to garbage collect further. (Im using Suns 1.6. JVM on Windows and Linux, and Apples 1.5 or 1.6 JVM on Macs)
    public static void checkMemoryWhilstLoadingFiles() throws LowMemoryException
            MemoryUsage mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
            //No max defined future proofing
            if(mu.getMax()==-1)
                return;
            if (mu.getUsed() > (mu.getMax()  *  0.85f))
                MainWindow.logger.warning("Memory low:" + mu);
                System.gc();
                MainWindow.logger.warning("Memory low gc1:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
                System.gc();
                MainWindow.logger.warning("Memory low gc2:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
                System.gc();
                MainWindow.logger.warning("Memory low gc3:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
                mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
                if (mu.getUsed()  > (mu.getMax()  *  0.85f))
                    MainWindow.logger.severe("Memory too low:" + mu);
                    throw new LowMemoryException("Running out of memory:"+mu.getUsed());
                else
                     MainWindow.logger.warning("Memory usage reduced to:" + mu);   
        }thanks for any help Paul
    Edited by: paultaylor on 27-Jun-2008 11:10

    On all of the current Sun HotSpot JVM's, calling System.gc() will cause a full compacting collection. Unless you have -XX:+DisableExplicitGC on your command line, in which case the call is a noop. Or if you are running the mostly-concurrent collector (-XX:+UseConcMarkSweepGC) and have the -XX:+ExplicitGCInvokesConcurrent flag on your command line, in which case calling System.gc() will start a concurrent collection (and the calling thread will block until the cycle is finished).
    But calling System.gc() isn't enough to recover all the space that might be recovered. For example, System.gc() will identify objects that are unreferenced but need to have their finalize() methods called before their space becomes available again. So one call to System.gc() won't recover their space. Those finalize() methods need some cycles to run in, so back-to-back (or back-to-back-to-back :-) calls to System.gc() won't help. If you use a lot of finalize() methods, you should leave a lot of time for the finalize() methods to run between the calls to System.gc(). (Better would be to convert your code to use WeakReferences and run your own reference processing queues, and then you could tell when you were done processing references. But that's real work.) Some people try calling System.runFinalization() and wait for that to return, but that has at least two failure modes (details left to the reader).
    In addition, there are details like: if there is still 15% of the heap free, then we won't aggressively clear SoftReferences when you call System.gc(). We might if you waited until the heap was full and we collected it on our own, since we know how much free space there will be after a collection at the point where we are choosing which SoftReferences to clear, and use that to decide how aggressively to clear SoftReferences.
    There is no method to force the collector to do a compacting collection at, say 85% full. There is an option to have the mostly-concurrent collector start a collection cycle that way. But there's no way to find out if a collection cycle is running.
    You are skating on the edge of the qualities of service offered by the different collectors in the various JVM's available. That weakens your ability to "write once, run anywhere".

  • Doubt about difference between "Send to sap" and "Send EWA Alerts to SAP"

    Hello All
    I hope that you can help me is juts a doubt about 2 check boxes
    I'm on setup of a EWA but when i´m on the configuration (dates, transfers ewa to sap, archiving of EWA etc) i see 2 check boxes
    that i don't know what is the difference
    The path is the following
    Tcode = DSWP --> Select the solution --> (the left column) Operations Setup --> Solution Monitoring --> EarlyWatch Alert  --> Setup EarlyWatch Alert
    Could you tell me what is the difference between "Send to SAP" and "Send EWA alerts to SAP" boxes?
    Thanks and have a nice day

    Hello Cherios,
    The "Send to SAP" check box is used when you want to sent a Production or Test (Quality) systems EWA data to SAP for analysis.
    Currently the "Send EWA Alerts to SAP" is not used at this time, and actually cannot be selected, and saved.
    There should now be no doubt about the two check box fields .
    Hope this information is helpful.
    Regards,
    Paul

  • How to specify when Full Garbage Collections occur in the Old Generation

    Hi. We seem to be having a problem with a number of JVMs (1.5.0_17-b04) that run a component of a Document Management application. This component stores a large amount of information in caches which reside in the Old Generation. Although these cache sizes can be somewhat controlled by the application, they are currently taking about 85% of the Old Generation space. Fortunately, very few objects get tenured into the Old Generation - they all are cleaned up in the New Generation space.
    The problem we are seeing is that with the Old Generation at 85% full, there are constant full GC's occurring. Since the caches cannot be removed, the system frantically tries to remove objects that can't be removed.
    We have three solutions in mind. The first is to increase the memory allocation to the Old Generation so that the caches take a smaller percentage of the available memory allocation. The second would be to decrease the size of the caches; but this is set more by the number of documents in the application and cannot be made much smaller.
    The third solution is to configure the JVM so that Garbage Collections in the Old Generation do not occur until the memory is more than a specific percentage of memory in the Old Generation. We would then set this percentage to be higher than the amount of memory being used by the caches.
    So, is it possible to tell the JVM to only run a Full GC when the memory in the Old Generation is greater than a specific value (say 85% full)?
    Thanks for your help.
    Andre Fischer.

    afischer wrote:
    The third solution is to configure the JVM so that Garbage Collections in the Old Generation do not occur until the memory is more than a specific percentage of memory in the Old Generation. We would then set this percentage to be higher than the amount of memory being used by the caches.
    So, is it possible to tell the JVM to only run a Full GC when the memory in the Old Generation is greater than a specific value (say 85% full)?Switch to the CMS collector.
    -XX:+UseConcMarkSweepGC
    -XX:CMSInitiatingOccupancyFraction=86

  • High cpu usage for garbage collection (uptime vs total gc time)

    Hi Team,
    We have a very high cpu usage issue in the production.
    When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
    Environemnt details:
    Jrockit version:
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
    BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
    Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
    Number Of Processors: 4
    Max Heap Size: 1073741824
    Total Garbage Collection Time: 21:43:56.5
    Uptime: 114:33:4.1
    Total Garbage Collection Count: 420872
    Total Number Of Threads: 198
    Number Of Daemon Threads: 191
    Can you guys please tell me what would be problem in the server which causing the high cpu usage?
    One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
    Santhosh.
    [email protected]

    Hi,
    I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
    I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
    In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
    What I have found so far is that this corresponds to increased GC activity.
    Let me list my environment specs before I proceed, though:
    CPU: Dual Xeon 3.06GHz
    RAM: 2GB
    OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
    JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
    Tomcat version 5.5.12
    JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
    Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
    [Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
    [Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
    [Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
    [Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
    [Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
    [Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
    [Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
    [Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
    [Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
    [Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
    [Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
    [Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
    [Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
    [Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
    [Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
    [Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
    [Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
    [Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
    [Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
    [Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
    [Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
    [Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
    [Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
    [Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
    [Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
    [Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
    [Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
    [Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
    [Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
    [Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
    [Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
    [Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
    [Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
    [Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
    [Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
    [Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
    [Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
    [Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
    [Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
    [Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
    vvvvv
    [Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
    [Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
    [Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
    [Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
    So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
    Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
    It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
    I guess my only question is: What would cause such GC behavior?
    I would appreciate your ideas/comments!
    Thanks,
    Tenyo

  • Red EWA alert in SAP Solution Manager Functionality

    Hi Experts,
    We found a red alert in Service Plan and General Infrastructure in EWA under SAP Solution Manager Functionality for Solman system. The error is as follows.
    Service Data Download Center
    SDCCN settings are not maintained -
    Service Plan
    RFC connection errors to SAP backend system
    General Infrastructure
    Not all services in ICF required for Solution Documentation Assistant are active
    RFC connection errors to SAP backend system
    Number range check inconsistent
    RNOTIFUPDATE01 is currently not scheduled Hourly
    & settings are inconsistent
    Could anyone provide a solution to rectify these red alerts.
    Thanks & Regards,
    Sundara.

    SDCCN:
    Go to tx SDCCN - Goto - Settings - Task-specific
    Make sure all settings are correct.
    Service Plan:
    Check your RFC's to satellite systems in SMSY.
    General Infrastructure:
    Go to transaction SICF and activate all nescesarry services.
    Hope this helps!
    Regards,
    David

  • EWA Alert

    Dear Experts,
    I am trying to send an EWA locally from my ECC6.0 Quality system.
    I have already configured Satellite sytem and Service desk in my solution manager.
    Procedure I am following:
    In my Quality system I went to Tcode SDCCN. Then I have activated it via Utilities-->.activate
    Automatically two task has been created: Task name: Maintenance Package and Service Preperation check.
    Then I went to Task>Create>Request session data-->then I select periodic(Early Watch Alert)
    After the background jobs finishes again went to Task>Create>Refresh session.
    My question is:
    1. Is that the right steps I am following.
    a. Maintenance Package
    b. Request session data
    c. Refresh session
    2. What will be the Target RFC Destination for all the three task(if correct).
    I am confused about the Target RFC's for the three task.
    Please suggest something.
    Regards,

    Hello,
    http://help.sap.com/saphelp_sm32/helpdata/EN/3b/6dcca09dd24250a0873fef3122de5b/content.htm  should help you in this regard.
    I believe there is a tutorial on the market place for the generation.Please check service.sap.com/solutionmanager.
    If you want the data to be sent to the solman, use the solman rfc.( i think the solman back rfc.Plz check)
    thanks,
    Prasanna kulkarni
    Edited by: Prasanna K on Jun 30, 2009 3:09 PM
    Edited by: Prasanna K on Jun 30, 2009 3:13 PM

  • EWA Alert 'rating not defined' and 'download problem' (last week it's fine)

    Hi Friends,
    Please help me with this Alert.
    We have a weekly schedule of EWA report. Lat week the report was fine (green).
    This week it's been grayed out. the erro is Rating not defined and download problem.
    I have run the EWA report and it generated well.
    As per the EWA aler recomendation, i have run the sysprep check (sdcc) in target system. as per the report ihave checked the patches, they seems to be ok.However till last week the report was fine(Green).
    I have checked the RFC connections etc.
    Please check the following error message and help me soon. Since this is a production system.
    Regards
    srini

    hi srini,
    r there any upgrades of patches as now i am experiencing the same problem to my qty and dev servers where i have scheduled ewa reps.
    it says dwnld problem... but i assume the recent cvhanges to our servers patch levels has some thing to do with this..as that is the only changewe had perfromed...i would keep u informed once i check back to this issue.
    let me know if u find any,
    Br,
    Sri
    Award points for helpful answwers

  • EWA Alert configuration done but report is not generated

    I have setup the EWA congiguration for a Solman 7.0 , i executed rtcctool and implemented addons now everything is seen in green , also activated SDCCN and checked for all RFC ...everything is working fine .i saw two tasks service preparation check and maintenance check and executed them properly i also created a solution in DSWP and activated EWA for that solution . I followed the EWA tutor available at service marketplace properly but still when i create a early wath alert in opertaions in DSWP in solman , i see this waiting symbol and dont get any report in return , even after refreshing session am not gettin it here in DSWP. Please help me out and suggest some solution.
    I did this setup to get EWA report of Solman system in that system itself , i mean i want report of solman system in it , i am not using any satellite system here, is this possible to do so . Please guide me .

    Hiii
    David ......i refreshed the service definitions and i ran service preperation check and maintenace package , both were ok after that i went to DSWP in operations(inside early watch alert Tab)  and i created a new service named "SAP early watch Alert "  i selected my solman system while creating this service but service is in Waiting process in DSWP in operations , sign is not of blue bottle or Red flag but the wait Sign that we usually get and when i click on it it says "The session is waiting for data from a remote system. Data transfer can take up to one day."   it also gives steps to start it manually by going to SDCCN and creating task "Refresh Session"  i also followed that process using "None"  Rfc  but still in DSWP in opertaion  its in Wait and still same message inside it   "The session is waiting for data from a remote system. Data transfer can take up to one day."
    Please help me out in resolving it.

  • Disable EWA Alerts ins Technical Monitoring

    Hello,
    I would like to disable certain "Early Watch Alert" Alerts in the Technical Monitoring application of Solution Manager 7.1.
    E.g. in my setup we get the warning that EWA:Security-Alert: "Security-related SAP notes have not been applied"...
    Since this will be the case for most systems most of the time I don't want the warning to appear in the technical monitoring Dashboards.
    I figure, that these alerts propably have something to do with "EWA Integration into MAI" and also that a "Early Watch Alert Template" seems to exist.
    Unfortunately I'm not able to configue this template.
    Do any of you know where "EWA Integration into MAI" or the above mentioned template can be customized?
    Best Regards,
    Thorsten

    Hi,
    Other way, you can manually deactivate metrics from the Technical monitoring setup, template maintenance-> select the template -> uncheck the EWA metrics.
    Thanks
    Jansi

  • Reducing full Garbage Collection frequency.

    I've been trying to improve the performance while inserting a large number of records to an embedded H2 database. Monitoring memory useage suggests that it's being used rather innefficiently. A lot of the objects created by H2 seem to find their way into "tenured" space before being freed. Full mark-and-sweap garbage collections are occuring every couple of seconds, despite the fact that only about 10% of the available heap is occupied.
    Any advise on tuning the garbage collector to improve throughput in this case?

    I think if surviving objects max out the to-space (part of the young generation) the remaining objects are copied into the tenured generation.
    You can get more info via:
    -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGC -Xloggc:<filename>

Maybe you are looking for