Please correct me if I'm wrong, but I thought actions occurring with escalations stay within the escalation thread (even filters, etc.) in 6.x and 7.x? This negated the capability to have an escalation do a Set Field of Delete = Yes, and then having a filter do the actual delete -- instead of running in separate threads and being asynchronous...they're all in the same thread running synchronously. It shouldn't have been the escalation that brought your system to its knees since it would've isolated all the processing to the 390603 RPC thread/queue (not utilizing the Fast/List queues)...but perhaps some other bottleneck (network or db)? J.T. New Edge Networks An EarthLink Company
________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Robert Halstead Sent: Wednesday, December 19, 2007 2:48 PM To: arslist@ARSLIST.ORG Subject: Re: Handling 10,000+ tickets in an escalation ** Another funny thing, not only could I not log into Remedy, but couldn't log into it using the admin tool.. On Dec 19, 2007 3:39 PM, Robert Halstead < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: 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 -- "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___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
<<Muppets - Beaker.jpg>>
