-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
At the risk of repeating things said by others...
André Warnier wrote:
> We have an old clunker PC (Pentium II, 512 Mb Ram, average ATA disks),
> which we use to test some applications (not only Java/Tomcat).
Based upon this hardware configuration, things are going to suck no
matter what else you do. Just bear that in mind going forward.
> -Xmx256M
[snip]
> 6226 tomcat55 25 0 506m 191m 10m S 0.0 37.9 140:26.15 java
Interesting that the JVM grows to nearly twice the size of the maximum
heap that you gave to it. If it performs okay, then I wouldn't worry too
much about that, but I'm surprised that the total virtual size is so big
given your (relatively) small maximum heap.
> Now, if I stop and restart Tomcat, for something like 6 minutes after
> that, the same top display shows this kind of thing :
> (There are 4 consecutive snapshots here, taken at more or less regular
> intervals during the 6 minutes)
[snipped top output showing large memory use]
> In other words, while this application is being loaded, our Tomcat and
> the whole system are totally unresponsive for about 5 minutes.
When you say "the whole system", do you mean that you can't get other
services to respond? What about something simple like 'ls' on a
command-line? Is the whole machine thrashing or is it just that Tomcat
appears dead for 5 minutes or so?
I agree with your assessment that your application is at fault; neither
Java nor Tomcat are the problem, here.
> Now my questions are of the kind :
> Our production servers are ASP servers, where several customers would be
> using this same application, each customer with its own 25 Mb XML file
> of data. They are more powerful servers, but if I have 5 customers and
> these things compete with one another for memory or resources, I could
> have a server that is unresponsive for a hour maybe at start.
You are absolutely right to be considering the scalability of your
application, and I would be worried, too. The good news is that web
applications spend most of their time running and very little of it
initializing themselves. ;)
> So basically, I am asking if there are any parameters I can vary for the
> application startup or Tomcat in general, to evaluate the behaviour
> under different circumstances
Nope. If the JVM and Tomcat startup quickly (15 seconds is just fine on
that hardware) then the only thing you could do to help your application
is to optimize the initialization.
Actually, before I say "never", you might want to check on two things:
1. DNS settings. Especially when parsing XML (which often requires
looking up a DTD or XML Schema file on a remote server), you might be
hitting a problem where your DNS resolver is taking a long time, but
finally succeeding (which is why you don't see any errors). This was
happening to us when our hosting provider took a DNS server out of
service without telling us: our lookups against our primary DNS server
were timing out (after tens of seconds), but the secondary server worked
right away. So, we had to wait for the primary to time out before
getting an instant response. The result was that most DNS lookups took
forever and it was a simple DNS configuration fix.
2. Cryptographic entropy. If your application ultimately uses
/dev/random for random numbers, you may be running out of entropy and
your application may be blocking during startup waiting for more. You
can modify your JVM configuration to use /dev/urandom which will not
block in these situations. Most recent JVMs are rigged to use
/dev/urandom on Linux and I don't suspect that this is your problem.
> [Should I] put more RAM in the server[?]
Always! ;)
> or if I should lower or raise the amount of memory available to
> Tomcat (and how), etc.
This is very application-specific. If you aren't running out of memory,
there's no reason to increase your heap size. If you set your heap too
large, you'll end up with lots of swapping which will kill your performance.
> I am also a bit surprised about the amounts I see in terms of memory
> usage, but not being an expert, I have not really anything to compare
> them with. It's just that these java applications seem very hungry in
> memory, if what is shown is really what they are using. For comparison,
> we have other applications running on that server, of comparable
> complexity, and they use 10-15 Mb apiece.
Just remember a few things about your application:
1. Java is a memory pig
2. XML is a memory pig (at least during parsing)
The faster you can throw String objects out of memory, the better.
(A complete digression here:
I hope this has been fixed, but old DOM parsers used to do this when you
called element.getText() (or whatever the equivalent is):
public String getText()
{
return new String(wholeDocument.substring(start, end));
}
This returns a "piece" of the whole XML document. That doesn't sound
like a bad idea until you consider how Java's String.substring works.
The String class "optimizes" substring operations by sharing the
underlying data. Calling "foobar".substring(3) returns a String object
that points to the original "foobar" character array but has the
starting offset set to 3. In this example, you've probably saved some
space. In the DOM example, if you have a 25MB XML document, you've just
pinned 25MB of text in memory until you happen to discard the string
"false" (for example) that you are holding onto as part of your
application's configuration.)
A few parting thoughts:
1. Java does not give up memory that it allocates from the OS. So, once
it's been requested, it'll stay there forever. 'top' isn't the world's
best memory profiler for Java applications. Consider using a real memory
profiler, or even 'jmap', or, in a pinch, something like my
SessionSnooper.jsp (which you can find here:
http://www.christopherschultz.net/projects/java/). That will at least
show you the proportion of Java's heap that is actually in use.
Observing what objects are taking up all your space (jmap's histogram
works just fine) will certainly help out there)
2. Your hardware sucks (for java), so don't expect too much from it ;)
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkbTa0ACgkQ9CaO5/Lv0PCMnQCffzrNnjv3BhGqQYtkuO+Wuopo
8bYAnipWLr3Olp/O4g7mdVdTiO4G4dgO
=UI2l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
