We have GC problem

M

mchunglin

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.
 
C

Cyrus

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 you sure it is the problem of creating/freeing of Bio_IMx??? too
much, object pooling can help u. The following is a link about it.
http://www.javaworld.com/jw-06-1998/jw-06-object-pool.html

However, you need to make the following changes on you current code:
1. change "new Bio_IMx???()" to "objectPool.CheckOut()".
2. when a Bio_IMx??? obj is no longer use, call
"objectPool.CheckIn(bioObj)".
 
R

Robert Klemme

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
 
M

mchunglin

Cyrus said:
If you sure it is the problem of creating/freeing of Bio_IMx??? too
much, object pooling can help u. The following is a link about it.
http://www.javaworld.com/jw-06-1998/jw-06-object-pool.html

However, you need to make the following changes on you current code:
1. change "new Bio_IMx???()" to "objectPool.CheckOut()".
2. when a Bio_IMx??? obj is no longer use, call
"objectPool.CheckIn(bioObj)".

Thank you. This kinds of help is what we want. Your using this? Can you
share your experience.. Was your codes running faster more efficiently,
by how much?

Thank you for link it looks good and my team looking on monday.
 
A

Andreas Wollschlaeger

Cyrus said:
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:
[....]
Please no suggestion about "tweak" -xms params. WE wasting so much time
with this and server will always have problems.

If you sure it is the problem of creating/freeing of Bio_IMx??? too
much, object pooling can help u. The following is a link about it.
http://www.javaworld.com/jw-06-1998/jw-06-object-pool.html

However, you need to make the following changes on you current code:
1. change "new Bio_IMx???()" to "objectPool.CheckOut()".
2. when a Bio_IMx??? obj is no longer use, call
"objectPool.CheckIn(bioObj)".

Well, i suppose this article dates back to 1998, with modern JVMs object
pooling is generally considered to *lose* performance in most cases! See
http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html for
a good explanation of this topic, maybe this also gives some insights on
how to fix your server :)

Greetings
Andreas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,608
Members
45,252
Latest member
MeredithPl

Latest Threads

Top