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)
  [EMAIL PROTECTED]
  www.Kohls.com




Robert Halstead <[EMAIL PROTECTED]> 
Sent by: "Action Request System discussion list(ARSList)" 
<[email protected]>
10/23/2008 11:40 AM
Please respond to
[email protected]


To
[email protected]
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.

<<image/jpeg>>

Reply via email to