This is a custom app, and I could see updating other forms as an issue. Looking at the workflow, we seem to just doing a lookup on the group form and setting a field on the ticket being closed. It wasn't using an index for the search. We are also inserting another ticket into a different form but using 1=2 as the set if condition so it's inserting everytime (audit trail form). What i'm thinking is that the escalation ended up using all 10 queues for it's operation not leaving a queue open for any user operations.. Is this as designed? Maybe this is just me, but wouldn't you want system processes not use up all the resources but leave a few open for any user requests?
On Dec 19, 2007 3:16 PM, Grooms, Frederick W <[EMAIL PROTECTED]> wrote: > ** The main things to look for are how many other forms are updated when > a ticket is closed and are they updated using indexes. You don't specify if > this is a custom application or a Remedy OTB App. > > The first thing that comes to mind preventing users from logging in is > that the database may be getting bogged down, preventing the User record > from being read. > > Fred > (Sorry about the blank response, some day's I hate windoze) > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Robert Halstead > *Sent:* Wednesday, December 19, 2007 3:59 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Handling 10,000+ tickets in an escalation > > ** Ahh, I see. I was wrong then thinking that the admin queue was the > only one that had database access. So, then let me ask this. If the fast > and list queues hold their own database connection and are multithreaded, > and we currently have our queue sizes setup up so that the minimum is 1 and > the maximum is 10 for both, why would this cause users to not be able to log > in while this escalation was running? > > Also, is there anything in specific that i'm looking for in the filters > while a ticket closes? > > On Dec 19, 2007 2:47 PM, Axton <[EMAIL PROTECTED] > wrote: > > > The admin queue is single threaded, but it is only used for admin > > (specific) operations. > > The escalation queue, in your version, is single threaded. > > The fast/list queues are multi-threaded; this is where the bulk of the > > work is performed. > > > > Each thread, for each queue, has its own db session. > > > > Take a closer look at what the escalation was doing (what are the > > filters doing that it trips). > > > > Axton Grams > > > > On Dec 19, 2007 4:24 PM, Robert Halstead <[EMAIL PROTECTED] > wrote: > > > ** Hello all, > > > > > > First off, we are using AR Server 6.3 patch 22. We have a escalation > > that > > > automatically moves our incident tickets from resolved to closed after > > 48 > > > hours of the ticket being resolved. We recently resolved around > > 40,000 > > > tickets a couple of days ago not thinking of this escalation. Well, > > today, > > > the escalation brought Remedy to a halt as the escalation took over > > all > > > resources. > > > > > > If I remember the docs correctly, the arsystem uses the admin queue > > for all > > > database connections correct? And if I also remember correctly, you > > can > > > only have one admin queue. Why is this limitation in Remedy? And if > > there > > > isn't a limit, what would be the suggested number? We have a server > > group > > > of two servers and one database, we're thinking about using one server > > for > > > all escalations and another that the users can use so that if this > > happens > > > again, only the escalation server will be bogged down and not the > > server > > > everyone is using. Is this a valid setup for a server group? > > > > > > Also, is there some way to force Remedy to say only resolve a limited > > number > > > of tickets in a go? Like a SQL Limit statement? I'm sure we are not > > the > > > only ones who have ran into this problem, but how do you guys handle > > that > > > many tickets in a go? > > > > > > -- > > > "A fool acts, regardless; knowing well that he is wrong. The ignoramus > > acts > > > on only what he knows, but all that he knows. > > > The ignoramus may be saved, but the fool knows that he is doomed." > > > > > > Robert Halstead __20060125_______________________This posting was > > submitted > > > with HTML in it___ > > > > > __20060125_______________________This posting was submitted with HTML in > it___ > -- "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on only what he knows, but all that he knows. The ignoramus may be saved, but the fool knows that he is doomed." Robert Halstead _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
