Wondering if anyone else has had trouble with Prizm seemingly freezing on occasion? Postgres has processes at the top of the cpu usage list so I suspect that prizm is trying to write the results of its scans to the db. I would think that the sql would be much more efficient at db writes than that but that is about all I can think of at the moment. I currently only have a couple hundred AP/BH/SM 's polling every 10 minutes so I would think it should handle that load well.
If anyone else has seen this or hopefully solved the issue I would be very interested.
Ya I’ve seen it as well. When doing a TOP on the server the CPU usage peaks for the postmaster file. Performing a VACUUM on the system usually returns the CPU usage to normal. Not sure why it happens though.
Could be do to the hardware for the server. From what I read, MOTO recommends that the server be running the following:
P4 3.0Ghz CPU or higher
40GB Harddrive
1 GB of RAM
512MB Maximum Prizm RAM
Prizm supports only Intel x86 with Pentium P4 or greater processors and high amounts of:
- Level 2 memory cache (secondary cache)
- Front side bus speed
- RAM
Thanks for that tip. And for those running less than 8.1 (most RedHat at the moment) you might try a cron job like the following:
# Vacuum (clean up) the db’s on the server
su postgres
vacuumdb --all --full
Should work in the standard install I think. You may have to adjust your hba file to allow this to work.
Plus if you using Cacti and Nagios, might as well shut off the EMS Feature in Prizm…it’s just taking up more bandwidth.
But I have to say that integrating prizm into some other system is easier than either cacti or nagios. We use both of those for monitoring our other equipment but the lack of any API makes integration very difficult. Prizm really does have some nice features built into it. There are a lot of things I want to see changed and added but it is a good tool that smoothly integrates with our billing.
It would be even better if they did a better job when they wrote the java, or better yet writing it in something other then java. But it’s all about the $$$.
Meaning it isn't worth what they are pricing it for or the dollars required to program something other than java? Don't get me wrong, I am no java fan, just wondering what your take is. I have noticed that for some reason there are a lot of java based snmp centric systems out there from a lot of big named companies. It is a huge resource hog on both the client and server.
Frothingdog.ca wrote: It would be even better if they did a better job when they wrote the java, or better yet writing it in something other then java. But it's all about the $$$.