D3 Tips and Tricks v4

Tuesday, 10 February 2015

Raspberry Pi System Information Measurement: 1. Measure

The following post is a section of the book 'Raspberry Pi: Measure, Record, Explore'.  The entire book can be downloaded in pdf format for free from Leanpub or you can read it online here.
Since this post is a snapshot in time. I recommend that you download a copy of the book which is updated frequently to improve and expand the content.
This is the first of three posts working through a project looking at Measuring Recording and Exploring system information from and with the Raspberry Pi.

System Information Measurement

This project will measure system information that shows how our Raspberry Pi is operating. This is useful information that will allow us to monitor the performance of our computing asset and to identify potential problems before they occur (or to discover the cause of problems when they do).
Specifically we are going to measure, record and display;
  • System load average
  • Memory (Ram) usage
  • Disk usage (on our SD card)
  • Temperature of the Raspberry Pi


Hardware required

Only the Raspberry Pi! All the readings are taken from the Pi itself.

Measured Parameters

System Load
Load average is available in the file /proc/loadavg. We can print the contents of this file using cat;
cat /proc/loadavg
This will produce a line showing five (or maybe six depending on how you look at it) pieces of information that will look a little like the following;
0.14 0.11 0.13 1/196 16991
The first three numbers give the average load for 1 minute (0.14), 5 minutes (0.11) and 15 minutes (0.13) respectively. The next combination of two numbers separated by a slash (1/196) provides two(ish) pieces of information. Firstly, the number before the slash gives the number of threads running at that moment. This should be less than or equal to the CPUs in the system and in the case of the Raspberry Pi this should be less than or equal to 1. The number after the slash indicates the total number of threads in the system. The last number is the process Id (the ‘pid’) of the thread that ran last.
Threads. Like processes are a mechanism to allow a program to do more than one thing at a time. As with processes, threads appear to run concurrently; the Linux kernel schedules them asynchronously, interrupting each thread from time to time to give others a chance to execute. Conceptually, a thread exists within a process. Threads are a finer-grained unit of execution than processes. When you invoke a program, Linux creates a new process and in that process creates a single thread, which runs the program sequentially. That thread can create additional threads; all these threads run the same program in the same process, but each thread may be executing a different part of the program at any given time.
We’re more interested in the system load numbers. Load average is an indication of whether the system resources (mainly the CPU) are adequately available for the processes (system load) that are running, runnable or in uninterruptible sleep states during the previous n minutes. A process is running when it has the full attention of the CPU. A runnable process is a process that is waiting for the CPU. A process is in uninterruptible sleep state when it is waiting for a resource and cannot be interrupted and will return from sleep only when the resource becomes available or a timeout occurs.
For example, a process may be waiting for disk or access to the network. Runnable processes indicate that we need more CPUs. Similarly processes in uninterruptible sleep state indicate Input/Output (I/O) bottlenecks. The load number at any time is the number of running, runnable and uninterruptible sleep state processes (we will call these collectively runnable processes) in the system. The load average is the average of the load number during the previous n minutes.
If, in a single CPU system such as our Raspberry Pi, the load average is 5, it is an undesirable situation because one process runs on the CPU and the other 4 have to wait for their turn. So the system is overloaded by 400%. In the above cat /proc/loadavg command output the load average for the last minute is 0.14, which indicates that the CPU is underloaded by 86%. Load average figures help in figuring out how much our system is able to cater to processing demands.
For our project we will record the value of system load at one of those intervals.
Memory Used
The memory being used by the Raspberry Pi can be determined using the free command. If we type in the command as follows we will see an interesting array of information;
free -m
Produces …
             total       used       free     shared    buffers     cached
Mem:           437        385         51          0         85        197
-/+ buffers/cache:        102        335
Swap:           99          0         99
This is displaying the total amount of free and used physical and swap memory in the system, as well as the buffers used by the kernel. We also used the -m switch at the end of the command to display the information in megabytes.
The row labelled ‘Mem’, displays physical memory utilization, including the amount of memory allocated to buffers and caches.
A buffer, also called buffer memory, is usually defined as a portion of memory that is set aside as a temporary holding place for data that is being sent to or received from an external device, such as a HDD, keyboard, printer or network. Cache is a memory location to store frequently used data for faster access. Cache data can be used multiple times where as buffer memory is used only once. And both are temporary stores for your data processing.
The next line of data, which begins with ‘-/+ buffers/cache’, shows the amount of physical memory currently devoted to system buffer cache. This is particularly meaningful with regards to applications, as all data accessed from files on the system pass through this cache. This cache can greatly speed up access to data by reducing or eliminating the need to read from or write to the SD card.
The last row, which begins with ‘Swap’, shows the total swap space as well as how much of it is currently in use and how much is still available.
For this project we will record the amount of memory used as a percentage of the total available.
Disk Used
It would be a useful metric to know what the status of our available hard drive space was. To determine this we can use the dfcommand. If we use the df command without any arguments as follows;
Produces …
Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs           7513804 2671756   4486552  38% /
/dev/root        7513804 2671756   4486552  38% /
devtmpfs          219744       0    219744   0% /dev
tmpfs              44784     264     44520   1% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs              89560       0     89560   0% /run/shm
/dev/mmcblk0p1     57288    9920     47368  18% /boot
The first column shows the name of the disk partition as it appears in the /dev directory. The following columns show total space, blocks allocated and blocks available. The capacity column indicates the amount used as a percentage of total file system capacity.
The final column shows the mount point of the file system. This is the directory where the file system is mounted within the file system tree. Note that the root partition will always show a mount point of /. Other file systems can be mounted in any directory of a previously mounted file system.
For our purposes the root file system (/dev/root) would be ideal. We can reduce the amount of information that we have to deal with by running the df command and requesting information on a specific area. For example…
df /dev/root
... will produce …
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        7513804 2671756   4486552  38% /
In the project we will use the percentage used of the drive space as our metric.
Raspberry Pi Temperature
The Raspberry Pi includes a temperature sensor in its CPU. The reading can be found by running the command
/opt/vc/bin/vcgencmd measure_temp
Which will produce a nice, human readable output similar to the following;
This value shouldn't be taken as an indication of the ambient temperature of the area surrounding the Pi. Instead it is an indication of the temperature of the chip that contains the CPU. Monitoring this temperature could be useful since there is a maximum temperature at which it can operate reliably. Admittedly that maximum temperature is 85 degrees for the CPU (the BCM2835) and once it hits that figure it reduces the clock to reduce the temperature, but none the less, in some environments it will be a factor.
The post above (and heaps of other stuff) is in the book 'Raspberry Pi: Measure, Record, Explore' that can be downloaded for free (or donate if you really want to :-)).

No comments:

Post a Comment