In my experience the caching process does not occur at the same time.
I’ve always applied changes on the admin server, and then waited 10 mins and logged onto every other AR server in the server group individually to verify the changes have cached. The reason I’ve found the need to do this is that we use a dns load balanced name for our AR server group cluster, and the midtier cluster uses that same name, so I have to make sure changes are cached on all AR servers before flushing cache on the midtier servers. Also: for the Admin server in the server group, make sure users do not connect directly to this server, keep admin functionality separated on a backend server in the server group. Doing so helped us significantly reduce issues with locking. e.g we have 3 active AR servers on the server group at one time, but only 2 are configured on load balancer to be forward facing to users. So they may connect via a dns alias like “remedyitsm.domain.com” – this is the same listed as the server name alias on all AR servers, but the 3rd AR server, which is primary Admin in the server group, is NOT listed on the load balancer, so that users don’t connect to it. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com <http://www.jcp.com/> ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of anantha padmanabhan Sent: Friday, November 04, 2011 4:01 PM To: arslist@ARSLIST.ORG Subject: Re: FW: Remedy Server Group issues ** Thanks Andrew, I guess we have to add these parameters in all server ar.conf file. Delay-Recache-Time: 300 Select-Query-Hint: NOLOCK When we set this does all secondary servers (we have 3 secondary servers) try to recache at same time, that cause any locking problem. Thanks, Ananth On Fri, Nov 4, 2011 at 3:48 PM, Jim Coryat (jcoryat) <jcor...@micron.com> wrote: If your customers can take a little down time, our approach is to: Turn on administrator-only mode on servers in group Restart servers to kick rest of users out Break Server Group Shut down primary server (OLTP - Disable admin operations checked) Perform migration to secondary server (Disable admin operations unchecked) Perform smoke testing on changes Start primary server Rejoin Server Group Turn off administrator-only mode on servers We found that the system load our servers were continuously under, having users accessing Remedy while making updates (especially high traffic forms etc.) was unfeasible and caused more problems than having the system unavailable to them for a short period. We only release updates quarterly so the downtime is not excessive. HTH Jim -----Original Message----- From: Andrew C Goodall [mailto:ago...@jcpenney.com] Sent: Friday, November 04, 2011 1:16 PM Subject: Re: Remedy Server Group issues Yeah make sure you don't have dev-cache mode switched on. Our Delay-Recache-Time: 300 You also may want to try adding: Select-Query-Hint: NOLOCK Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com <http://www.jcp.com/> -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jeyaprakash Sent: Friday, November 04, 2011 2:09 PM To: arslist@ARSLIST.ORG Subject: Remedy Server Group issues Hello everybody, We have Remedy in server group environment. Everytime when we migrate objects to Remedy database locking happens and users are not able to use Remedy. I guess this is due to server sync or cache issue. Remedy documentation suggest couple of points. Anybody has implemented this. If so can you please suggest which settings work fine. Thankyou, Configure the AR System server to control memory use Implement the following AR System server configuration best practices: Set the following AR System server configuration options appropriately: Delay-Recache-Time—Specifies the number of seconds before the server makes the latest cache available to all threads. The minimum is 0, which means every API call will get the latest cache (that is, the cache will be copied for every administrative call or for operations such as arsignal). To permit only one admin copy cache to occur every hour for multiple administrative changes, set this option to the maximum (3600 seconds). Cache-Mode—When set to development cache mode (Cache-Mode: 1), prevents the server from creating a second cache during administrative changes and thus prevents huge memory expansion due to a single action. Development cache mode has these drawbacks, however: When a change is made, users are blocked until the change is completed. Performance is significantly degraded during long-running API calls or programs. Hence, this mode is not recommended for a production environment _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> attend wwrug12 www.wwrug12.com <http://www.wwrug12.com/> ARSList: "Where the Answers Are" The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> attend wwrug12 www.wwrug12.com <http://www.wwrug12.com/> ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> attend wwrug12 www.wwrug12.com <http://www.wwrug12.com/> ARSList: "Where the Answers Are" -- Cheers, Ananth _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
