One of my two 7.1 mid-tiers (development, currently being tested by a few support staff users) keeps dumping cached definitions after a successful persistent prefetch. After no one uses it for a while, it behaves just like it never prefetched when someone logs on and tries to open the Incident console - over a minute delay on each console or form, then very fast after that. This is on Win2K3 Ent but the Tomcat instance has mid-tier, Crystal Report Server, and RKM sharing it. On the pre-production server where mid-tier is the sole user of the Tomcat instance, Win2K3 Ent x64, I have not seen this behavior even when no one logs on to this mid-tier for days at a time. I tried it a minute ago for the first time this week and it seemed faster than the user tool. When I hit development this morning, I was the first user and it took 1.5 minutes to load the Incident Mgmt Console.
All of the mid-tier configuration settings are the same, except the reporting server, and they both have the same prefetch.xml file (with different server names). I have a ticket open on it, but no resolution so far; I may just have to completely reinstall the development web server, but it's too busy right now. So far, it is just reinforcing my belief that mid-tier, RKM, and Crystal Reports should all have separate Tomcat instances, if possible on separate servers, which is how I am building out pre-production - mainly because I caught RKM killing Tomcat when the Hummingbird SearchServer crashed, forcing a prefetch on mid-tier during production hours. The persistent cache seems to work across manual stops and starts of Tomcat, although that has failed for me at least once on the pre-production server, but it does not work across crashes of Tomcat (which is where you want it the most, of course). I don't think the persistent cache is quite where it needs to be yet, but the 7.1 release definitely lowered some of the page load times from what they were in 7.0.x. Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Murray Sent: Monday, October 15, 2007 2:01 PM To: [email protected] Subject: Re: w3wp.exe pegs CPU randomly - ARS 6.3 Hi Christopher, Re: your comment " Mid-tier 7.1 has other issues with the persistent cache, but that's another topic", what have you seen? Heard? Can you share your experience. One of the key drivers for us to upgrade is this feature...any input welcome... TIA, Kevin -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: 12 October 2007 19:46 To: [email protected] Subject: Re: w3wp.exe pegs CPU randomly - ARS 6.3 Mid-tier 7.1 has other issues with the persistent cache, but that's another topic. I would agree that you are seeing some sort of recaching activity on the part of the 6.3 mid-tier. When mid-tier 7.x prefetches and caches an ITSM 7 application (or most of its forms), we always see about 25-35 minutes of 35% CPU activity on the AR server, with somewhat less load on the mid-tier server - more like 20% load and in smaller peaks that are converse to the AR Server load. The load on the db server during this process is perceivable, but very low - about 5%. During that time period even User Tool access to the AR Server is definitely degraded. These are all Tomcat-based mid-tiers on 2003 Enterprise servers with more RAM and CPU than 32-bit BMC software knows what to do with. Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head > Sent: Friday, October 12, 2007 1:31 PM > To: [email protected] > Subject: Re: w3wp.exe pegs CPU randomly - ARS 6.3 > > Are you running ITSM?...this sounds like the Mid-Tier caching itself > the first time someone access the app in the morning...if I'm not > mistaken 6.3 Mid-tier will clear it's cache of unused items during > down periods (overnight)...and the first person to request the page > will get a delay while it's caching. If this is the case...then a > properly configured 7.1 mid-tier should alleviate your issues as 7.1 > has persistent cache capabilities. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Julie Rockwood > Sent: Friday, October 12, 2007 12:23 PM > To: [email protected] > Subject: w3wp.exe pegs CPU randomly - ARS 6.3 > > Hello list, > Calling all Win 2003 Remedy geeks. We are having production problems > on our win 2003, ARS 6.3 patch 14 mid-tier server. > Below is an email from my system administrator describing the problem. > If anyone has any ideas, we would sure appreciate it. > Julie > > I manage the server instances for our ARS team which are the > following: > > Mid-tier: W2K3/IIS6.0/ServletExec 5.0/ARS 6.3 - VMware > Application: W2K3/ARS 6.3 - VMware > Database: Oracle 9i on AIX 5.3.x > > Anyway, I'm seeing the w3wp peg the CPU on the mid-tier almost every > morning, rendering the web server inoperable (even for static html > rendering). If I temporarily remove the ServletExec ISAPI filter, > static html rendering is fine and CPU utilization is normal. Re- > insert the filter and perform an iisreset - the same behavior occurs. > > If I wait about 15-20 minutes (this problem occurs almost daily at > 6:30 so customers aren't complaining yet) the problem clears itself > out and everything is working fine. If I monkey with it (iisresets, > rebooting, etc) the problem perpetuates itself even longer. > > We're moving towards a ARS 7.1 install on new infrastructure, so I'm > hoping this will fix it - but in the meantime if anyone has run into > this (and possibly fixed it) any pointers would be greatly > appreciated. > > Thanks! > > ______________________________________________________________ > ______________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > ARSlist:"Where the Answers Are" > > ______________________________________________________________ > _________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > ARSlist:"Where the Answers Are" > ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
