Yes, Mary. You turn on/off the capability at an AR Server level, but the number is done form by form. Multiple NM (Network Monitoring) systems, like would be in place at a large corporation comprised of an assortment of smaller acquisitions not yet all on the same platform, could feed large numbers of alarms into Remedy as Incidents. I've seen 30k tickets a day in one system (90% NM-sourced), and I am sure that some run higher than that.
Gaps will occur on AR System restart, and all unused Entry IDs are lost. In a server group, this will mean that each server has its own set for pre-allocated IDs, and restarting all servers would cause all sets to be lost on restart. This can be disconcerting to users as well as those who do reporting/metrics. If you work in an industry that audits Remedy data, having missing blocks of IDs may show as a red flag - something to consider. The advice about turning off the Change History is a good one, and indicates the better path to the solution to performance issues. If performance is an issue, my advice is to address it in different ways (like that one) that don't have the negative side effects of the Entry-ID-Block. That being said, I would have a lot less of an issue using the ID allocation for a back-end form like Email Messages than I would for a customer facing one with lots of metrics and reports like Incidents. For instance, I don't know the details of your mail distribution, but you may be able to cut it substantially by turning off some notifications, creating Exchange aliases and sending ONE email out from AR System to that group vs. having the notification group in Remedy that sends a separate email to each person in the group, etc. Email output was actually the source of my testing, as we were doing some consolidation of ticket status update emails to only send one email/person/day instead of one per person/ticket/day. The solution cut the number of outgoing emails by about 85%, if memory serves, and gave the email servers some of their resources back. Rick On Tue, Sep 11, 2012 at 10:16 AM, Mary Dollus <[email protected]>wrote: > 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 <[email protected]> > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
