ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Ofbiz Demo TrunK Slow
Date Wed, 08 Dec 2010 08:28:32 GMT
This URL does not seem to be make much sense. How did you come to it?

Jacques

From: "BJ Freeman" <bjfree@free-man.net>
> seems I blew it up again doing:
> http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML
> 
> HTTP - Ofbiz Demo Trunk
> 
> This service has 1 comment associated with it This service is flapping 
> between states
> CRITICAL 2010-12-08 02:01:58 0d 0h 33m 3s 10/10 CRITICAL - Socket 
> timeout after 16 seconds
> 
> 
> 
> 
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> Jacques Le Roux sent the following on 12/7/2010 1:51 PM:
>> We  have already 2 memory dumps and the suspects so far are
>>
>> 1)
>> 110 542 instances of "org.apache.derby.impl.jdbc.EmbedConnection40",
>> loaded by "java.net.URLClassLoader @ 0x7f3681c111f0" occupy 415
>> 680 440 (79,89%) bytes. These instances are referenced from one instance
>> of "java.util.WeakHashMap$Entry[]", loaded by "<system
>> class loader>"
>> More at https://issues.apache.org/jira/browse/OFBIZ-4043
>>
>> 2)
>> 198 instances of "org.apache.tomcat.util.threads.ThreadWithAttributes",
>> loaded by "java.net.URLClassLoader @ 0x7fb4b8f59220" occupy
>> 286 111 256 (45,01%) bytes.
>>
>> Biggest instances:
>>
>> a.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4c47e7818
>> TP-Processor90 - 8 558 720 (1,35%) bytes.
>> b.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4c35bb570
>> TP-Processor70 - 8 197 640 (1,29%) bytes.
>> c.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4c9f1b320
>> TP-Processor122 - 8 195 856 (1,29%) bytes.
>> d.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4c0719340
>> TP-Processor27 - 7 108 272 (1,12%) bytes.
>> e.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4ca6fd200
>> TP-Processor129 - 6 912 832 (1,09%) bytes.
>> f.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4cbfe2f60
>> TP-Processor152 - 6 639 528 (1,04%) bytes.
>> g.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4c80a7b98
>> TP-Processor114 - 6 494 872 (1,02%) bytes.
>> h.. org.apache.tomcat.util.threads.ThreadWithAttributes @ 0x7fb4ca8bf9a8
>> TP-Processor133 - 6 478 984 (1,02%) bytes.
>>
>> For the later it seems we simply miss enough memory to handle the
>> requests (there are no threads taking a huge part, only 1,35% max)
>>
>> Most of the time one of the demo instances fails because there is not
>> enough swap space. But this symptom means something is going wrong
>> anyway. Because we have 2.5GB of memory and 1.5GB of swap space. The
>> instances use
>> branch9: -Xms128M -Xmx512M (default MaxPermSize is 64m for server)
>> trunk: -Xms128M -Xmx768M -XX:MaxPermSize=256m (I have also tried with
>> -XX:MaxPermSize=192m but it's the same)
>>
>> I suspect something from users (or bots) and the infra team suggested to
>> use mod_log_forensic. I have not looked at it yet
>>
>> Jacques
>>
>> From: "BJ Freeman" <bjfree@free-man.net>
>>> both my demos are working fine on Centos5
>>> one other thing I noticed is that when the one failed the other server
>>> was up but there was no fail over to the working server.
>>> Will look at the dumps and see if I can see anything and track on my
>>> demos.
>>>
>>>
>>> =========================
>>> BJ Freeman
>>> Strategic Power Office with Supplier Automation
>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat Y! messenger: bjfr33man
>>>
>>>
>>> Jacques Le Roux sent the following on 12/7/2010 1:59 AM:
>>>> I'm currently struggling to get both demo working smoothly. Though we
>>>> did not change the running configuration, since the last OS update we
>>>> had a lot of problems.
>>>> I have changed the running configuration by minoring the memory used but
>>>> there are still issues. I have already 2 heap dumps which show some
>>>> leaks suspects. But I have not enough time to look into details
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <bjfree@free-man.net>
>>>>> did a
>>>>> http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML
>>>>> and got
>>>>> Service Temporarily Unavailable
>>>>> checked
>>>>> http://monitoring.apache.org/status/
>>>>>
>>>>> HTTP - Ofbiz Demo Trunk
>>>>>
>>>>> WARNING 2010-12-06 21:08:58 0d 0h 6m 3s 6/10 HTTP WARNING: - HTTP/1.1
>>>>> 200 OK - 13.380 second response time
>>>>>
>>>>>
>>>>> =========================
>>>>> BJ Freeman
>>>>> Strategic Power Office with Supplier Automation
>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>> Systems Integrator-- Glad to Assist
>>>>>
>>>>> Chat Y! messenger: bjfr33man
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>


Mime
View raw message