[vwnc] Finishing garbage collection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] Finishing garbage collection

Paul Baumann
I'm looking for a way to force garbage collection between request processing so that GC costs don't affect request processing.
 
The application being tuned has many weak references--one weak array is as large as 468K. A request takes about 900ms to process if there is no GC activity involved, but can take as long as 6000ms when GC happens during a request. Using perm-save-as cut the number of affected requests in half, but doubled the time in GC, so the amount of old space is relevant.
 
I tried doing "ObjectMemory quickGC" between each request. The cost of each #quickGC was about 83ms, but average request processing time jumped from 1753ms to 2251ms. Can someone explain why requests would take longer now that quickGC is happening between requests? Is there any way to ensure that the cleanup started by #quickGC is completed before resuming?
 
Paul Baumann 
 

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Finishing garbage collection

Paul Baumann
Never mind.
 
It doesn't appear to be a VW problem. After #quickGC, the next trip to GS has to do cleanup costs that were deferred by design. Newer GBS releases can be tricked into partitioning finalization/export costs by making a separate NoOp trip to GemStone. GemStone would have to fix this.
 
Paul Baumann 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Baumann
Sent: Friday, April 04, 2008 9:40 AM
To: [hidden email]
Subject: [vwnc] Finishing garbage collection

I'm looking for a way to force garbage collection between request processing so that GC costs don't affect request processing.
 
The application being tuned has many weak references--one weak array is as large as 468K. A request takes about 900ms to process if there is no GC activity involved, but can take as long as 6000ms when GC happens during a request. Using perm-save-as cut the number of affected requests in half, but doubled the time in GC, so the amount of old space is relevant.
 
I tried doing "ObjectMemory quickGC" between each request. The cost of each #quickGC was about 83ms, but average request processing time jumped from 1753ms to 2251ms. Can someone explain why requests would take longer now that quickGC is happening between requests? Is there any way to ensure that the cleanup started by #quickGC is completed before resuming?
 
Paul Baumann 
 
 

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc