Hi All, I came across this thread dated back to October, and found that it applied to my current situation. I have just upgraded to 9.0 SP1, and am now encountering the same type of messages. It is unclear from all the responses below as to which is exactly the best way to handle these alerts. If it has just been happening all the long, but is just now being reported on in these later versions of Spectrum. Is it possible to raise the 'Threshold' of the alert so it only appears if it is an extreme timeframe, and applied to only specific containers? Or is the solution to still just to modify the .vnmrc so that it applies to all containers. I have some containers that alarm at just 5060 ms. Then I have others than exceed 15000ms. This solution seems to be a blanket coverage. I do not see an attribute in the atribute editor for threshold settings on just specific collections. Has anyone pursued this further? Thanks Patrick
________________________________ From: Marcel Schulte [mailto:[email protected]] Sent: Thursday, October 16, 2008 11:44 PM To: spectrum Subject: Re: [spectrum] GLOBAL COLLECTION CPU THRESHOLD EXCEEDED 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] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
