Here is the entries from thread log; <THRD> /* Wed Feb 25 2009 05:16:37.8330 */ Thread Trace Log -- ON (AR Server 7.1.00 Patch 005 200809150630)
<THRD> /* Wed Feb 25 2009 05:22:15.5140 */ InitServerCache Begin <THRD> /* Wed Feb 25 2009 05:22:29.0760 */ FreeServerCache: rpcCallProc=10004 user="Remedy Application Service" tid=3076 rpcId=390600 <THRD> /* Wed Feb 25 2009 05:22:29.3260 */ Thread Id 3076 (thread number 1) on ADMIN queue died. <THRD> /* Wed Feb 25 2009 05:22:29.3260 */ Thread Id 4600 (thread number 1) on ADMIN queue restarted. <THRD> /* Wed Feb 25 2009 05:32:15.5020 */ InitServerCache Begin <THRD> /* Wed Feb 25 2009 05:32:28.7990 */ FreeServerCache: rpcCallProc=10004 user="Remedy Application Service" tid=4600 rpcId=390600 <THRD> /* Wed Feb 25 2009 05:32:29.0490 */ Thread Id 4600 (thread number 1) on ADMIN queue died. <THRD> /* Wed Feb 25 2009 05:32:29.0490 */ Thread Id 5916 (thread number 1) on ADMIN queue restarted. Regards, Anthony From: Rathnappa, Anthony Sent: Wednesday, February 25, 2009 4:57 PM To: arslist@ARSLIST.ORG Subject: RE: ARS 7.1 server group issue I have verified the boot.ini file has /3G switch. Also using ‘dumpbin’ tool I got confirmed that arserver can address more than 2GB. After startup the memory consumed is ~1.3GB, as shown in Task Manager. This is still a pre-prod env, so there are no users. In the Dev env, I had used ;CopyCache Begin’ flag, where the log showed only ‘CopyCache Begin:’ but no ‘CopyCache End’ Will enable both flags and update you. Thanks, Anthony From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Walters, Mark Sent: Wednesday, February 25, 2009 1:46 PM To: arslist@ARSLIST.ORG Subject: Re: ARS 7.1 server group issue By default the maximum memory arserver can access on 32-bit Windows is 2GB. If it tries to grow beyond this then it will fail. This is an OS limitation that can be changed to 3GB by the addition of the /3GB switch to the appropriate line in the boot.ini file. See http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx and many of the other pages returned by a Google for “windows 3gb boot.ini”. The arserver is compiled with the large address aware flag that enables it to make use of the additional 1GB of RAM provided by this switch. However, I’d be interested to understand why your arserver process is getting so large that it is reaching the 2GB limit. How much memory does arserver.exe consume after startup – at the point that users can login? How many concurrent users? The initial size of the process is largely determined by the amount of forms and workflow that you have on the system as these are all read in to the server to create the cache. If you have a full ITSM system with multiple language packs the initial size could be in excess of 700MB. Once it is up and running the server will increase in size as it allocates memory to handle it’s day-to-day work – processing query results and so on. One of the advantages of the Windows platform is that once the server releases the memory it is returned to the OS and the footprint should shrink again. If the maximum process size (2 or 3 GB depending on the flag above) minus the current size or arserverd is LESS than the startup size a recache operation is likely to fail. Things that you could do; · Enable the /3GB option · If your startup size is very large look to remove unused views, forms, workflow from the system · Set Large-Result-Logging-Threshold: 100000 in ar.cfg and enable thread logging on the secondary servers – this will show you if you have users running queries returning large datasets and consuming memory. · Set Copy-Cache-Logging: T too – this will record the recache operations in the thread log. You want to make sure that you see the freeservercache that indicates that the server has released the original copy of the cache. If you have long running API calls it is possible for the server to end up with more than 2 copies of the cache – if this is a large cache you can very quickly hit the memory limit. Eg This is bad – multiple copies – you want to see a begin, end and free before the next begin. CopyCache Begin: rpcCallProc=10002 user="Remedy Application Service" tid=5 rpcId=0 CopyCache End CopyCache Begin: rpcCallProc=10002 user="Remedy Application Service" tid=5 rpcId=0 CopyCache End FreeServerCache: rpcCallProc=10018 user="Remedy Application Service" tid=5 rpcId=1178442632 Incidentally, if you have are using 64-bit Windows I believe the maximum size of a large address aware enabled 32-bit application is 4GB by default - http://msdn.microsoft.com/en-us/library/ms791558.aspx Mark Walters The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or support representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Anthony K R Sent: 25 February 2009 07:17 To: arslist@ARSLIST.ORG Subject: Re: ARS 7.1 server group issue 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:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Wednesday, February 25, 2009 7:50 AM To: arslist@ARSLIST.ORG 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 <tayl...@ldschurch.org> To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Tuesday, February 24, 2009 3:20 PM To: arslist@ARSLIST.ORG 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 <tayl...@ldschurch.org> To: arslist@ARSLIST.ORG 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:
