I have figured out the ioacct weirdness. the beancounter files do not always recreate. If a vm is rebooted from inside it does not recreate bc info. If the vm is restarted the bc info is not always recreated. Which is why my "uptime/io" was so out of wack at times. The only way I could come up with a correct uptime of the VM is to:
> stat /proc/vz/beancounter/$veid | grep Modify | cut -d" " -f2 I just choose the modify all three of the dates stay the same since everything is recreated new. I also converted everything to epoch time for easier subtraction numbers. Just figured I would share incase others were trying to find out who is chewing up their ssd's. On 07/21, Kir Kolyshkin wrote: > Just one thing -- ioacct accounts on a VFS level, not on actual disk I/O > level. > Also, ioacct accounts all reads and writes, including tmpfs and /proc and > /sys etc. > > Say, if you rewrite a file (a real file on disk) a thousand times real > quick, it does not > mean the data will be written to a disk a thousand times -- more probably > just once. > > Maybe you want to look into iostat rather than ioacct? > > https://openvz.org/IO_statistics > > > On 07/21/2015 12:39 PM, Mark Johanson wrote: > >So as it was explained to me before, the vm specific ioacct file resets when > >the vm is restarted. Which seemed to work and make sence until today. I have > >a vm that according to that file has made 403G of writes since it was > >restarted yesterday. > > > >(1 day) VE WWWW 403 GB in average daily writes and 403 GB in total since it > >was last rebooted > >(51 days) VE XXXX 9 GB in average daily writes and 487 GB in total since it > >was last rebooted > >(11 days) VE YYYY 5 GB in average daily writes and 60 GB in total since it > >was last rebooted > >(51 days) VE ZZZZ 2 GB in average daily writes and 132 GB in total since it > >was last rebooted > > > >*above day listings are from me just checking on their uptimes. > > > >My Script runs as: > > > >for veid in `vzlist -Hoveid`; do #run in all running vms > > a=`vzctl exec $veid uptime | awk '{print $3}'` #grab uptime from vm > > b=`grep write /proc/bc/$veid/ioacct | awk '{print $2}'` #grab write > > information from ioacct file for vm > > c=`echo "$b/$a" | bc` #divide writes by days up > > d=`echo "$c/1073741824" | bc` #daily writes in GB > > e=`echo "$b/1073741824" | bc` #total wirtes since uptime in GB > > echo "VE $veid $d GB in average daily writes and $e GB in total since it > > was last rebooted" #spit out results per vm > >done > > > >The ioacct file for this vm contains: > > > > read 121361661952 > > write 433471070208 > > dirty 2439431475200 > > cancel 2005960404992 > > missed 0 > > syncs_total 5 > > fsyncs_total 179645 > > fdatasyncs_total 48312 > > range_syncs_total 0 > > syncs_active 0 > > fsyncs_active 0 > > fdatasyncs_active 0 > > range_syncs_active 0 > > io_pbs 0 > > fuse_requests 0 > > fuse_bytes 0 > > So based on the write numbers (I do understand that dirty is unwritten > > and canceled is data not written during a flush) it comes out to 403G in > > writes since its reboot Mon Jul 20 08:46. > > Am I completely off on my math? Seemed to be working just fine until this > > vm spit out a 403G number. Am I missing something else? > >_______________________________________________ > >Users mailing list > >Users@openvz.org > >https://lists.openvz.org/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users