 |
 |
Hi Adrian, Yes, that memory load calculation is good enough. You just want to get a sense of how stressed the system is. Andy -----Original Message----- From: Adrian Sevcenco Sent: Tuesday, June 18, 2019 2:48 PM To: Andrew Hanushevsky ; [log in to unmask] Cc: Oliver Freyermuth Subject: Re: cms.perf script - how to contribute On 6/19/19 12:03 AM, Andrew Hanushevsky wrote: > Hi Adrian, > > -----Original Message----- From: Adrian Sevcenco > Sent: Tuesday, June 18, 2019 9:35 AM > To: [log in to unmask] > Subject: cms.perf script - how to contribute > > Hi! With the help of Oliver Freyermuth i rewrote the script > /usr/share/xrootd/utils/XrdOlbMonPerf > which in documentation is referenced as cms_MonPerf > http://xrootd.org/doc/dev410/cms_config.htm#_Toc8247264 > > in the form that can be seen here: > https://github.com/adriansev/bin-scripts/blob/master/cms_monPerf > > w.r.t to old script i would have some questions : > 1. what would be the proper name to have > +++So, cms_MonPerf is your preferred name. That's fine. I will simply stop > documenting the old name. actually in documentation the name is cms_MonPerf :) this is why i asked what name should have :) > 2. i seen that both cms.perf and the script have some timing arguments > moreover the ols script is supposed to run in the loop ... > what is the relation between cms.pref int parameter and the "interval" > argument that the script is supposed to have? > +++Yes, the script needs to run in a loop and produce output at the > frequency you specify as a parameter to the script. The int parameter is > simply the estimated time between the program reporting something. The > "int" value should be somewhat larger that the actual reporting time that > you would specify as a parameter to the script. The reason is that the > server uses the int value to determine if the reporting program is dead > (i.e. not reporting) and needs to be restarted. Yes, I agree, none of that > is explained in the doc. ok, i see .. the default is 1s and then the script takes 1s for cpu util determination and 1s for each valid network interface for each have to measure the instantaneous bandwidth > 3. is it really relevant for memory load to take into account the > buffers and cache? > +++No, not at all. I don't even think Linux takes that into account. the linux kernel fills as much is possible the not commited memory with buffers and cache and then if the pressure from to allocator increase, it release the buffers and caches so, it would be ok to change to compute the memory load based only on: (MemTotal - MemAvailable)*100/MemTotal ? http://man7.org/linux/man-pages/man5/proc.5.html /proc/meminfo > i assumed that : > 1. -m <shmkey> option is something too old to be cared about > +++Correct. Forget about it. great > 2. -n netspeed have no meaning because either it is know directly > or, for virtio interfaces, even the human admin cannot determine it > (so for virtio interfaces the net load will be always 0) > As a generic network load measurement, packets per second averaged over > the reporting interval (which can be computed) is a good indicator of how > busy the interface is. I'd suggest simply doing that. "the rules" of the script says that the value should be normalized to some 100% ... with packets i cannot do this because : 1. they have variable size; 2. i have no speed in pkt/s for the network interface > 3. -I netintf this was also skipped as the net load will be taken as the > maximum of all physical up interfaces, with the assumption that on the > xrootd data server at least 1 interface is dedicated to xrootd server > and that is the most utilized. > +++Probably good enough here for the general cose. ok > the script make use only of awk and assumes linux. > +++That's fine. At least it will work virtually all Linux distros. Thanks > a heap -- both of you! > > As for getting it into the repo, simply create a pull request and I will > merge it in. great! Thanks a lot! Adrian ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1