A slightly more painful way of determining thread count is taking API logs. These logs would give you the average times it takes to perform operations. There used to be a log timer utility that was useful for this that could generate a report of the time it took to perform each operation. I remember going through that pdf document too that you mention.. Do you happen to have a copy of it available to send? Rgds Joe D'Souza Remedy Developer / Consultant, Shyle Networks, New Jersey.
----- Original Message ---- From: Matt Reinfeldt <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thursday, September 11, 2008 2:09:25 PM Subject: Re: Incident Management 7.x Slow ** Joe, While, in theory, I agree with you regarding the # of users and thread settings, I want to refer you to the BMC Sizing and Capacity Planning_200608.pdf… here’s an excerpt from pages 23-24: “The thread count settings determine the amount of parallel activity that can take place on the AR server system, and therefore lower settings (such as the default setting) will decrease the throughput of the system to a level much lower than observed in the following table. In general, over-configuring threads has little impact, while under-configuring threads might limit throughput. In this way, BMC uses a number approximately three times the CPU count for the number of list threads (both minimum and maximum), and six times the CPU count for the number of fast threads (both minimum and maximum). So a medium configuration will have 12 and 24 threads for List and Fast thread counts, respectively. Such high thread counts will enable batch operations, such as RE, to complete quickly, but will also handle on-line activity effectively. Private threads might also be allocated and used by RE jobs, though configuring that is documented in other locations.” Obviously, this is just a guideline (and they’re referencing ‘medium’ sized installations), however it does make me wonder if that is not at least part of the issue. Just a thought. J Matt R. From:Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Thursday, September 11, 2008 12:38 PM To: arslist@ARSLIST.ORG Subject: Re: Incident Management 7.x Slow ** Depending on how many concurrent users you have on your system, your min and max settings for your fast and list theads may be insufficient so you might want to revisit that eventually. But since you are on MS-SQL, you would do better first checking the status of your transaction logs and if full, back them up and flush them.. If you need to know how thats done let me know.. Its more likely to be the case since you say you have just built the system and transaction logs do tend to get full during install and setup time of the AR System due to heavy SQL transaction at the time of the database being built.. Cheers Joe D'Souza Remedy Developer / Consultant, Shyle Networks, New Jersey. ----- Original Message ---- From: Koyb P. Liabt <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thursday, September 11, 2008 1:23:34 PM Subject: Re: Incident Management 7.x Slow ** Hi, List: Min 2 threads, Max 2 threads (390635) Fast: Min 2 threads, Max 2 threads (390620) Escalation: Min 1 thread, Max 1 thread (390603) Alert: Min 1 thread, Max 1 thread (390601) Entry type is blank with: Min thread 2, Max thread 2 (390626) We are on SQL 2005. Not sure if we have backed up and truncated the transaction logs - we will find out. -----Original Message----- From: Joe DeSouza <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thu, 11 Sep 2008 12:21 pm Subject: Re: Fwd: Incident Management 7.x Slow ** Can you take an AL and Filter log including an SQL log and see if the system is performing any searches to a form that might have a large number of records? Also what about your thread settings? Have you configured your Fast and List threads appropriately? What database are you on? MS-SQL?? If so have you backed up and truncated your transaction logs? These are the few things that come to my mind.. Cheers Joe D'Souza Remedy Developer / Consultant, Shyle Networks, New Jersey. ----- Original Message ---- From: Koyb P. Liabt <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thursday, September 11, 2008 12:12:59 PM Subject: Fwd: Incident Management 7.x Slow ** Forgot to mention - this hanging when submitting tickets to Incident Management also happening in Production - and there has not been any customizations to the Production Incident Management application - its straight out of the box. -----Original Message----- From: [EMAIL PROTECTED] To: ARSLIST@ARSLIST.ORG Sent: Thu, 11 Sep 2008 12:06 pm Subject: Re: Incident Management 7.x Slow We have maybe 23 records in Incident Management because it still new. We have not done much at all in terms of customization. I created one permission group and one active link that is disabled. -----Original Message----- From: Joe DeSouza <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thu, 11 Sep 2008 11:52 am Subject: Re: Incident Management 7.x Slow ** Whats the size of your system? Meaning number of records etc? Any customizations? I would check on things like indexes.. Maybe some customizations you have done runs a bad search? Joe D'Souza Remedy Developer / Consultant, Shyle Networks, New Jersey. ----- Original Message ---- From: Koyb P. Liabt <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thursday, September 11, 2008 11:43:12 AM Subject: Incident Management 7.x Slow ** Hello all, We are on ITSM 7.0.3, patch 7. We are having issues with the Incident Management application only. When the user presses SAVE to create the ticket - it takes 5 minutes to process the transaction, and then the error message comes back and says: ARERR [92] Timeout during database update -- the operation has been accepted by the server and will usually complete successfully : server XYZ The process does not hang when submitting tickets via Asset, or Change Management. I generated logs and nothing jumped out. I noticed the latency happens when modify an incident record ticket also. Is there some bug with Incident Management? _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
