thomasabishop/eolas
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Last Sync: 2022-09-05 13:00:04

Browse source
This commit is contained in:
tactonbishop 2022-09-05 13:00:04 +01:00
parent 75f5ab0637
commit ed3e2aafba
2 changed files with 26 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
Linux/Monitoring_processes_and_resources.md
View file

@ -6,7 +6,9 @@ tags: [sytems-programming]
# Monitoring processes and resources # Monitoring processes and resources
## Processor time and memory usage: `top`, `htop` etc ## General purpose diagnostic programs (memory, CPU, I/O)
### `top`/`htop`
We can use [ps](/Programming_Languages/Shell_Scripting/Processes.md) to list the currently running processes but it does not provide much information about the resource metrics or how the process changes over time. We can use `top` to get more information. We can use [ps](/Programming_Languages/Shell_Scripting/Processes.md) to list the currently running processes but it does not provide much information about the resource metrics or how the process changes over time. We can use `top` to get more information.
@ -50,6 +52,7 @@ _Here I have pressed `u` to show only the processes associated with my user:_
- S for sleeping (idle) - S for sleeping (idle)
- R for running - R for running
- D for disk sleep - D for disk sleep
## Files being used by active processes: `lsof` ## Files being used by active processes: `lsof`
`lsof` stands for _list open files_. It lists opened files and the processes using them. Without modifiers it outputs a huge amount of data. The best way to use it is to execute it against a specific PID. For example the below output gives me some useful info about which files VS Code is using: `lsof` stands for _list open files_. It lists opened files and the processes using them. Without modifiers it outputs a huge amount of data. The best way to use it is to execute it against a specific PID. For example the below output gives me some useful info about which files VS Code is using:
@ -93,7 +96,8 @@ $ getconf PAGE_SIZE
This will typically be the same for all Linux systems. This will typically be the same for all Linux systems.
### `free` : available physical memory ### `free` : available physical memory
`free` displays the total amount of free and¬used physical and swap memory in the system, as well as the [buffers and caches](/Hardware/Memory/Role_in_computation.md#relation-between-cache-and-buffers) used by the kernel.
`free` displays the total amount of free and¬used physical and swap memory in the system, as well as the [buffers and caches](/Hardware/Memory/Role_in_computation.md#relation-between-cache-and-buffers) used by the kernel.
```bash ```bash
$ free $ free
@ -102,12 +106,12 @@ Mem: 16099420 5931512 5039344 2046460 5128564 7781904
Swap: 3145724 0 3145724 Swap: 3145724 0 3145724
``` ```
### `vmstat` : virtual memory statistics ### `vmstat` : virtual memory statistics
Pretty much the same as `free` but in the context of virtual memory. It also distinguishes between buffer and cache. Pretty much the same as `free` but in the context of virtual memory. It also distinguishes between buffer and cache.
The default output is a single line with the averages since boot. You can add a delay parameter (in secs) which will then output at that interval, allowing you to see memory usage in realtime, e.g: The default output is a single line with the averages since boot. You can add a delay parameter (in secs) which will then output at that interval, allowing you to see memory usage in realtime, e.g:
``` ```
$ vmstat 5 $ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
@ -120,17 +124,7 @@ procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
``` ```
* `r` stands for the number of runnable processes - `r` stands for the number of runnable processes
* `b` stands for the number of blocked processes: those waiting for I/O to complete before proceeding. - `b` stands for the number of blocked processes: those waiting for I/O to complete before proceeding.
* `si/so`: the amount of memory swapped in (from disk) and swapped out (to disk) - `si/so`: the amount of memory swapped in (from disk) and swapped out (to disk)
* `bi/ bo`: the amount of blocks received from a device (`bi`), the amoung of blocks sent to a device (`bo`) - `bi/ bo`: the amount of blocks received from a device (`bi`), the amoung of blocks sent to a device (`bo`)
### Page faults
There are two kinds of error that can occur with relation to paged memory:
- minor page faults
- The desired page is in main memory but the MMU doesn't currently know where it is
- major page faults
- The desired page is not in main memory at all. Therefore the kernel must fetch it from disk
Minor page faults are very common and are to be expected; they resolve quickly. On the other hand too many major page faults can slow the system down both because of the time-costly process of fetching data from disk and because it demands more kernel resources to locate the missing page, which puts other processes on hold.

11
Operating_Systems/Virtual_memory_and_the_MMU.md
View file

@ -31,6 +31,17 @@ We use the term **pages** to denote blocks of virtual memory and to distinguish
Virtual memory allows the sharing of files and memory by multiple processes. Crucially the shared data doesn't have to be within the address of each process, instead there is a reference in the page table that each process has access to the shared data. Virtual memory allows the sharing of files and memory by multiple processes. Crucially the shared data doesn't have to be within the address of each process, instead there is a reference in the page table that each process has access to the shared data.
## Page faults
There are two kinds of error that can occur with relation to paged memory:
- minor page faults
- The desired page is in main memory but the MMU doesn't currently know where it is
- major page faults
- The desired page is not in main memory at all. Therefore the kernel must fetch it from disk
Minor page faults are very common and are to be expected; they resolve quickly. On the other hand too many major page faults can slow the system down both because of the time-costly process of fetching data from disk and because it demands more kernel resources to locate the missing page, which puts other processes on hold.
## Resources ## Resources
[Virtual memory](https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/9_VirtualMemory.html#:~:text=Virtual%20memory%20also%20allows%20the,to%20more%20than%20one%20process) [Virtual memory](https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/9_VirtualMemory.html#:~:text=Virtual%20memory%20also%20allows%20the,to%20more%20than%20one%20process)