Add content for eBPF documentation (#12417)
thiagoftsm committed
Mar 18, 2022 at 22:22 UTC
f8b22ce560922133b13ea2d655dc80d10e95fffc
1 file changed
+20
-5
collectors/ebpf.plugin/README.md
+20
-5
@@ -244,19 +244,29 @@ To collect data related to Linux multi-device (MD) flushing, the following kprob
244
245
### Disk
246
247
-The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled. This will create the
248
-chart `disk_latency_io` for each disk on the host. The following tracepoints are used:
247
+The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled.
248
+
249
+#### Disk Latency
250
+This will create the chart `disk_latency_io` for each disk on the host. The following tracepoints are used:
251
252
- [`block/block_rq_issue`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_issue):
253
IO request operation to a device drive.
254
- [`block/block_rq_complete`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_complete):
255
IO operation completed by device.
256
257
+Disk Latency is the single most important metric to focus on when it comes to storage performance, under most circumstances.
258
+For hard drives, an average latency somewhere between 10 to 20 ms can be considered acceptable. For SSD (Solid State Drives),
259
+in most cases, workloads experience less than 1 ms latency numbers, but workloads should never reach higher than 3 ms.
260
+The dimensions refer to time intervals.
261
+
262
### Filesystem
263
257
-This group has charts demonstrating how applications interact with the Linux
258
-kernel to open and close file descriptors. It also brings latency charts for
259
-several different filesystems.
264
+This group has charts demonstrating how applications interact with the Linux kernel to open and close file descriptors.
265
+It also brings latency charts for several different filesystems.
266
+
267
+#### Latency Algorithm
268
+We calculate the difference between the calling and return times, spanning disk I/O, file system operations (lock, I/O),
269
+run queue latency and all events related to the monitored action.
270
271
#### ext4
272
@@ -410,6 +420,11 @@ is accessed, but also in possible errors, so we need to attach a `kretprobe`. Fo
420
- [`d_lookup`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/dcache.c?id=052b398a43a7de8c68c13e7fa05d6b3d16ce6801#n2223):
421
Called when the desired file is not inside the directory cache.
422
423
+##### Directory Cache Interpretation
424
+When directory cache is showing 100% that means that every accessed file was present in the directory cache.
425
+If files are not present in the directory cache, they are either not present in the file system or the files were not
426
+accessed before.
427
+
428
### Mount Points
429
430
The following `kprobes` are used to collect `mount` & `unmount` call counts: