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 |
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 |
Free forum by Nabble | Edit this page |