Re: [Rabbit-proxy-users] Memory/Proxy problems

[Robert O. <ro...@kh...>]

Samuel Hill wrote:

>I am still seeing a leak....
>  
>
>I think we can see about 1 MB a minute growth in ram usage.
>As it goes on and on response times from the proxy go way down.
>Eventually, when the RAM limit is reached, there will be 5-10 seconds
>response times for pages to be delivered.
>  
>
Ok, noted.

One question what is your "maxconnections" setting?
I guess that most users use IE/5 or IE/6 and last time I checked each IE 
will open 8
concurrent connections to each host. The default value is 500, and the
thread dumps I have seen does not go that high. If you have to few 
connections your
clients will have to wait until a connection has timed out.

Anyway looking at the jmp_dump there seems to be a lot of threads that
are waiting for the cache, so it may be that the cache is to slow or to 
heavily
synchronized.

So one thing that would be interesting to get is a monitor dump (hmm,
jmp does not write such files, yet). Can you open the monitor window and
check if many threads seems to be waiting on the cache?

>I get stuff like below but what do you really need?
>jmp/0.41 initializing: (nomethods,nomonitors,noobjects,nogui):...
>  
>
That looks like normal output. Since jmp is still in development (note 
the 0 at the
beginning of the version) it still outputs some debug information on the 
console.

The object dump that you did send me will be a good first start to look at.
Did you run GC before you generated that file?

 From the jmp-dump I see:
Total    80335    354882    5584184    1262985
char[]    13117    54480    2087760    206557
java.lang.String    13875    59323    333000    212557
rabbit.http.GeneralHeader$Header    9795    23007    156720    41357
rabbit.http.HTTPHeader    1100    2561    44000    4874

So the java heap seems to be ~5.5 MB, not very big.
And the biggest entry is char[] (as expected).

One thing that would be interesting is if you could genereate a string dump.
_NOTE_ this file may contain sensitive information so think twice before 
you
release it. If you dont want to release it, can you at least see if 
there are many
duplicates? (I would guess that that is not an issue, but your ouput 
seems a bit odd in
regarding the number of strings, but if you did not do a GC before you 
generated this
file that is normal).

Looking at the methods we can see that addCacheStream and addEntry are 
the top most
entries (except wait, but wait is meant to take time). So this would 
also seem to
give the cache as the bottle neck.

I will look more on this tomorrow, I am to tired now (after a hard 
karate training session).
 
/robo