Joe,
The chunk setting should not cause malloc error. There is no timeout issue either. Today I saw memory consumption report when the recache triggered on secondary servers. It is crossing 2GB before the malloc error, a memory limitation on OS or arserver process? Regards, Anthony From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe DeSouza Sent: Wednesday, February 25, 2009 7:50 AM To: [email protected] Subject: Re: ARS 7.1 server group issue ** Its a known issue where ARS on Windows connected to a Remote Oracle database, takes forever to recache and that it takes forever to restart if the services have been stopped and is restarted. This is because of the way that data is read in chunks of 100 rows. It is as designed and Remedy has nothing to do with the design as its more how the Oracle client communicates to remote oracle databases when the client is on Windows.. I didn't experience the kinds of problems you are talking about on UNIX ARS Servers connected to remote Oracle databases. So I guessed your configurations by the symptoms you described. Unfortunately you got to live with it unless you decide to move to UNIX. Joe ________________________________ From: Lyle Taylor <[email protected]> To: [email protected] Sent: Tuesday, February 24, 2009 6:02:40 PM Subject: Re: ARS 7.1 server group issue Correct…… From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe DeSouza Sent: Tuesday, February 24, 2009 3:20 PM To: [email protected] Subject: Re: ARS 7.1 server group issue ** Your AR Servers are probably on windows and connect to Oracle setup as a Remote database? Joe ________________________________ From: Lyle Taylor <[email protected]> To: [email protected] Sent: Tuesday, February 24, 2009 4:27:56 PM Subject: Re: ARS 7.1 server group issue ** I see server groups as being more useful for load balancing and redundancy. While you can indeed have users on the other systems while you perform the updates, the other servers become nearly unusable as the cache updates, especially for anything other than very minor changes. I’ve simply had less issues if I simply bring down the other servers during the changes and then bring them back up again after. In my experience, that actually provides a better user experience, because knowing that it’s down for a short time is easier to deal with than extremely slow performance during a cache update. Lyle From:
