Due to the IO pattern generated by updating RRD's, they are extremely harsh on
disks, and tuning RAID for them to work well is tricky and requires lots of
spindles as well. Take a look at the amount of iowait your system is
sustaining. I'd highly suggest creating a tmpfs mount-point large enough to
hold your RRD fileset, copying your tree into there, and using a symlink in the
ZenOSS install dir pointing to it. Just (obviously) make sure you've got room
to do this without swapping.
I've been doing this with Ganglia/Cacti for years, it solves 100% of your IO
problem, and you'll find your load goes down tremendously, thus increasing the
number of services/metrics you can check on the same hardware. This requires
scripting regular backups (use rsync) of the RRD's. I'm currently looking at
using a RAM SSD for this purpose as RRD sizes for various apps are getting too
big for main-memory capacity, and it enables HA cluster access to the data...
Provided I stick with ZenOSS, I'm splitting up my web/RRD server, DB server,
and perf/avail monitor systems. There's enough load generated by each action,
and serving up user/API requests that removing the monitoring load from the web
server looks quite beneficial (for us). Still looking into how this impacts
RRD locality...
Cheers,
/eli
buldamoosh wrote:
I've noticed the same with a hardware configuration very similar to
yours however, I have 2GB of ram assigned to the session and there is no
memory swapping. This VM session is hosting my development server (FC6)
and is dog slow. My production server is a HP DL385 G5 (4GB RAM,
openSUSE 10.2) and I am using an external MySQL server (also a DL385 G5
with 4GB of RAM). In the end I will have approximately 450 devices
(almost all routers and switches) and expect this server to handle the
devices with overhead to spare. My testing has shown that 2GB of RAM
and dual 3.2 Processors should be able to handle this load with
approximately 50% CPU utilization on a dedicated server. Due to the
extensive writing to disk of modeled devices like switches (switches can
have 6 files per interface and our 6500 series switches can have up to
576 ports for a whopping 3456 files every 5 minutes per switch) I've
noticed an improvement in polling by switching to SAS drives with an
array controll
er (previously a SATA controller). Some companies have a hard time
coming up with this kind of hardware but, it is definitely worth it.
------------------------
Benjamin Moore
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=10260#10260
-------------------- m2f --------------------
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
