Hi David, Shahla, Brett, Michael, Calvin, all others, we've all CsVendor and SG-Support files in version control. Having checked this I can say H13 brought changes to Cabletron/EventDisp, among other things the events causing these alarms, as well as the new Prob00010f20 for the alarm.
Seems as if the only change is to generate these alarms now, the cause has always been the same - GCs don't need more CPU resources than before, but now you're notified about remarkable threshold violations. Hope that helps, Marcel On Fri, Oct 17, 2008 at 2:18 AM, Nissel, David < [EMAIL PROTECTED]> wrote: > While it is true that you can up the thresholds, the point I was trying > to make was that we never had any threshold problems previously (unless they > are new alarms in H13 and above). By increasing the thresholds, you do > indeed get rid of the alarms but the fact remains that you are still > experiencing an issue that had not existed previously and that is the fact > the GCs now appear to be eating more CPU resources than they did before the > hotfixes. Upping the threshold just hides it. > > -dave > > > Dave Nissel > Network Architect > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > Select Medical Corporation > Voice (717) 975-4522 > Fax (717) 412-9371 > E-Mail [EMAIL PROTECTED] > SendPlainText > > -----Original Message----- > *From:* Calvin Lane [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, October 15, 2008 9:55 AM > *To:* spectrum > *Cc:* spectrum > *Subject:* Re: [spectrum] GLOBAL COLLECTION CPU THRESHOLD EXCEEDED > > > I was getting this alarm for about two weeks. After some research and > talking to support they suggested that I increase the Global Collection CPU > threshold setting. You basically have to add the following line to your > .vnmrc file, 'gc_perf_cpu_threshold= ' . If you look under the Alarm > History tab you will be able to see how long the Global Collection updates > are taking. You want to make that threshold setting greater than the > highest update value. After you change the .vnmrc you will have to restart > your SpectroSERVER. This will take care of that alarm. > > Calvin Lane > [EMAIL PROTECTED] > > > > On 10/15/08, Zink, Michael <[EMAIL PROTECTED]> wrote: >> >> We started running into this issue after upgrading to H13. H13 caused our >> system to core dump about every 2 days. We received a patch to H13 to >> correct the core dumps. It corrected the problem to about one core dump per >> week. We received a second patch to H13 and have not seen any additional >> core dumps. However, after we loaded the second patch, we started noticing >> the Global Collection Threshold alarms. When I spoke to Spectrum support >> about this, I was told that we needed to look at our SpectroServer >> resources. I was not told about SP2. >> >> Michael Zink >> >> Network Analyst >> Information Technology Services >> 3700 Wake Forest Road >> Raleigh, NC 27609 >> (P) - 919-754-6095 >> (F) - 919-850-2827 >> >> ++++++++++++++++++++++++++++++++++++++++++ >> >> -----Original Message----- >> From: Nissel, David [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 15, 2008 9:12 AM >> To: spectrum >> Subject: RE: [spectrum] GLOBAL COLLECTION CPU THRESHOLD EXCEEDED >> >> I began running into this error daily when I upgraded to H14 - have you >> done so as well?. I had never seen a collection error like Shahla describes >> up until that point and the collections did not change. I did go back >> through and optimize the criteria and the errors seem to have dissipated, >> though I'll have to watch it for a few more days to confirm it. I also have >> a hunch that it was related to my random SS crashes insofar as that if a >> couple of them decided to fire up and update at the same time, the stress >> may have been too much for the SS process to handle. We'll see if that calms >> down as well. >> >> On another note related H14 however, when I opened a call with CA, they >> did indicate that they have seen issues in some customer sites with the >> SpectroServer.exe in that patch. Apparently its related to some memory >> management binaries that are included in the executable. They sent me one >> that is compiled without it which also seems to have helped the random SS >> crashes. >> >> Dave Nissel >> Network Architect >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Select Medical Corporation >> Voice (717) 975-4522 >> Fax (717) 412-9371 >> E-Mail [EMAIL PROTECTED] >> SendPlainText >> >> >> -----Original Message----- >> From: Brett Davis [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 15, 2008 8:56 AM >> To: spectrum >> Subject: Re: [spectrum] GLOBAL COLLECTION CPU THRESHOLD EXCEEDED >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Shahla, >> >> Did you recently modify the search criteria on the global collection? If >> you accidentally put an "OR" where you meant to have an "AND" you could >> easily end with an overwhelmingly large global collection. This is >> because Spectrum will not only model devices in global collections, but >> will also find any Applications, Ports, etc that match the criteria. >> When this happens in our environment (3000+ network devices) it actually >> causes the whole spectroserver to crash usually. >> >> My suggestion is to double check the numbers and criteria on your >> collection if it's a dynamically updating one. >> - -- >> Brett Davis >> IT Network and Security Operations >> Cisco Certified Network Associate (CCNA) >> Purdue University >> YONG 605 >> Phone (765) 49-62304 >> [EMAIL PROTECTED] >> >> Tabarzadi, Shahla wrote: >> > Less-than optimal SpectroSERVER performance, abnormally disconnected >> > clients, and slow response times. >> > >> > >> > >> > A Global Collection update has taken a longer-than-normal amount of CPU >> > time, which might be contributing to the above symptoms. >> > >> > >> > >> > Note: I have already opened a case with support but they recommend SP2 >> > which is not available yet. >> > >> > ------------------------------------------------------------------------ >> > ------------------------------ >> > >> > Shahla Tabarzadi >> > CAO Network Engineering and Configuration Branch >> > U.S. House of Representatives >> > 202-226-6266 >> > >> > >> > >> > >> > --- >> > To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the >> body: unsubscribe spectrum [EMAIL PROTECTED] >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkj16FoACgkQ+j4RojbPFmAjnwCfWbaTbn+m1516hhQBU3oy+mrz >> eyYAoKGDznCmH0C+tNhonawt4a8B5awO >> =lu8P >> -----END PGP SIGNATURE----- >> >> --- >> To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the >> body: unsubscribe spectrum [EMAIL PROTECTED] >> >> --- >> To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the >> body: unsubscribe spectrum [EMAIL PROTECTED] >> > > > - --To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with > the body: unsubscribe spectrum [EMAIL PROTECTED] > > > > - --To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with > the body: unsubscribe spectrum [EMAIL PROTECTED] > > --- To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the body: unsubscribe spectrum [EMAIL PROTECTED]
