[one-users] 'monitoring' command in 3.6 - sunstone 100% CPU

[Thomas Higdon]

All looks reasonable. It was mostly a case of me not reading up on the
docs for the new release. Thanks for the response.

On Wed, Aug 08, 2012 at 07:18:40AM -0400, Daniel Molina wrote:
> Hi Thomas,
> 
> On 7 August 2012 21:42, Thomas Higdon <thigdon at akamai.com> wrote:
> > I noticed that sunstone was starting to use 100% CPU after awhile on my
> > new 3.6.0 install. It turns out the culprit was the 'monitoring' command
> > that I think sunstone uses to render its graphs is handing back a *lot*
> > of XML, over 3 MB in my case. This is probably a good deal more than
> > it would be a default install because I've got the polling interval
> > cranked to 10s.
> >
> > That amount of XML is too much for the default XML parser to handle, and
> > it apparently pegs the CPU and freezes the application indefinitely.
> > Running
> >
> > gem install xmlrpc-streaming nokogiri
> 
> Actually, this is a common problem experienced by many users, using
> Nokogiri instead of the default REXML parser provides a huge
> performance improvement. In order to avoid this problem, the nokogiri
> gem is installed by default when using the install_gem tool as
> described in the installation guide.
> 
> Also we included in OpenNebula.rb a Nokogiri Stream class
> (https://github.com/OpenNebula/one/blob/master/src/oca/ruby/OpenNebula.rb#L92),
> hence the xmlrpc-streaming gem is not required.
> 
> >
> > causes sunstone to use a faster XML parser, which brings down the
> > execution time to 2-3 secs, which is acceptable(-ish) performance.
> > However, it seems like there should be some means of limitation on the
> > number of records that the 'monitoring' command returns, at least for
> > that instance. It's pegging some python XML parsing code I have, too.
> 
> Currently you can define the following parameters in oned.conf
> 
> #  HOST_MONITORING_EXPIRATION_TIME: Time, in seconds, to expire monitoring
> #  information. Use 0 to disable HOST monitoring recording.
> #
> #  VM_MONITORING_EXPIRATION_TIME: Time, in seconds, to expire monitoring
> #  information. Use 0 to disable VM monitoring recording.
> 
> and
> 
> #  HOST_MONITORING_INTERVAL: Time in seconds between host monitorization.
> #  HOST_PER_INTERVAL: Number of hosts monitored in each interval.
> #
> #  VM_POLLING_INTERVAL: Time in seconds between virtual machine monitorization.
> #  Use 0 to disable VM monitoring.
> #  VM_PER_INTERVAL: Number of VMs monitored in each interval.
> 
> with these parameters you can adjust the number of records that will
> be sent in each request
> 
> >
> > 3.6 looks great otherwise -- thanks for bringing in the qcow2 features!
> 
> I'm glad you like it. Thanks for your feedback
> 
> Cheers
> 
> -- 
> Daniel Molina
> Project Engineer
> OpenNebula - The Open Source Solution for Data Center Virtualization
> www.OpenNebula.org | dmolina at opennebula.org | @OpenNebula