Howdy, I wish your mail program would quote properly -- it's much tougher to read your message without knowing what you wrote and what you quoted ;(
>Yes we are doing a -Xmx, -Xms, -XX:NewSize and not as I typed, sorry about >the confusion. We are in the process to use either of the parallel GC >algorithm with jvm 1.4.2 but dont have grounds to prove it would be better >but only theoretical (wish if you can point to some). But, we need a >parallel collector as we have 4 CPU's per machine and that in fact would >help it with some more parameters like compaction. You would never be able to find GC numbers specific to your app. You must benchmark it yourself, on your servers, to get accurate numbers. Only that will tell you which GC settings are best. At the scale you're dealing with, the characteristics of your application matter a whole lot to the GC performance. >I don't have at present the idea about this number (778m). But, I was more You should know why you're limited the heap at that unusual number. >interested to understand the output that pmap returns and am enclosing one >with this mail right now: I'm not a pmap expert, I've never found it useful in debugging performance or GC problems. I'm sure other people on the list could help more in this area. >The output marked in red, what does this actually signify ??? Excess >swapping ??? >Why is the heap size in pmap output not equal to the one under the column >size in 'TOP' ??? Top lists a lot more than just the heap, so you can't compare the output from top to just the heap in another tool's output. There was nothing marked in red in your message, so I don't know what you mean by the red question. >Anyways what I meant was, if swapping was causing some problems here and do >we require more memory or do we need to tune the application more. >Comments??? When you look at top, it tells you how much swap space is being used. You want to minimize the amount of swap space used. If you have more physical memory, let the JVM use it by increasing the -Xmx setting. >>You have your causality mixed up here. High GC does not cause a high >>number of threads. > >Yeah I think you are right that high threads don't cause the GC but the >default % heap which when filled will invoke the GC. But, more or less all >these threads account for database connections actually and to some >downloads. That's not what I said: What I said and what you say above are both right, but not the same thing. >>Why are they unable to come back? Are they not released back into the >>pool? Do they go bad but not abandoned by the pool? > >This is what I wanted to know .... but seems like the connections are held No one can answer that except you. Run your app inside a profiler and see what holds references to the connection objects. >The crash message and id was checked. This was found an active bug on the >sun's bug database. But, seems they have corrected it in jdk1.4.2. As we >have't had any kills all of a sudden yet, it may have been solved or ...?? ... or you've been lucky so far. You should have the latest OS patches for the JDK installed as a matter of proper procedure. Keep watching this, but if it's OK for now, focus more on the memory usage. >Please help me find a way out of this or a checklist of what need to be >done/checked at this stage. A checklist???? ;) ;) Amusing. I used to go out with a girl who worked at Sapient. Are you up here in Boston? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
