Re: We have GC problem
On 19.11.2006 01:46, mchunglin@yahoo.com wrote:
We have probem with this one our java biometrics server. Server is
doing too much GCs. The JProbe analyzer says class Bio_lMx315 and
Bio_lMx317 are big problem for us. These class is mostly list of double
like this:
class Bio_lMx315 {
private double chain_315, obp, dbp, lbp, oby, dby, lby;
private double divergence_chain_315, d_obp, d_dbp, d_lbp, d_oby, d_dby,
d_lby;
private String chainName;
private double rtotal_obp, rtotal_dbp, rtotal_lbp, rtotal_oby,
rtotal_dby, rtotal_lby;
private double total_obp, total_dbp, total_lbp, total_oby, total_dby,
total_lby;
...
}
This other classes like Bio_lMx317 looks the same, but for diferent
chain and maybe have little more or little less double.
We getting too many request to compute the chain and the total plus
those regressions and server is doing too much GC and become slow and
we have to kill it. We are not really java programmer! There is three
of us and we don't know all this codes written from a java consultant,
but we have to fix it soon. We thought using object recycling. What do
you think about that? So we don't use new Bio_lMx315 and those other
each time we getting those request, but we have a long cache of them.
We take one out, use them then put it back for use later. I read in
this group someone said you must know the "Life Cycel" of your object.
We know that. We know when use need it and when we do not need them no
longer because computing done. Can you share your comments please? We
don't have lots of time and we must fixing the problems soon.
Server work like this (this is in comment from original programmer):
Utilize a thread pool to divide the biometric modeling work:
BioReceiver directs requests to worker threads (one group for each
chain as persisted in bm_persist_db.ChainDesc). Each worker thread owns
a call back into BioReceiver to notify of completion, results and
problems.
We know to modify this BioReceiver, but we don't want to touch all
those threading codes. We can put the long cache in this BioReceiver
because he doing the BioChain thisRequest = new Bio_lMx315(); and all
those thing.
Please no suggestion about "tweak" -xms params. WE wasting so much time
with this and server will always have problems.
If your JVM is doing too much GC then this could be an indication that
you might actually have too little memory in that machine. If these
objects are short lived then tweaking GC parameters might actually help.
Another reason might be a memory leak, i.e. some part of the program
holds on to objects too long.
With the information presented I cannot say whether object pooling will
or will not help. Reducing the number of concurrent threads might also
be a viable solution - and it is even less intrusive than adding object
pooling.
Frankly, it's difficult to debug this remotely (i.e. via newsgroup) and
fast; and I guess you might have a hard time fixing this if there is no
one around your team that actually knows Java.
Some books you might want to read:
http://www.oreilly.com/catalog/javapt2/index.html
http://www.awprofessional.com/bookstore/product.asp?isbn=0201704293
Otherwise, if it is that urgent hiring a consultant to deal with this
might actually be faster. Other than that you'll have to bite the
bullet and dive into Java.
Kind regards
robert