André Warnier wrote: > Now that I have (with your help) established some basic facts, I have a > practical case for analysis. > > 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). ... > 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)
Comments on your situation and "top" snapshots: - you're low on memory, but not paging heavily yet; you're likely taking some kind of hit from not having enough memory for a decent buffer cache (disk cache), though - your swap usage remains constant to 70000k (on which I base my claim that you're not paging heavily) - CPU usage, at least based on these snapshots, is almost pure user-mode CPU use, so there's little else happening than some computation internal to the application/Tomcat - looks like you could do with slightly smaller Java heap size, at least at this point of execution -- but it also could be that a smaller heap would get you an OutOfMemoryError later on - based on the fact that 'top' shows only 188M memory resident of the total 482M address space, the application is not even close to heap size (thus GC limits), but you could verily the GC issue by enabling verbose garbage collection for your JVM (with -verbose:gc flag to Java startup parameters) - you could also see which of the threads are taking time, with "ps -fLp <pid-of-tomcat-java>" (and getting the thread information f.ex. by getting a thread dump with "kill -QUIT <pid-of-tomcat-java>" to catalina.out > In other words, while this application is being loaded, our Tomcat and > the whole system are totally unresponsive for about 5 minutes. Whole system - as in "ls" from command line taking ages to complete when the startup is running? If so, then this could indicate a bottleneck in disk I/O (and as such, would be, partially at least, in line with my comment on not having enough memory for a buffer cache). However, this could also contradict my assumption that paging is not the issue. If it's a memory issue, you could help it a bit by lowering the heap size limit for the Tomcat JVM (but therein lies the risk of getting an OOME). However, as you noted, the machine is weak in terms of memory capacity and CPU power -- and I would suspect in hard drive speed just as well. And what it is you're doing: loading a largish file from the drive (while having minimal amount of memory available for buffer cache), and doing some memory- and CPU-intensive processing (XML parsing) on it. So, I would encourage you to have a look at the start times of the application on one of your production servers, preferably at a time of low traffic. In case of hangs, it might be good to have a command-line ready with "kill -9 <pid-of-tomcat-java>" to forcibly end the Tomcat process (however I strongly suspect you're not going to need it). -- ..Juha --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
