web-dev-qa-db-ja.com

Centos 5.5 / ext3のcpとcatは、特定のディレクトリ内のファイルでは10倍遅くなります

GNU sortでいくつかの大きなファイル（27ファイル全体で91GB）を並べ替えていたときに、iostat -dxk 3の読み取り速度が5MB/sから10MB/sの間で、100％と非常に遅いことに気付きました。ディスク使用率。 cat large-file > /dev/nullを試してみましたが、同様のパフォーマンスが得られましたが、わずかに高くなっています。 cp large-file /tmp/についても同じですが、/tmpは別のディスクにあります。 vimも同じように経験します。また、Rubyで記述したスクリプトは、ファイルの読み取りに役立ちます。ただし、書き込み速度は問題なく高速です。

編集：これらの操作は特定のディレクトリ内のファイルでのみ遅いようです。兄弟ディレクトリ（同じディスクパーティション）内の他のファイルでの同じ操作は、90MBPSを超える読み取り速度で高速になります。これこれらのファイルの作成方法が原因である可能性がありますか？他の多くのファイルを読み取り、最初の文字に応じて各行を適切な「バケットファイル」に書き込むことで作成しました。そのため、数千のファイルを読み取りながら、8つのプロセスを通じて27のファイルに一度に1つずつ、ほぼ同時に行を追加していました。これにより、ブロックが順番に並べられる可能性があります。代わりにファイルが故障していることを表しますか？したがって、その後の遅いシーケンシャル読み取り？

ただし、fioを使用して順次読み取りパフォーマンスを測定しようとすると、73 MB/sでクロックインされました。また、同じマシンからFTP経由でいくつかのファイルをダウンロードすると、上司が適切な読み取り速度を取得したことも注目に値します。

ですから、これはどこかの構成の問題だと思いますが、どこにあるのかわかりません。理由は何で、どうすれば修正できますか？

編集：このマシンはCitrixXen仮想化で実行されています。

編集：sortが大きなファイルをバッファーにロードしている間のiostat -dxkの出力（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のように見えますが、実行されているソート操作は1つだけで、他のプロセスは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
linuxcentosperformancexenhard-drive
3
ehsanul

遅いファイルは非常に断片化されていますか？実行/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

またはおそらくはるかに悪い。

システムが仮想化の下で実行されているとおっしゃいました。このアクセスは仮想ディスクイメージファイルを使用していますか？

3
mattdm

スー、これはRAMが足りないという単純なケースだと思います...

RAM（「fio」テストのようにすべてが高速です。）よりも小さいファイルの読み取り/書き込みを行う場合の開始点です。）

OSがキャッシュできるよりも大きいデータで作業を開始すると、OSキャッシュがスワップを開始します（場合によってはディスクにさえ）（実際、4MBの読み取り速度がある場合はRAMの使用状況を確認する必要があります）

これまでの経験のように聞こえますが、このような大きなファイルの読み取り速度が遅くなっています。（DBがRAM）に収まらない大きなインデックスを使用していたときにまったく同じことをするのを見ました）

VM（これは私にとって非常に典型的なように聞こえます）での作業のオーバーヘッドも考えると）

ディスクがスワッピングされていないか、アクティブなメモリがいっぱいでないことを確認します（そして私に知らせてください）：D

0
Arenstar