Have you logged a defect on this problem? _____
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Marty.Thorin Sent: Friday, October 24, 2008 8:55 AM To: arslist@ARSLIST.ORG Subject: Re: User operations halt while group cache is performed ** Be careful switching this to zero. We did this and ran into a memory problem. When in this mode and it needs to recache (such as a group change), it asks for a second copy in memory, does the update, starts running all new actions in the new workspace. Meanwhile the old workspace is kept until all actions are done. Then the old memory is freed. Sounds great, right? Although the AR System freed the memory, Solaris did not. We found ourselves running out of RAM and had to switch modes. We do all major changes to production after hours. These include group changes (but not group membership), form changes, and a bunch of other things. It takes six minutes to recache when our system is idle. I understand ARS 7.1 continues to have this issue. Thorin _____ From: Hall Chad - chahal [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2008 3:29 PM Subject: Re: User operations halt while group cache is performed ** If you set Cache-Mode to 0 then workflow changes, like group and user changes, will recache "silently" without affecting users. Chad Hall (501) 342-2650 _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Robert Halstead Sent: Thursday, October 23, 2008 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: User operations halt while group cache is performed ** Yes, we do have the Cache-Mode set to 1 in our ar.conf file. Also, thanks for the hint on the arthread.log file. I guess when I change the Cache-Mode in our ar.conf i'll also add the Copy-Cache-Logging command in there as well. By setting this value to 0, would workflow changes essentially behave same then? On Thu, Oct 23, 2008 at 12:13 PM, Hall Chad - chahal <[EMAIL PROTECTED]> wrote: ** Do you have development cache mode enabled? If so, it handles caching differently. With this enabled it will block all users until the change is complete. Its ideal for development environments because the changes happen faster. With this disabled, it creates a copy of the cache and only replaces it once all active API calls have completed so that users aren't impacted. Look in ar.cfg for the "Cache-Mode:" tag. If its set to "1", then you're in development mode and that's your problem. If its set to "0", or if its not present in your ar.cfg at all, then you're in production mode and your root cause is still a mystery. There was also a 6.3 bug (although I think it was prior to patch 20) that caused users to lock up during a group recache. Although it may have been specific to dynamic group updates only. I can't remember exactly. Chad Hall (501) 342-2650 _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tony Worthington Sent: Thursday, October 23, 2008 12:36 PM To: arslist@ARSLIST.ORG Subject: Re: User operations halt while group cache is performed We have the same behavior here. You can see the recache operations in arthread.log if you turn on thread logging and add the ar.conf setting Copy-Cache-Logging: T This is from a 7.1 system so I don't know if it applies to 6.x <THRD> /* Wed Oct 22 2008 15:29:17.5320 */ CopyCache Begin: rpcCallProc=41 user="Remedy Application Service" tid=2364 rpcId=2371423 <THRD> /* Wed Oct 22 2008 15:35:10.0060 */ CopyCache End Because of this we only perform group additions, deletions and modifications off-hours. Tony Worthington Sr. Technical Analyst Kohl's Department Stores N56 W17000 Ridgewood Drive Menomonee Falls, WI 53051 262.703.5911 (phone) <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] <http://www.kohls.com/> www.Kohls.com Robert Halstead <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 10/23/2008 11:40 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject User operations halt while group cache is performed ** Hi guys, Hope you all are having a great day. I have an slight issue and some questions that I hope someone could help shed some light on before I take this to BMC support. Recently, we did some group changes via the group form which caused a group-cache update to be performed on the servers. During this time, the CPU of our first server jumped to 90% and sustained that for at least 3-4 minutes. During this time no user could operate in Remedy at all. All other operations came to a screeching halt while this was being done. Is this the norm for a group-cache update? I thought I read in the docs that when a group-cache update occurs, only the admin thread is used and should not affect other list and fast threads from using the system. There will be some performance impact, but no where does it state the system will come to a halt when it's performed. We have also seen this same behavior when modifying a piece of workflow. Though I can understand this happening when we modify workflow to some point as the server needs to recache workflow objects. The thing is, my coworker has worked on other Remedy projects with other companies and hasn't seen this behavior at all. On our most loaded days we only have 170 people accessing remedy. Is this a configuration issue? Has anyone else seen this behavior? My servers are as follows: 2x Sun Fire v480R 1.2 Ghz 4GB RAM Sun Solaris 9 SPARC AR System 6.3 patch 20 server group Database Server: SunFire v210 1.3Ghz 8GB RAM Sun Solaris 9 SPARC Oracle 9i -- "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." Bob Halstead __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _____ CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time without any further consent. ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ -- "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 __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
