Re: timer ticks in /proc/stat - more differences between SLES and RHEL?
The differences you're seeing ... some are lag-time as changes get rolled into the kernel and utilities, but others may be variances from a standard. (or lag-time in keeping up with the standard) Standard ... is there? Why ... yes, there is! "The Linux Standard Base was created to lower the overall costs of supporting the Linux platform. By reducing the differences between individual Linux distributions, the LSB greatly reduces the costs involved with porting applications to different distributions, as well as lowers the cost and effort involved in after-market support of those applications." http://www.linuxfoundation.org/collaborate/workgroups/lsb And it appears that IBM, SuSE, and RedHat are all supporting members of the LF. -- R; <>< On Fri, May 17, 2013 at 1:23 PM, Michael MacIsaac wrote: > James, Emmett, > > Thanks for the replies. Good to know that an older and a new RHEL seem to > come up with the right answer (I assume you both have 2 vCPUs). > > Just to be sure, I tried again on my reference system, and got similar > results: > > # cat /etc/redhat-release >Red Hat Enterprise Linux Server release 6.3 (Santiago) > # ./getticks > getting one set of data > sleeping 5 seconds and getting another set of data > statOut1 = cpu 13191 57057 57033 4 0 2781 3194 3158 0 > statOut2 = cpu 13191 57057 57033 4 0 2781 3194 3158 0 > nums1 = 13191+57057+57033+4+0+2781+3194+3158+0 > nums2 = 13191+57057+57033+4+0+2781+3194+3158+0 > totalTicks = 0 > > > "Mike MacIsaac" > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- -- R; <>< -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: timer ticks in /proc/stat - more differences between SLES and RHEL?
Hello list, Aha moment - a while back I reported that "vmstat 1 2" was core dumping on RHEL 6.3. I got a reply this is a known issue and that there is a fix. This must be the same issue (without a proper tick count, the code might be trying to divide by 0). Another mystery solved. I think it's time to move to RHEL 6.4 ... Thanks again for all quick replies. "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Amount of memory in buffers shown by the free command
Mark, Thanks for the reply. So, it would seem "more correct" to add in the other two components. Interesting ... I guess that explains why on one system I'm looking at apples and on the other at oranges :)) "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: timer ticks in /proc/stat - more differences between SLES and RHEL?
James, Emmett, Thanks for the replies. Good to know that an older and a new RHEL seem to come up with the right answer (I assume you both have 2 vCPUs). Just to be sure, I tried again on my reference system, and got similar results: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.3 (Santiago) # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 13191 57057 57033 4 0 2781 3194 3158 0 statOut2 = cpu 13191 57057 57033 4 0 2781 3194 3158 0 nums1 = 13191+57057+57033+4+0+2781+3194+3158+0 nums2 = 13191+57057+57033+4+0+2781+3194+3158+0 totalTicks = 0 "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Only 10 business days left! Registration closes at 23:59, May 31 for the 2013 VM Workshop in Indianapolis.
Cross-posted to the IBMVM, Linux-390, and IBM-MAIN discussion lists. The registration deadline is set hard and fast as the end of day May 31, 2013 due to Indiana University - Purdue University Indianapolis (IUPUI) deadlines. Don't delay (besides, the two 2-part Hands-on Labs are expected to reach their maximum capacity of 30 each rather quickly). Why attend? Well... * the 2013 VM Workshop registration fee is only $100, and * BRAND NEW double occupancy dorm rooms can be reserved as a 3-night package for $150 (with additional nights at $50 each), and * reduced rate Parking passes are available for $20 (a $10 discount), and * a lavish Thursday evening reception and dinner is included, and * a $65 IUPUI debit card for meals in the Campus Center is included, and * excellent technical sessions and the same IBM-provided Hands-on Labs presented at the bigger conferences, and * the famous VM Workshop Ugly Hawaiian Shirt Contest is included (BYOUHS), and * famous and infamous speakers delivering up-to-date technical sessions on z/VM and Linux on System z topics all centrally located on the IUPUI campus in downtown Indianapolis, Indiana. All 37 session slots are now 100% full. There have been rumors of a few late sessions, so some of those below might be replaced by newer sessions of more general appeal, and/or... session times adjusted. You may view each speaker's full session descriptions by visiting the current session agenda and schedule at: http://www.vmworkshop.org/2013/agenda To learn more about the 2013 VM Workshop, visit: http://www.vmworkshop.org/2013 You can review all public information at that URL, but to register you'll first need to request a VM Workshop ID (used only to minimize spambot attacks on the web site). Once you have been manually granted an ID by an admin, you may register for, and pay for (via Paypal) your purchases. Note: There are only 15 IBM-provided Hands-on lab laptops at each of the non-concurrent 'z/VM Install & Config', and 'Linux on System z Install & Config' labs. Once you have received a workshop ID, you may reserve a seat at one and/or the other labs (maximum attendee reservations for each lab = 30). Best regards, Mike Walter On behalf of the 2013 VM Workshop Volunteer Committee -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: timer ticks in /proc/stat - more differences between SLES and RHEL?
RHEL 6.4 cat /etc/redhat-release;./getticks.sh Red Hat Enterprise Linux Server release 6.4 (Santiago) getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 31860 18874 14917 835252 84240 869 1430 8480 0 statOut2 = cpu 31869 18874 14924 836234 84242 869 1430 8481 0 nums1 = 31860+18874+14917+835252+84240+869+1430+8480+0 nums2 = 31869+18874+14924+836234+84242+869+1430+8481+0 totalTicks = 1001 -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of CHAPLIN, JAMES (CTR) Sent: Friday, May 17, 2013 10:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: timer ticks in /proc/stat - more differences between SLES and RHEL? Interesting because when I ran the same script on a RHEL 5.9 guest (w/ 2 vCPUs), we get: ./gettricks.sh getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 60259 128520 96523 256447792 415684 8000 15453 134955 statOut2 = cpu 60259 128520 96524 256448793 415686 8000 15453 134955 nums1 = 60259+128520+96523+256447792+415684+8000+15453+134955 nums2 = 60259+128520+96524+256448793+415686+8000+15453+134955 totalTicks = 1004 Do not have a RHEL 6.3 system to compare with :-(. James Chaplin Systems Programmer, MVS, zVM & zLinux Base Technologies, a CA Technologies Company Supporting the zSeries Platform Team -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael MacIsaac Sent: Friday, May 17, 2013 10:30 AM To: LINUX-390@VM.MARIST.EDU Subject: timer ticks in /proc/stat - more differences between SLES and RHEL? I'm hacking around with CPU utilization numbers from /proc/stat with this little script: # cat getticks #!/bin/bash echo "getting one set of data" statOut1=`egrep '^cpu ' /proc/stat` echo "sleeping 5 seconds and getting another set of data" sleep 5 statOut2=`egrep '^cpu ' /proc/stat` nums1=`echo "$statOut1" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum1=$nums1 nums2=`echo "$statOut2" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum2=$nums2 let totalTicks=$sum2-$sum1 echo "statOut1 = $statOut1" echo "statOut2 = $statOut2" echo "nums1 = $nums1" echo "nums2 = $nums2" echo "totalTicks = $totalTicks" On a SLES 11 SP2 system, with 5 vCPUs, I get the expected output: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 251 8 170 857508 145 2 7 32 0 0 statOut2 = cpu 251 8 170 860009 145 2 7 32 0 0 nums1 = 251+8+170+857508+145+2+7+32+0+0 nums2 = 251+8+170+860009+145+2+7+32+0+0 totalTicks = 2501 2501 ~= 5 seconds * 5 CPUs * 100 ticks/sec On a RHEL 6.3 system (2 vCPUs), I get a *slightly* different number: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 13059 57057 56528 4 0 2740 3152 3130 0 statOut2 = cpu 13059 57057 56529 4 0 2740 3152 3130 0 nums1 = 13059+57057+56528+4+0+2740+3152+3130+0 nums2 = 13059+57057+56529+4+0+2740+3152+3130+0 totalTicks = 1 HUH? Does RHEL not count ticks in /proc/stat? Any help will be appreciated. "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: timer ticks in /proc/stat - more differences between SLES and RHEL?
Interesting because when I ran the same script on a RHEL 5.9 guest (w/ 2 vCPUs), we get: ./gettricks.sh getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 60259 128520 96523 256447792 415684 8000 15453 134955 statOut2 = cpu 60259 128520 96524 256448793 415686 8000 15453 134955 nums1 = 60259+128520+96523+256447792+415684+8000+15453+134955 nums2 = 60259+128520+96524+256448793+415686+8000+15453+134955 totalTicks = 1004 Do not have a RHEL 6.3 system to compare with :-(. James Chaplin Systems Programmer, MVS, zVM & zLinux Base Technologies, a CA Technologies Company Supporting the zSeries Platform Team -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael MacIsaac Sent: Friday, May 17, 2013 10:30 AM To: LINUX-390@VM.MARIST.EDU Subject: timer ticks in /proc/stat - more differences between SLES and RHEL? I'm hacking around with CPU utilization numbers from /proc/stat with this little script: # cat getticks #!/bin/bash echo "getting one set of data" statOut1=`egrep '^cpu ' /proc/stat` echo "sleeping 5 seconds and getting another set of data" sleep 5 statOut2=`egrep '^cpu ' /proc/stat` nums1=`echo "$statOut1" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum1=$nums1 nums2=`echo "$statOut2" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum2=$nums2 let totalTicks=$sum2-$sum1 echo "statOut1 = $statOut1" echo "statOut2 = $statOut2" echo "nums1 = $nums1" echo "nums2 = $nums2" echo "totalTicks = $totalTicks" On a SLES 11 SP2 system, with 5 vCPUs, I get the expected output: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 251 8 170 857508 145 2 7 32 0 0 statOut2 = cpu 251 8 170 860009 145 2 7 32 0 0 nums1 = 251+8+170+857508+145+2+7+32+0+0 nums2 = 251+8+170+860009+145+2+7+32+0+0 totalTicks = 2501 2501 ~= 5 seconds * 5 CPUs * 100 ticks/sec On a RHEL 6.3 system (2 vCPUs), I get a *slightly* different number: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 13059 57057 56528 4 0 2740 3152 3130 0 statOut2 = cpu 13059 57057 56529 4 0 2740 3152 3130 0 nums1 = 13059+57057+56528+4+0+2740+3152+3130+0 nums2 = 13059+57057+56529+4+0+2740+3152+3130+0 totalTicks = 1 HUH? Does RHEL not count ticks in /proc/stat? Any help will be appreciated. "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Amount of memory in buffers shown by the free command
>>> On 5/17/2013 at 08:15 AM, Rob van der Heij wrote: > That explains why it's not in RHEL since it is not part of the upstream > procps sources. The changelog entry has an innocent description like below. > > * Thu Nov 17 2011 wer...@suse.de > - Change order of parsing /proc/meminfo to make sure that > "Slab" and "SwapCached" fields are found (bnc#696351) > > I don't think this is a wise change, and I'm surprised a distributor would > do things like that. I can see that you might want to add swap cache if you > need to have a single number, but there's more value in having this > consistent in the distributions. The actual change came much earlier: Thu Jul 10 18:24:14 CEST 2008 - wer...@suse.de - Annoying change in /proc/meminfo makes info about free memory useless ... thanks Bart Van Assche for spotting (bnc#405246) Looking at the bug report, there was quite a bit of discussion about the change, and how older versions (or other distribution's versions) would report different values. In the end, it boiled down to the upstream maintainer not doing much actual maintaining, and the old behavior being considered by everyone to be wrong. Some people weren't happy about the change in behavior, but the SUSE developer at the time decided he'd rather have correct information that was inconsistent with older versions, than incorrect information that was consistent with older versions. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
timer ticks in /proc/stat - more differences between SLES and RHEL?
I'm hacking around with CPU utilization numbers from /proc/stat with this little script: # cat getticks #!/bin/bash echo "getting one set of data" statOut1=`egrep '^cpu ' /proc/stat` echo "sleeping 5 seconds and getting another set of data" sleep 5 statOut2=`egrep '^cpu ' /proc/stat` nums1=`echo "$statOut1" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum1=$nums1 nums2=`echo "$statOut2" | grep ^cpu | sed -e 's/cpu\s*//g' -e 's/ /+/g'` let sum2=$nums2 let totalTicks=$sum2-$sum1 echo "statOut1 = $statOut1" echo "statOut2 = $statOut2" echo "nums1 = $nums1" echo "nums2 = $nums2" echo "totalTicks = $totalTicks" On a SLES 11 SP2 system, with 5 vCPUs, I get the expected output: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 251 8 170 857508 145 2 7 32 0 0 statOut2 = cpu 251 8 170 860009 145 2 7 32 0 0 nums1 = 251+8+170+857508+145+2+7+32+0+0 nums2 = 251+8+170+860009+145+2+7+32+0+0 totalTicks = 2501 2501 ~= 5 seconds * 5 CPUs * 100 ticks/sec On a RHEL 6.3 system (2 vCPUs), I get a *slightly* different number: # ./getticks getting one set of data sleeping 5 seconds and getting another set of data statOut1 = cpu 13059 57057 56528 4 0 2740 3152 3130 0 statOut2 = cpu 13059 57057 56529 4 0 2740 3152 3130 0 nums1 = 13059+57057+56528+4+0+2740+3152+3130+0 nums2 = 13059+57057+56529+4+0+2740+3152+3130+0 totalTicks = 1 HUH? Does RHEL not count ticks in /proc/stat? Any help will be appreciated. "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Amount of memory in buffers shown by the free command
It's Friday, but I still don't feel like installing all the dependencies to build the procps package... I believe the smoking gun is on my desk already: procps-3.2.7-slab.patch (part of the SUSE add-ons to procps) says @@ -603,6 +615,7 @@ } kb_swap_used = kb_swap_total - kb_swap_free; kb_main_used = kb_main_total - kb_main_free; + kb_main_cached += kb_slab_reclaimable + kb_swap_cached + kb_nfs_unstable; } That explains why it's not in RHEL since it is not part of the upstream procps sources. The changelog entry has an innocent description like below. * Thu Nov 17 2011 wer...@suse.de - Change order of parsing /proc/meminfo to make sure that "Slab" and "SwapCached" fields are found (bnc#696351) I don't think this is a wise change, and I'm surprised a distributor would do things like that. I can see that you might want to add swap cache if you need to have a single number, but there's more value in having this consistent in the distributions. Rob On 17 May 2013 12:57, Michael MacIsaac wrote: > Alex, > > > That is not what I see at my end. > Wait, what? > > You have two RHELs and they agree with my RHEL - the value for "Cached" in > /proc/meminfo is also shown in "free". It's SLES's "free" that seems to > add the "Cached" and "SReclaimable" values (and as Rob points out, > possibly also "SwapCached"). > > "Mike MacIsaac" > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Amount of memory in buffers shown by the free command
Alex, > That is not what I see at my end. Wait, what? You have two RHELs and they agree with my RHEL - the value for "Cached" in /proc/meminfo is also shown in "free". It's SLES's "free" that seems to add the "Cached" and "SReclaimable" values (and as Rob points out, possibly also "SwapCached"). "Mike MacIsaac" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Amount of memory in buffers shown by the free command
On 17 May 2013 01:55, Suthammanont, Alex C < alex.suthamman...@bankofamerica.com> wrote: > Mike & Rob, > That is not what I see at my end. Below are sample of RHEL 5.9 and RHEL > 6.3. > In both cases, the number of cached from the 'free' command matches to the > number of cached found in /proc/meminfo. Strange but true.. You did not show the "SwapCached:" entry from /proc/meminfo in your output. If that is 0, I could still be correct to expect that "free" shows us the sum of Cached and SwapCached. I don't see what Mike's slab reclaimable would have to do with this, unless some ambitious soul tried to stuff 3 numbers into one and hoped to do us a favor. After all, some look at the 2nd line in "free" for what they could available when it has to be, so by sneaking other numbers into the "cached" value you find that "free" will include that into the "+/-" cache numbers. Wish even more I had the time to investigate. From earlier experiments in http://zvmperf.wordpress.com/2013/01/31/the-nocache-approach/ I still have tools that tell me *which* files are in cache, so we should be able to get the picture right... Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
