Differences
This shows you the differences between two versions of the page.
|
ep:labs:01:contents:tasks:ex1 [2021/10/11 13:13] radu.mantu [01. [20p] Vmstat] |
ep:labs:01:contents:tasks:ex1 [2026/03/03 10:54] (current) emilian.radoi [Google Colab Notebook] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 01. [20p] Vmstat ==== | + | ==== Google Colab Notebook ==== |
| - | The **vmstat** utility provides a good low-overhead view of system performance. Since **vmstat** is such a low-overhead tool, it is practical to have it running even on heavily loaded servers when it is needed to monitor the system’s health. | + | |
| - | === [5p] Task A - Monitoring stress === | ||
| - | Run **vmstat** on your machine with a 1 second delay between updates. Notice the CPU utilisation (info about the output columns [[https://medium.com/@damianmyerscough/vmstat-explained-83b3e87493b3|here]]). | ||
| - | In another terminal, use the **stress** command to start N CPU workers, where N is the number of cores on your system. | + | For this lab, we will use Google Colab for exploring numpy and matplotlib. Please solve your tasks [[https://github.com/cosmaadrian/ml-environment/blob/master/EP_Plotting_I.ipynb|here]] by clicking "**Open in Colaboratory**". |
| - | Do not pass the number directly. In stead, use command substitution. | + | |
| - | <solution -hidden> | + | ==== [10p] Feedback ==== |
| - | **Task A:**\\ | + | |
| - | <code bash> | + | |
| - | $ vmstat -w -n 1 | + | |
| - | $ stress -c $(nproc) | + | |
| - | </code> | + | |
| - | </solution> | + | |
| - | === [5p] Task B - How does it work? === | + | Please take a minute to fill in the **[[https://forms.gle/moWQFAfMMmNmA2Q17 | feedback form]]** for this lab. |
| - | Let us look at how **vmstat** works under the hood. We can assume that all these statistics (memory, swap, etc.) can not be normally gathered in userspace. So how does **vmstat** get these values from the kernel? Or rather, how does any process interact with the kernel? Most obvious answer: //**system calls**//. | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ strace vmstat | + | |
| - | </code> | + | |
| - | + | ||
| - | //"All well and good. But what am I looking at?"// | + | |
| - | + | ||
| - | What you //should// be looking at are the system calls after the two **write**s that display the output header (hint: it has to do with **/proc/** file system). So, what are these files that **vmstat** opens? | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ file /proc/meminfo | + | |
| - | $ cat /proc/meminfo | + | |
| - | + | ||
| - | $ man 5 proc | + | |
| - | </code> | + | |
| - | + | ||
| - | The manual should contain enough information about what these kernel interfaces can provide. However, if you are interested in //how// the kernel generates the statistics in **/proc/meminfo** (for example), a good place to start would be [[https://elixir.bootlin.com/linux/v4.15/source/fs/proc/meminfo.c|meminfo.c]] (but first, [[https://ocw.cs.pub.ro/courses/so2|SO2 wiki]]). | + | |
| - | + | ||
| - | === [10p] Task C - USO flashbacks (1) === | + | |
| - | + | ||
| - | Write a one-liner that uses **vmstat** to report complete **disk statistics** and sort the output in **descending** order based on **total reads** column. \\ | + | |
| - | Include both the bash command and the output in your submission. | + | |
| - | + | ||
| - | <solution -hidden> | + | |
| - | <code bash> | + | |
| - | $ vmstat -wdn | tail -n +3 | sort -nrk 2 | + | |
| - | </code> | + | |
| - | </solution> | + | |
