On Fri, Jan 05, 2007 at 04:59:54PM -0000, [EMAIL PROTECTED] wrote: > Unfortunately it is cygwin itself (and not ganglia) that causes problems > by not imlpementing all the metrics that it should in /proc.
well, for Windows there is no concept of "load average" and therefore the "load_*" metrics are doomed as the system doesn't implement an equivalent function call to getloadavg() (standard for LSB and BSD) or keep track of some nice standard exponentially decaying load function. one could be written either in cygwin or by using the CPU values from the other metrics and with a similar logic to the one being used by either Linux, Solaris or anyone of the BSD but will never be a windows load average. > So the cygwin things wrong include: > > Not implemented: load_one, load_five, load_15, proc_run, > proc_total. all this rely on /proc/loadavg support which is incomplete for cygwin, but the proc_* metrics could be fixed easily for cygwin (still only showing processes from the point of view of cygwin) > Partially implemented: memory metrics (e.g. mem_free), and memory > metrics > do not report total memory correctly above 2.5 > gig or so. I think this is a limitation to the per process memory from windows, as it is seen by cygwin, indeed, I am surprised you can actually see that much memory as the default in cygwin should be shorter than that, but if you have a windows system with that much memory this will be an interesting thing to do : http://cygwin.com/cygwin-ug-net/setup-maxmem.html if possible also run the following from a cygwin shell : $ uname -a && echo && cat /proc/meminfo > Broken I think: disk space metrics. this ones were just missing the implementation, and will be most likely available in 3.0.5 > A native windows agent may be available from a company in switzerland. > I can supply a contact if you like. do you know if it is using WMI? that is the approach I was targeting for my own native port to windows. Carlo
