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

[Samuel H. <Sam...@Co...>]

500 is my maxconnections setting.
I will increase that though.

I know when I go to status it does not generally show more than 40-50.

The server is a dual Zeon 3ghz server with a perc controller (high speed
scsi).
It has plenty of horsepower for what we are doing.

If there is a wait on cache then it may be the kernel limitations.
I will have to look at that.

I will gather more info for you.
I am not running the GUI version of jmp because I do not have any GUI
set up on the server.

Sam


-----Original Message-----
From: rab...@li...
[mailto:rab...@li...] On Behalf Of
Robert Olofsson
Sent: Monday, April 19, 2004 4:28 PM
To: Samuel Hill
Cc: rab...@li...
Subject: Re: [Rabbit-proxy-users] Memory/Proxy problems


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



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Rabbit-proxy-users mailing list Rab...@li...
https://lists.sourceforge.net/lists/listinfo/rabbit-proxy-users