☰

Centos 5.5/ext3 上的 cp 和 cat 对于某些目录中的文件来说速度慢了 10 倍

tag-icon • tag-icon linux centos performance xen hard-drive
Centos 5.5/ext3 上的 cp 和 cat 对于某些目录中的文件来说速度慢了 10 倍

我用 GNU 对一些大文件（27 个文件，共 91GB）进行排序sort时，我注意到iostat -dxk 3读取速度非常慢，介于 5 MB/s 和 10 MB/s 之间，磁盘利用率为 100%。我尝试了cat large-file > /dev/null，得到了类似的性能，只是略高一点。cp large-file /tmp/在/tmp单独的磁盘上使用时vim也是如此。如果有帮助的话，我用 Ruby 编写的脚本读取文件时也会遇到同样的情况。不过写入速度很快。

编辑：看起来这些操作只对某个目录中的文件很慢。对同级目录（同一磁盘分区）中的其他文件执行相同的操作，最终会很快，读取速度超过 90 MBPS。这对我来说毫无意义。这可能是由于这些文件的构造方式吗？我通过读取大量其他文件并根据行中的第一个字符将每行写入适当的“存储桶文件”（因此是 az，其他文件为单个文件）来创建它们。因此，我几乎同时通过 8 个进程一次将行附加到 27 个文件中，同时读取几千个文件。这是否会导致表示文件的块的顺序乱序？因此之后的顺序读取很慢？

不过，我尝试用它fio来测量连续读取性能，它的速度为 73 MB/s。同样值得注意的是，我的老板从同一台机器通过 FTP 下载一些文件时获得了适当的读取速度。

所以我猜这是某个地方的配置问题，但我不知道在哪里。原因可能是什么？我该如何尝试修复它？

编辑：该机器在 Citrix Xen 虚拟化下运行。

iostat -dxk编辑： while的输出sort正在将一个大文件加载到其缓冲区中（获得与 cat/cp 类似的输出）：

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb              0.00     0.00 1000.00  0.00  6138.61     0.00    12.28    24.66   24.10   0.99  99.41
xvdb1             0.00     0.00 1000.00  0.00  6138.61     0.00    12.28    24.66   24.10   0.99  99.41
xvda              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
xvda1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

编辑：几个小时后性能进一步下降（处理时磁盘中断sort）。它几乎看起来像随机 IO，但只有一个排序操作在进行，没有其他进程执行任何 IO，因此读取应该是连续的 =/ ：

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb              0.00     0.00 638.00  0.00  2966.67     0.00     9.30    25.89   40.62   1.57 100.00

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb              0.33     0.00 574.67  0.00  2613.33     0.00     9.10    27.82   47.55   1.74 100.00 

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb              0.00     0.00 444.33  0.00  1801.33     0.00     8.11    28.41   65.27   2.25 100.00

答案1

您的慢速文件是否高度碎片化？运行/usr/sbin/filefrag -vfilename找出答案。您将获得如下输出：

Checking big.file
Filesystem type is: ef53
Filesystem cylinder groups is approximately 4272
Blocksize of file big.file is 4096
File size of big.file is 96780584 (23629 blocks)
First block: 88179714
Last block: 88261773
Discontinuity: Block 6 is at 88179742 (was 88179719)
Discontinuity: Block 12233 is at 88192008 (was 88191981)
Discontinuity: Block 17132 is at 88197127 (was 88196911)
Discontinuity: Block 17133 is at 88255271 (was 88197127)
big.file: 5 extents found, perfection would be 1 extent

甚至可能更糟。

您提到系统在虚拟化下运行。这是使用虚拟磁盘映像文件进行访问吗？

答案2

所以，我相信这只是一个 RAM 不足的简单情况……

首先，当读取/写入小于 RAM 的文件时（一切都很快 - 就像您的“fio”测试一样..）

一旦您开始处理大于操作系统可以缓存的数据，您的操作系统缓存就会开始交换（有时甚至是交换到磁盘）（事实上，当您的读取速度为 4mb 时，您应该检查您的 RAM 使用情况）

这听起来像我以前经历过的事情，读取这么大的文件的速度很慢。（我见过数据库在使用无法放入 RAM 的大型索引时也发生同样的事情）

还考虑到在虚拟机上工作的开销（这对我来说听起来很典型）

我会检查你的磁盘是否没有交换或者你的活动内存是否已满（并让我知道）：D

相关内容