当我注意到iostat -dxk 3读取速度非常慢，介于5 MB / s和10 MB / s之间，以及100％的磁盘利用率时，我正在用GNU sort对一些大文件（91 GB，跨越27个文件）进行sort 。 我试过cat large-file > /dev/null ，得到相似的性能，只是略高一点。 对于cp large-file /tmp/ ，在单独的磁盘上使用/tmp也是一样的。 vim体验和我在Ruby读取文件中写的脚本一样，如果有帮助的话。 写入速度很好，但速度很快。
编辑：它看起来像这些操作只是缓慢的某个目录中的文件。 对兄弟目录（相同的磁盘分区）中的其他文件进行相同的操作，速度快，读取速度高于90MBPS。 这对我来说没有意义。 这可能是由于这些文件的构build方式吗？ 我通过阅读很多其他文件来创build它们，并根据行中的第一个字符（如az和其他文件的单个文件）将每行写入适当的“存储区文件”。 所以我几乎同时在一次读取27个文件的同时，通过8个进程追加几行文件。 这是否会导致代表一个文件的块顺序排列？ 因此，之后的缓慢连续读取？
不过，我尝试使用fio来测量顺序读取性能，并以73 MB / s的速度进行读取。 还值得注意的是，我的老板从同一台机器上通过FTP下载某些文件时，得到了正确的读取速度。
所以我猜这是一些configuration问题，但我不知道在哪里。 原因是什么？我该如何解决？
编辑：这台机器在Citrix Xen虚拟化下运行。
编辑： iostat -dxk输出，而sort正在加载一个大文件到其缓冲区（得到类似的输出猫/ CP）：
Device: rrqm/s wrqm/sr/sw/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，但是只有一个sorting操作正在进行，没有其他进程正在执行任何IO操作，所以读取应该是sequential = /：
Device: rrqm/s wrqm/sr/sw/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/sr/sw/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/sr/sw/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
你的文件是否很慢？ 运行/usr/sbin/filefrag -v filename找出来。 你会得到如下输出：
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
或者可能更糟糕。
你提到系统正在虚拟化下运行。 这是与虚拟磁盘映像文件访问吗？
所以，我相信这是一个没有足够内存的简单情况…
当读/写一个比你的RAM小的文件时，一开始就是这样（每一件事情都很快 – 就像你的“fio”testing一样）
一旦你开始处理大于你的操作系统caching的数据，你的操作系统caching开始交换（有时甚至是磁盘）（事实上，当你有4mb的读取速度时，你应该检查你的内存使用情况）
这听起来像是以前的一些经验，你的阅读这样一个大文件的速度变慢了。（当我看到一个数据库完全一样，当它使用大的索引，不适合内存）
同时也考虑到在虚拟机上工作的开销（这听起来很典型）
我会检查你的磁盘没有交换或你的活动内存不充分（让我知道）：D