This shows you the differences between two versions of the page.
|
ep:labs:05:contents:tasks:ex2 [2025/02/11 23:43] cezar.craciunoiu created |
ep:labs:05:contents:tasks:ex2 [2026/03/30 22:16] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 02. [30p] iostat & iotop ==== | + | ==== 02. [20p] RAM disk ==== |
| - | === [15p] Task A - Monitoring the behaviour with Iostat === | + | Linux allows you to use part of your RAM as a block device, viewing it as a hard disk partition. The advantage of using a RAM disk is the **extremely low latency** (even when compared to SSDs). The disadvantage is that all contents will be lost after a reboot. |
| <note tip> | <note tip> | ||
| - | Parameteres for iostat: | + | There are two main types of RAM disks: |
| - | * -x for extended statistics | + | * **ramfs** - cannot be limited in size and will continue to grow until you run out of RAM. Its size can not be determined precisely with tools like **df**. Instead, you have to estimate it by looking at the "cached" entry from **free**'s output. |
| - | * -d to display device stastistics only | + | * **tmpfs** - newer than **ramfs**. Can set a size limit. Behaves exactly like a hard disk partition but can't be monitored through conventional means (i.e. **iostat**). Size can be precisely estimated using **df**. |
| - | * -m for displaying r/w in MB/s | + | |
| - | <code bash> | + | |
| - | $ iostat -xdm | + | |
| - | </code> | + | |
| - | Use iostat with -p for specific device statistics: | + | |
| - | <code bash> | + | |
| - | $ iostat -xdm -p sda | + | |
| - | </code> | + | |
| </note> | </note> | ||
| + | === [10p] Task A - Create RAM Disk === | ||
| - | * Run //iostat -x 1 5//. | + | Before getting started, let's find out the file system that our root partition uses. Run the following command (T - print file system type, h - human readable): |
| - | * Considering the last two outputs provided by the previous command, calculate **the efficiency of IOPS** for each of them. Does the amount of data written per I/O **increase** or **decrease**? | + | |
| - | + | ||
| - | Add in your archive screenshot or pictures of the operations and the result you obtained, also showing the output of iostat from which you took the values. | + | |
| - | + | ||
| - | <note> | + | |
| - | How to do: | + | |
| - | + | ||
| - | * Divide the kilobytes read (//rkB/s//) and written (//wkB/s//) per second by the reads per second (//r/s//) and the writes per second (//w/s//). | + | |
| - | * If you happen to have quite a few [[https://en.wikipedia.org/wiki/Loop_device|loop devices]] in your **iostat** output, find out what they are exactly: | + | |
| <code bash> | <code bash> | ||
| - | $ df -kh /dev/loop* | + | $ df -Th |
| </code> | </code> | ||
| - | </note> | + | The result should look like this: |
| - | + | ||
| - | + | ||
| - | <solution -hidden> | + | |
| - | The way to calculate the efficiency of IOPS is to divide the reads per second //(r/s)// and writes per second //(w/s)// by the kilobytes read //(rkB/s)// and written //(wkB/s)// per second. | + | |
| - | + | ||
| - | Example: the amount of data written per I/O for ///dev/sda// increases during each iteration: | + | |
| - | + | ||
| - | {{ :ep:labs:ep2017_l3_ex01.png?700 |}} | + | |
| <code> | <code> | ||
| - | 53040/105 = 505KB per I/O | + | Filesystem Type Size Used Avail Use% Mounted on |
| - | 71152/102 = 697KB per I/O | + | udev devtmpfs 1.1G 0 1.1G 0% /dev |
| + | tmpfs tmpfs 214M 3.8M 210M 2% /run | ||
| + | /dev/sda1 ext4 218G 4.1G 202G 2% / <- root partition | ||
| + | tmpfs tmpfs 1.1G 252K 1.1G 1% /dev/shm | ||
| + | tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock | ||
| + | tmpfs tmpfs 1.1G 0 1.1G 0% /sys/fs/cgroup | ||
| + | /dev/sda2 ext4 923M 73M 787M 9% /boot | ||
| + | /dev/sda4 ext4 266G 62M 253G 1% /home | ||
| </code> | </code> | ||
| - | If everything is zero in iostat - perform some I/O operations... | + | From the results, we will assume in the following commands that the file system is **ext4**. If it's not your case, just replace with what you have: |
| - | </solution> | + | |
| + | <code bash> | ||
| + | $ sudo mkdir /mnt/ramdisk | ||
| + | $ sudo mount -t tmpfs -o size=1G ext4 /mnt/ramdisk | ||
| + | </code> | ||
| - | === [15p] Task B - Monitoring the behaviour with Iotop === | + | <note> |
| - | <note tip> | + | If you want the RAM disk to persist after a reboot, you can add the following line to ///etc/fstab//. Remember that its contents will still be lost. |
| - | **Iotop** is an utility similar to top command, that interfaces with the kernel to provide per-thread/process I/O usage statistics. | + | |
| <code> | <code> | ||
| - | Debian/Ubuntu Linux install iotop | + | tmpfs /mnt/ramdisk tmpfs rw,nodev,nosuid,size=1G 0 0 |
| - | $ sudo apt-get install iotop | + | |
| - | + | ||
| - | How to use iotop command | + | |
| - | $ sudo iotop OR $ iotop | + | |
| </code> | </code> | ||
| - | |||
| - | Supported options by iotop command: | ||
| - | |||
| - | | **Options** | **Description** ^^ | ||
| - | | --version | show program’s version number and exit || | ||
| - | | -h, --help | show this help message and exit || | ||
| - | | -o, --only | only show processes or threads actually doing I/O || | ||
| - | | -b, --batch | non-interactive mode || | ||
| - | | -n NUM, --iter=NUM | number of iterations before ending [infinite] || | ||
| - | | -d SEC, --delay=SEC | delay between iterations [1 second] || | ||
| - | | -p PID, --pid=PID | processes/threads to monitor [all] || | ||
| - | | -u USER, --user=USER | users to monitor [all] || | ||
| - | | -P, --processes | only show processes, not all threads || | ||
| - | | -a, --accumulated | show accumulated I/O instead of bandwidth || | ||
| - | | -k, --kilobytes | use kilobytes instead of a human friendly unit || | ||
| - | | -t, --time | add a timestamp on each line (implies –batch) || | ||
| - | | -q, --quiet | suppress some lines of header (implies –batch) || | ||
| </note> | </note> | ||
| + | That's it. We just created a 1Gb **tmpfs** ramdisk with an **ext4** file system and mounted it at ///mnt/ramdisk//. Use **df** again to check this yourself. | ||
| - | * Run iotop (install it if you do not already have it) in a separate shell showing only processes or threads actually doing I/O. | + | === [10p] Task B - Pipe View & RAM Disk === |
| - | * Inspect the script code ({{:ep:laboratoare:dummy.sh|dummy.sh}}) to see what it does. | + | |
| - | * Monitor the behaviour of the system with iotop while running the script. | + | |
| - | * Identify the PID and PPID of the process running the dummy script and kill the process using command line from another shell (sending SIGINT signal to both parent & child processes). | + | |
| - | * Hint - [[https://superuser.com/questions/150117/how-to-get-parent-pid-of-a-given-process-in-gnu-linux-from-command-line|How to get parent PID of a given process in GNU/Linux from command line?]] | + | |
| - | Provide a screenshot in which it shows the iotop with only the active processes and one of them being the running script. Then another screenshot after you succeeded to kill it. | + | As we mentioned before, you can't get I/O statistics regarding **tmpfs** since it is not a real partition. One solution to this problem is using **pv** to monitor the progress of data transfer through a pipe. This is a valid approach only if we consider the disk I/O being the bottleneck. |
| - | <solution -hidden> | + | Next, we will generate 512Mb of random data and place it in ///mnt/ramdisk/file// first and then in ///home/student/file//. The transfer is done using **dd** with 2048-byte blocks. |
| - | {{:ep:laboratoare:lab3-ex4.png?600}} | + | |
| - | **dd** performs disk writes... wow! Reason why there are no disk reads is because it uses pseudo-files from **devtmpfs** that don't record these statistics. Also, **tmpfs** are not disks :p | + | <code bash> |
| + | $ pv /dev/urandom | dd of=/mnt/ramdisk/rand bs=2048 count=$((512 * 1024 * 1024 / 2048)) | ||
| + | $ pv /dev/urandom | dd of=/home/student/rand bs=2048 count=$((512 * 1024 * 1024 / 2048)) | ||
| + | </code> | ||
| - | Find PPID from PID: ps -o ppid= -p PID | + | Look at the elapsed time and average transfer speed. What conclusion can you draw? |
| - | Send SIGINT signal: kill -SIGINT PID,PPID | + | |
| - | </solution> | + | |