Rick, Thanks so much Rick! And yes that is our issue... we send out enormous amounts of email, so the AR System Email Message form gets hit pretty hard and the system was tied up creating the New ID's and yes, caused performance issues...
Were you able to do any testing in 7.6.04? And yes, we are considering this based on a recommendation from BMC.... Here are the results of our testing so far: ["No gaps were created under the test conditions which involved running 10 instances of the script simultaneously. Tricia used the xxxx application on the 7.6 system, and there were only 2 fast/2 list threads. One thing observed was that when Tricia changed the next id block size from 25 down to 1, a gap of several IDs occurred. The Remedy documentation says that a restart of ARS can result in gaps. This appears to be caused because the reserved block of IDs is in memory and this is lost when restarting ARS, or in this case also when the AR configuration change occurred. So, we can expect gaps if arserverd crashes or is restarted, but perhaps it is unlikely otherwise."] Sorry if this is a dumb question,,, but in your comment below, what does "MULTIPLE NM" mean... and are you saying it is possible to add the next ID increase to ONLY that form? and not a global change for all forms? "[Your comment from below] So if you have MULTIPLE NM apps feeding the SAME form at the SAME time with LOTS of records (thousands/day), then yes, you should increase the setting for THAT form to a higher number. " Thanks!! Mary ******************** Mary, I did some extensive research on the Next-ID-Block size setting in 7.5 a couple years ago. That research involved formal performance testing and conversations with BMC Engineers about the results I found. The results were that it didn't help. In fact, performance was actually diminished in over half of the cases. Maybe that was due to unrelated traffic, but at very least I can say that there was no noticeable improvement with the settings at anything above 1. The word from BMC when this feature was released was that it was in response to multiple Network Management applications (i.e. Patrol, Netcool, HP, Tivoli, etc.) feeding large number of records into the same form on the same AR Server at the same time. This caused contention for SQL pulls of the Entry ID, which was causing performance issues. The problem is that BMC, for some reason, is recommending increasing that number to something above 1 as a default setting, without apparent justification for that recommendation. I have seen nothing that has changed the justification for the setting beyond the initial requirement. I have seen nothing to indicate that either the function or the rationale have changed in 7.6x. So if you have MULTIPLE NM apps feeding the SAME form at the SAME time with LOTS of records (thousands/day), then yes, you should increase the setting for THAT form to a higher number. If you are not, then you shouldn't. The cost is far greater than any benefit you might see. Rick On Tue, Sep 11, 2012 at 9:27 AM, Mary Dollus <mary.t.dol...@saic.com> wrote: Hi Everyone, We are going to set our Next ID Block size from 1 to 25 due to some issues we had last week with our AR System Email Messages form tying up the system. We did some initial testing and it seems like there shouldn't be any issues. Is there in anything particular we need to look out for? Has anyone noticed any gaps in the Request ID sequencing and if so, to what extent? What is your environment if you noticed issues? Do you use a server group? and what was the value of your Next ID Block size? Thanks so much in advance!! Mary Dollus ARS 7.6.04 Oracle/UNIX _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
