Author: "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Date: Tue, 10 Sep 2002 10:48:50 +0200
Hi *SM-ers! Last week I read about Rodney Clark doing a 400 objects a second expiration. I checked my expiration process: it's inspecting about 20 objects a second. Ok, maybe he has got faster hardwa
Author: Jane Bamberger <jane.bamberger AT BASSETT DOT ORG>
Date: Thu, 21 Feb 2002 09:08:16 -0500
Hi, I think you might be running into the same problem we are - our expire command never stops - but we do not see any more expired after about 1 hour.. it examines millions of files - but only expir
Author: David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
Date: Thu, 21 Feb 2002 09:25:42 -0500
One simple step that definitely improves expiration processing speed is having enough BUFPOOLSIZE. do a q db f=d and see what the "cache Hit Pct" is. Ideally is 98 % or better. If much lower, even 90
We run expiration daily for a couple of hours, and we realized Tony Jules ITS / Olympus America Inc. 631-844-5887 tony.jules AT olympus DOT com=20 "MMS <health-first.org>" made the following annotati
Author: Allen Barth <allen_barth AT SCUDDER DOT COM>
Date: Thu, 21 Feb 2002 09:13:44 -0600
Also make sure you've got either EXPQUIET specified in your server options file, or specify QUIET=YES on the expire command. David Longo <David.Longo@HEALTH- To: ADSM-L AT VM.MARIST DOT EDU FIRST.ORG
Author: Jane Bamberger <jane.bamberger AT BASSETT DOT ORG>
Date: Thu, 21 Feb 2002 14:38:01 -0500
Hi, I have SELFTUNEBUFpoolsize Yes.. shouldn't that be sufficient? - but I do see that my Cache hit percent is low.. Cache Hit Pct.: 97.15 Cache Wait Pct.: 0.00 Does anyone have any suggestions on ho
Author: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Date: Sun, 04 Oct 2015 17:12:14 -0500
One simple step that definitely improves expiration processing speed is having enough BUFPOOLSIZE. do a q db f=d and see what the "cache Hit Pct" is. Ideally is 98 % or better. If much lower, even 90
Author: Jane Bamberger [mailto:jane.bamberger AT BASSETT DOT ORG]
Date: Sun, 04 Oct 2015 17:12:14 -0500
Hi, I have SELFTUNEBUFpoolsize Yes.. shouldn't that be sufficient? - but I do see that my Cache hit percent is low.. Cache Hit Pct.: 97.15 Cache Wait Pct.: 0.00 Does anyone have any suggestions on ho
Hi, I have SELFTUNEBUFpoolsize Yes.. shouldn't that be sufficient? - but I do see that my Cache hit percent is low.. Cache Hit Pct.: 97.15 Cache Wait Pct.: 0.00 Does anyone have any suggestions on ho
One simple step that definitely improves expiration processing speed is having enough BUFPOOLSIZE. do a q db f=3Dd and see what the "cache Hit Pct" is. Ideally is 98 % or better. If much lower, even
Author: "Richard L. Rhodes" <rhodesr AT FIRSTENERGYCORP DOT COM>
Date: Fri, 31 Aug 2001 15:50:06 -0500
While expiration is running you can see on a "q pro" cmd how many objects are inspected and expired. Is there any way to tell the number of objects expiration still has to inspect? In other words, I'
Author: "Thomas A. La Porte" <tlaporte AT ANIM.DREAMWORKS DOT COM>
Date: Wed, 5 Nov 1997 16:52:58 -0800
I'm curious to hear from others about the length of time it takes for expiration processing to run on their V2 servers. We currently have a 30GB database and it seems to take as much as twelve (12) h
Author: Werner Baur <Werner.Baur AT LRZ-MUENCHEN DOT DE>
Date: Thu, 6 Nov 1997 11:01:17 +0100
At LRZ we have two servers. Processing expire inventory takes about 15 hours on the first server (19 GB database) and 24 hours on the second server (26 GB database). So you see,12 houres for 30 GB is
Author: "PITTSON, TIMOTHY" <PITTSON1 AT BWMAIL1.HCC DOT COM>
Date: Wed, 8 Nov 1995 10:43:00 EST
A few weeks ago, I posted a message about how people are handling expiration processing, particularly for larger ADSM environments. Many thanks to everybody who took the time to respond. From the res
Author: Jerry Lawson <JLAWSON AT ITTHARTFORD DOT COM>
Date: Wed, 8 Nov 1995 12:35:53 +0000
Tim - That is an interesting thought (running the expiration process on alternating days) - We are getting into a large rollout, and some of these things are better thought of now, rather than later.