diff options
author | thiagoftsm <thiagoftsm@gmail.com> | 2022-03-18 22:22:50 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-03-18 22:22:50 +0000 |
commit | f8b22ce560922133b13ea2d655dc80d10e95fffc (patch) | |
tree | e9a9d77762cb3cee9234f009ed35f3136e002f4a /collectors | |
parent | 300575a1680b1fab2f294bb231f5ae2ab8e1e7f5 (diff) |
Add content for eBPF documentation (#12417)
Diffstat (limited to 'collectors')
-rw-r--r-- | collectors/ebpf.plugin/README.md | 25 |
1 files changed, 20 insertions, 5 deletions
diff --git a/collectors/ebpf.plugin/README.md b/collectors/ebpf.plugin/README.md index e0b74a575a..0f943416c6 100644 --- a/collectors/ebpf.plugin/README.md +++ b/collectors/ebpf.plugin/README.md @@ -244,19 +244,29 @@ To collect data related to Linux multi-device (MD) flushing, the following kprob ### Disk -The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled. This will create the -chart `disk_latency_io` for each disk on the host. The following tracepoints are used: +The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled. + +#### Disk Latency +This will create the chart `disk_latency_io` for each disk on the host. The following tracepoints are used: - [`block/block_rq_issue`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_issue): IO request operation to a device drive. - [`block/block_rq_complete`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_complete): IO operation completed by device. +Disk Latency is the single most important metric to focus on when it comes to storage performance, under most circumstances. +For hard drives, an average latency somewhere between 10 to 20 ms can be considered acceptable. For SSD (Solid State Drives), +in most cases, workloads experience less than 1 ms latency numbers, but workloads should never reach higher than 3 ms. +The dimensions refer to time intervals. + ### Filesystem -This group has charts demonstrating how applications interact with the Linux -kernel to open and close file descriptors. It also brings latency charts for -several different filesystems. +This group has charts demonstrating how applications interact with the Linux kernel to open and close file descriptors. +It also brings latency charts for several different filesystems. + +#### Latency Algorithm +We calculate the difference between the calling and return times, spanning disk I/O, file system operations (lock, I/O), +run queue latency and all events related to the monitored action. #### ext4 @@ -410,6 +420,11 @@ is accessed, but also in possible errors, so we need to attach a `kretprobe`. Fo - [`d_lookup`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/dcache.c?id=052b398a43a7de8c68c13e7fa05d6b3d16ce6801#n2223): Called when the desired file is not inside the directory cache. +##### Directory Cache Interpretation +When directory cache is showing 100% that means that every accessed file was present in the directory cache. +If files are not present in the directory cache, they are either not present in the file system or the files were not +accessed before. + ### Mount Points The following `kprobes` are used to collect `mount` & `unmount` call counts: |