On Aug 30, 2012, at 1:19 AM, Ron Roskens <rosk...@elfin.net> wrote:

Attached is a zip file with logs from running opennms-rrd-stresser using CassandraRrdStrategy, JRobinRrdStrategy, and JniRrdStrategy.

Could you show us how you configured and setup the environment and ran the RRD Stressor?


I ran these inside a virtualbox vm running fedora 17, with kernel 3.5.2-3.fc17 x86_64. The VM has 8GB of ram. Host OS is Windows 7 64bit.

If you look at the mpstat logs included, they are probably the best indicator of how the 3 compare.

I'll definitely be giving this a look.  I will try to dig up the IO status I found from running Instruments on my MBP with the two strategies.


Cassandra had relatively low IO load compared to the other two strategies, but had a much higher overall cpu load. When it ran, it had no troubles writing the data out (totalOperationsPending remained low, in the teens).

JRobinRrdStrategy had a high IO load, and a lower overall cpu load. IO load was significant enough that the totalOperationsPending went all the way up to 37000 before it got near the end and they got flushed out.

I suspect that CPU load stays low here because the IO is so bad the CPU demand is blocked by the IO waits.  Typical system behavior since most of what OpenNMS is doing is not CPU intensive.



JniRrdStrategy had comparable CPU usage to JRobinRrdStrategy, but its IO load dropped off much quicker than JRobin. The totalOperationsPending was comparable to what I saw with CassandraRrdStrategy.

I know that the JNI code was very much higher performant but I was figuring the Cassandra Strategy would be faster yet.  Hmm… Well, perhaps the Cassandra strategy would get faster with more nodes added to the cluster?


I would have to say after running these tests, I will have to look into potentially using JniRrdStrategy on my work OpenNMS system.

This is what we recommend most of the time, now, for this very reason.  I've spent quite a lot of time attempting to figure this one out but have failed… I only know that the JRobin code has an order of magnitude more IO operations called through the kernel and I haven't figured out why or where this is happening.  I do know that the code has not always been this way.  Have you tried using the MNIO backend?


From a disk usage perspective, CassandraRrdStrategy was using about 160MB of storage, where as all the RRDs for both JRobin & RRDtool were using around 8.1GB. I would expect that the CassandraRrdStrategy would balloon up past that if I had records for every period compared to the rrd/jrb files.

Very interesting.



Intersting findings, and things to think about.

Definitely!



I'm not a developer with commit access, so I can't answer the question on when/if this work would be integrated into the main branch.

I see that you have you signed an OpenNMS Contributor's Agreement… we should be able to get you commit access so you can move this code into a branch of master.   Thanks for all the hard work.


David



David Hustace
President, COO
220 Chatham Business Drive
Suite 100
Pittsboro, NC  27312
+1 919 533 0160 x7734


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-devel mailing list

To *unsubscribe* or change your subscription options, see the bottom of this 
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel

Reply via email to