tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: heap size problems (speed) [2]
Date Mon, 28 Nov 2005 21:27:33 GMT
--- Cristian <cs@nightwish.eu.org> wrote:
> > I don't think your CPU L caches are going to
> influence
> > the issues you are seeing...not noticeably..not
> with
> > todays hardware.  Cristian is resizing the java
> heap
> > to allow it to get larger than it was able before
> > (default or the Tomcat default setting).  In this
> case
> > heap being the amount of memory the java process
> is
> > going to be able to use for the process aside from
> the
> > static space which can not be controlled by the
> heap
> > setting being used.
> >
> > How much memory does your computer physically have
> > Cristian?  Are you also using -Xms512m?  I'll wait
> to
> > here about your memory first before making other
> > comments on that.
> 
> 
> 1G of RAM and I do not set -Xms512m
> swap space is hit ocasionaly but not all the time.
> 
> > The next thing I'm going to ask deals with another
> > issue we had on the list.  Do you also write to
> the
> > HashMap from your application?  Are you reading
> and
> > writing to this cache or your application loads
> this
> > cached data at start up and it is merely read from
> > that point on?  If you are writing to this data
> you
> > need to be sure to synchronize the HashMap because
> if
> > you don't you can get into some serious problems
> with
> > concurrency issues and HashMap resizing
> (synchronize
> > reads and writes).  If you load all of the data up
> > then only read from the application then
> synchronizing
> > the reads to the hash map won't matter (unless you
> > allow reading while the loading is occuring).
> 
> The application only caches data at startup and
> after that it performs
> only read operations regarding this cache.
> 
> > The next question would be: Even if only reading
> and
> > you are are currently synchronizing the calls to
> this
> > "cached" data are the operations long?  If the
> > operations to a synchronized resource are very
> long
> > then other threads (requests in this case) will be
> > delayed while trying to access the HashMap.
> 
> I'm told that the accesses are not "long ones" ...
> The designer of this
> test
> just  accesses the HashMap. If it exists, OK they
> return the value.
> If not they return the name of the requested key.
> 
> Please don't blame my lack of knowledge in this
> matter, this being only
> what they've told me.
> I am far away (hundreds of pages of java docs) from
> understanding the
> functionality.
> I'm only providing support on linux for tomcat
> (installation with APR
> etc).
> They wanted to test this scenario on linux because
> on windows they claim
> it worked.
> 
> However I can understand advises and put them into
> practice if needed.
> Also, as I said before, I am able to read some docs
> that would
> eventually get me to the point of solving and
> understanding the problem.
> 
> > Wade
> 
> Thanks,
> Cristian
> 

I don't know really.  I've not seen issues with
HashMap in a Linux vs. Windows scenario (might check
JRE/JDK bug reports).  Since your swap isn't being hit
all the time I wouldn't say it would be that.  I don't
know really where to direct you without knowing more,
because the general issues don't seem to be the cause.
 Does the application perform badly with only a few
hits to the site?  Does the application get under
heavy load then stop working?

Wade

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message