有什么方法可以跟踪特定进程并获取磁盘 IO 的统计信息，例如队列深度、读/写线程总数、读/写百分比等？
主要目标是使用所有这些信息通过 fio 工具模拟 IO 活动。
或者可能有任何其他方式（工具）来估计哪些硬件可以更好地满足特定负载？
当然测试是最好的选择，但对我来说并不完全可用，我无法购买所有可能的硬件。
因此，我必须与购买前已经做出一些假设的产品进行比较。
# fio --name=random-write --directory=/mnt/test/ --ioengine=posixaio --rw=randwrite -bs=4k --numjobs=1 --size=4g -iodepth=1 -runtime=600 --time_based --end_fsync=1
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.7
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:00s]
知道为什么它在我设置的 60 分钟而不是 600 秒后返回吗？
我检查了dmesg，没有错误：
[Mon Mar 1 20:53:36 2021] XFS (sda2): Mounting V5 Filesystem
[Mon Mar 1 20:53:37 2021] XFS (sda2): Starting recovery (logdev: internal)
[Mon Mar 1 20:53:45 2021] XFS (sda2): Ending recovery (logdev: internal)
我同时在同一个盒子上的另一个驱动器（而不是 SSD）上运行了相同的命令，它按时完成并返回。
提前致谢！
我被要求fio提供此测试数据集的基准测试结果：1048576x1MiB。因此，整体大小为1TiB。该集合包含2^20 个 1MiB文件。服务器运行CentOS Linux release 7.8.2003 (Core)。它有足够的内存：
[root@tbn-6 src]# free -g
total used free shared buff/cache available
Mem: 376 8 365 0 2 365
Swap: 3 2 1
它实际上不是物理服务器。相反，它是一个具有以下 CPU 的 Docker 容器：
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 48
On-line CPU(s) list: 0-47
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6146 CPU @ 3.20GHz
[...]
为什么是码头工人？我们正在开展一个项目，评估使用容器而不是物理服务器的适当性。回到fio问题。
fio我记得我以前在处理包含许多小文件的数据集时遇到了麻烦。所以，我做了以下检查：
[root@tbn-6 src]# ulimit -Hn
8388608
[root@tbn-6 src]# ulimit -Sn
8388608
[root@tbn-6 src]# cat /proc/sys/kernel/shmmax
18446744073692774399
在我看来一切都很好。在撰写本文时，我还使用 GCC 9编译了最新的 fio 3.23 。
[root@tbn-6 src]# fio --version
fio-3.23
这是作业文件：
[root@tbn-6 src]# cat testfio.ini
[writetest]
thread=1
blocksize=2m
rw=randwrite
direct=1
buffered=0
ioengine=psync
gtod_reduce=1
numjobs=12
iodepth=1
runtime=180
group_reporting=1
percentage_random=90
opendir=./1048576x1MiB
注：以上内容，可取出以下内容：
[...]
gtod_reduce=1
[...]
runtime=180
group_reporting=1
[...]
其余的必须保留。这是因为在我们看来运行 fio 时，作业文件的设置方式应尽可能模拟应用程序与存储的交互，即使知道fio!=也是如此the application。
我第一次跑步是这样的
[root@tbn-6 src]# fio testfio.ini
smalloc: OOM. Consider using --alloc-size to increase the shared memory available.
smalloc: size = 368, alloc_size = 388, blocks = 13
smalloc: pool 0, free/total blocks 1/524320
smalloc: pool 1, free/total blocks 8/524320
smalloc: pool 2, free/total blocks 10/524320
smalloc: pool 3, free/total blocks 10/524320
smalloc: pool 4, free/total blocks 10/524320
smalloc: pool 5, free/total blocks 10/524320
smalloc: pool 6, free/total blocks 10/524320
smalloc: pool 7, free/total blocks 10/524320
fio: filesetup.c:1613: alloc_new_file: Assertion `0' failed.
Aborted (core dumped)
好的，是时候使用--alloc-size
[root@tbn-6 src]# fio --alloc-size=776 testfio.ini
smalloc: OOM. Consider using --alloc-size to increase the shared memory available.
smalloc: size = 368, alloc_size = 388, blocks = 13
smalloc: pool 0, free/total blocks 1/524320
smalloc: pool 1, free/total blocks 8/524320
smalloc: pool 2, free/total blocks 10/524320
smalloc: pool 3, free/total blocks 10/524320
smalloc: pool 4, free/total blocks 10/524320
smalloc: pool 5, free/total blocks 10/524320
smalloc: pool 6, free/total blocks 10/524320
smalloc: pool 7, free/total blocks 10/524320
smalloc: pool 8, free/total blocks 8/524288
smalloc: pool 9, free/total blocks 8/524288
smalloc: pool 10, free/total blocks 8/524288
smalloc: pool 11, free/total blocks 8/524288
smalloc: pool 12, free/total blocks 8/524288
smalloc: pool 13, free/total blocks 8/524288
smalloc: pool 14, free/total blocks 8/524288
smalloc: pool 15, free/total blocks 8/524288
fio: filesetup.c:1613: alloc_new_file: Assertion `0' failed.
Aborted (core dumped)
回到原点 ：（
我肯定错过了什么。任何帮助都非常有义务。