主页 / server / 问题 / 1039640
Accepted
foss4me
Asked: 2020-10-22 15:44:14 +0800 CST

对许多小文件进行基准测试时，fio 3.23 核心转储

  • 772

我被要求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)

回到原点 ：（

我肯定错过了什么。任何帮助都非常有义务。

memory fio crash oom

1 个回答

  1. Best Answer

    （TL；DR设置--alloc-size有一个大数字有帮助）

    我敢打赌，您可以简化这项工作并仍然重现问题（这对于查看此内容的人都会有所帮助，因为可以查看的地方更少）。我猜关键是那个opendir选项以及你说目录包含“2 ^ 20 1MiB文件”的事实......

    如果您阅读文档，--alloc-size您会注意到它提到：

    如果在启用randommap的情况下运行大型作业，fio 可能会耗尽内存。

    默认情况下，fio 在文件中均匀分布随机 I/O（每个块每次写入一次），但为此它需要跟踪它已写入的区域，这意味着它必须为每个文件保留一个数据结构。好的，您可以看到这是怎么回事...

    为某些数据结构预留的内存池（因为它们必须在作业之间共享）。最初有 8 个池（https://github.com/axboe/fio/blob/fio-3.23/smalloc.c#L22），默认情况下每个池的大小为 16 兆字节（https://github.com/axboe /fio/blob/fio-3.23/smalloc.c#L21）。

    每个执行随机 I/O 的文件都需要一个数据结构。根据您的输出，让我们猜测每个文件强制分配一个 368 字节 + 标头（https://github.com/axboe/fio/blob/fio-3.23/smalloc.c#L434）的数据结构，结合起来388 字节。因为池在 32 字节（https://github.com/axboe/fio/blob/fio-3.23/smalloc.c#L70）的分配中工作，这意味着我们实际上从 13 个块（416 字节）中取出每个文件一个池。

    出于好奇，我有以下问题：

    • 你是在容器中运行它吗？
    • 你的最大尺寸/tmp是多少？

    我认为以上内容与您的问题无关，但最好排除。

    更新：默认情况下，docker 限制 IPC 共享内存的数量（另见其--shm-size选项）。目前尚不清楚这是否是这种特殊情况的一个因素，但请参阅下面的“原始作业仅停止在 8 个池”评论。

    那么为什么设置没有--alloc-size=776帮助呢？看看你写的，你每个池的块没有增加似乎很奇怪，对吧？我注意到您的池第二次增长到最多 16 个（https://github.com/axboe/fio/blob/fio-3.23/smalloc.c#L24）。的文档是--alloc-size这样说的：

    --alloc-size= kb在KiB中分配大小为kb 的其他内部 smalloc 池。[...] 池大小默认为16MiB。[重点补充]

    你用过--alloc-size=776... 776 KiB 不是小于 16 MiB 吗？这将使每个池小于默认值，并且可以解释为什么它在第二次运行放弃之前尝试将池的数量增加到最大 16。

    (2 ** 20 * 416) / 8 / 1024 = 53248 (but see the update below)

    上述算术建议您希望每个池的大小约为 52 兆字节，如果您将拥有 8 个池，总计大约 416 兆字节的 RAM。使用时会发生什么--alloc-size=53248？

    更新：上面计算的数字太低了。在评论中，提问者报告说需要使用更高的设置--alloc-size=1048576。

    （我有点担心原来的工作只停在 8 个池 (128 MiB) 上。这是否表明尝试增长到第 9 个 16 MiB 池是有问题的？）

    最后，当您要求随机 I/O 的特定分布时，fio 文档似乎暗示正在分配这些数据结构。这表明如果 I/O 是顺序的，或者 I/O 使用随机偏移量但不必遵守分布，那么也许不必分配这些数据结构......如果你使用会发生什么norandommap?

    （旁白：blocksize=2M但你的文件有 1MiB 大 - 对吗？）

    这个问题对于随便的 serverfault 答案来说感觉太大了，太专业了，可能会从 fio 项目本身得到更好的答案（参见https://github.com/axboe/fio/blob/fio-3.23/REPORTING-BUGS，https:// /github.com/axboe/fio/blob/fio-3.23/README#L58）。

    祝你好运！

    • 2

相关问题