For the Oracle bulk fetch parameter: Default Config (Oracle-Bulk-Fetch-Count: 50): LoadDisplayInfoList: Loads 500 rows at a time LoadFieldPermissions: Loads 50 rows at a time
Modified Config (Oracle-Bulk-Fetch-Count: 100): LoadDisplayInfoList: Loads 500 rows at a time LoadFieldPermissions: Loads 50 rows at a time The Oracle-Bulk-Fetch-Count configuration parameter has no bearing on this portion of the startup routine. No difference at all. On Feb 17, 2008 7:33 PM, Guillaume Rheault <[EMAIL PROTECTED]> wrote: > I wonder if the ar.conf parameter Oracle-Bulk-Fetch-Count has any bearing > on this. > the maximum is 100 which is ridiculously low in this day an age > > Guillaume > > -----Original Message----- > From: Action Request System discussion list(ARSList) on behalf of Axton > Sent: Thu 02/14/08 10:00 AM > To: [email protected] > Subject: Re: arserver.exe Memory Usage 7.0.01 > > Remedy just needs to tune the startup of arserver. That's kind of where > the > problem lies. > > start arserver > ... > -> fetch 100 of 50000 records from feild_dispprop (read 6mb of data and > use > 20k) > -> process those 100 records > -> fetch next 100 of 50000 records from feild_dispprop (read 6mb of data > and > use 20k) > -> process those 100 records > -> fetch next 100 of 50000 records from feild_dispprop (read 6mb of data > and > use 20k) > -> process those 100 records > ... > > No wonder it takes so long. How about fetching all the data at once, the > processing it serially, or even better, in parallel. It is something that > can be done, but the people at BMC have to be convinced that there is a > benefit to the customers, and they probably have to be able to directly > capitalize on it to get a direction from management, neither of which is > probably going to happen. > > Axton Grams > > On Thu, Feb 14, 2008 at 9:02 AM, Bardsley, Michael < > [EMAIL PROTECTED]> wrote: > > > ** I was told by support that there is a known slow startup issue with a > > windows/remote oracle database configuration. We are looking at about 7 > > minutes startup. My db confirmed that at startup he see's the ARADMIN > > account pulling little bits of information at a slow pace from > field_dispprop > > table. I was told that is the Data Definition files that AR holds in > > memory. We have also seen some database timeouts while saving changes > in > > the Admin tool. > > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza > > *Sent:* Thursday, February 14, 2008 2:37 AM > > > > *To:* [email protected] > > *Subject:* Re: arserver.exe Memory Usage 7.0.01 > > > > ** We are running our AR Server at around that much (650,000 K) too. We > > are experiencing a lag of at least 15 minutes at the start of the > services. > > We are currently working with BMC Support on that.. At Remedy supports > > suggestion, we tried a 1 GB connection @ Full Duplex between the AR > Server > > and the DB and that didn't help much either. > > > > What is the average time you guys are experiencing on restart of AR > > Services? > > > > We are running all the ITSM apps, AIE, CMDB, SLM, BMC RKM, SRM on our AR > > Server. > > > > We have tried tuning the database with the help of our DBA's and none of > > our efforts produced any significant change in the performance during > > startup. > > > > Even after startup, it does take unreasonably long to save even a light > > form or save a filter or active link or menus even if we click on the > server > > name on the server window so it doesn't refresh any lists after saving > an > > object.. > > > > Is anyone else fighting a similar issue? > > > > Joe > > > > -----Original Message----- > > *From:* Action Request System discussion list(ARSList) [mailto: > > [EMAIL PROTECTED] Behalf Of *strauss > > *Sent:* Wednesday, February 13, 2008 10:50 AM > > *To:* [email protected] > > *Subject:* Re: arserver.exe Memory Usage 7.0.01 > > > > ** Typically ARS 7.1.00.001 runs at about 650,000 K on my Win2K3 x64 > > servers. The one I have up that has relatively steady development in > > Kinetic Request going on, plus daily testing of notifications and > paging, > > shows a peak at 825,000 K - and it has been running without a restart > since > > 16 January. The back end is SQL Server 2005 x64 on separate servers. > It > > has been a while since I ran any 7.0.01 servers (patch 003, middle of > last > > year), but I believe that 7.1 has a smaller memory footprint. > > > > Christopher Strauss, Ph.D. > > Call Tracking Administration Manager > > University of North Texas Computing & IT Center > > http://itsm.unt.edu/ > > > > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Bardsley, Michael > > *Sent:* Wednesday, February 13, 2008 8:50 AM > > *To:* [email protected] > > *Subject:* arserver.exe Memory Usage 7.0.01 > > > > ** > > > > Not sure if anyone will be able to provide me a direct answer on this > but > > would anyone be able to tell me about how much memory arserver.exeshould > > be consuming on the server after it has been running for a few days > without > > restarting? > > > > I am running ARS 7.0.01 Patch 005 with the full ITSM 7.02 Suite, SLM > 7.03, > > and CMDB 2 on a Windows server pointing to a remote Oracle 10G database. > > > > We just recently went live so we have been doing a lot of restarts as we > > have had to make system changes. I noticed that after a restart > > arserver.exe consumes about 700,000 K. > > > > After a few days of not restarting I am seeing that the memory footprint > > has grown to about 1,300,000 K which has me concerned about a memory > leak. > > This may be normal and it may not grow much larger so I will continue to > > monitor but wanted to toss the question out there.. > > > > I understand that all environments are different and therefore no one > > instance is correct but just thought I would ask. > > > > Thanks, > > > > *Michael Bardsley* > > > > __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" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
