When you say the Escalation was scanning 40 million records, are you saying it was processing that many records? Wasn't there a Run If condition that narrowed the set to a smaller subset? If so then that was one 'expensive' requirement to process 40 million records in an escalation. I do not think the Escalation thread can handle that many records in a single run. Escalations are usually designed to run over a much smaller subset of records and tipping over a 4 or a 5 K mark I would think is begging for some trouble in the long run.
Joe ________________________________ From: Chintan Shah <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Monday, November 24, 2008 6:47:47 PM Subject: Re: libumem - performance increase on Solaris with ITSM 7.X ** Hi Terry, We have libumem on our production system(all custom remedy apps..no ITSM)..but here's the deal..if you dont specify the "Number of results returned"there is possibility that "arserverd" will crash. We have tested this on couple of different machines with same configurations. However, if you set "Number of records returned" to 3000, it works fine. We had an escalation scanning 40 million records that crashed "arserverd" in less than 4 minutes even though we were on libumem. Although it was bad code, instead of throwing any errors, it just crashed. Another issue was with form which had 2 million records and "Results List" had more than 15 fields. This also crashed server on "Search". We are on Solaris 5.10. Try the above scenarios. It might also be related to Hardware and all those fuzzy CPU utilization..but I am not sure..all I saw from remedy side was that it got crashed. Thanks Chintan. --- On Mon, 11/24/08, Terry Bootsma <[EMAIL PROTECTED]> wrote: From: Terry Bootsma <[EMAIL PROTECTED]> Subject: libumem - performance increase on Solaris with ITSM 7.X To: arslist@ARSLIST.ORG Date: Monday, November 24, 2008, 3:08 PM Hello arslist: We have been utilizing ARS 7.1 Patch 004 with ITSM 7.0.2 (latest patch for Incident, Change, Config, and Problem) on a multi-CPU, high end Solaris box running DB2. We have had SIGNIFICANT performance issues under high load running this configuration as a result of our load testing exercise. However, after meeting with Remedy engineers yesterday, they suggested that we replace the standard Solaris memory manager with a preloaded "libumem" memory manager. This has produced astonishing results and has resolved our issue of performance under high load with the fact that libumem uses a different memory allocation model that is more condusive to multi-cpu, multi-threaded applications. My question to the list is this. Have any of you replaced your memory manager in production with "libumem" and , if so, were there any side affects of doing so? Thanks for any feedback.... Terry _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
