ボリュームをfsckするのにどのくらい時間がかかりますか？
現在300〜500万ページビューを提供しているウェブサイトを運営しています。私たちのサイトはファイル共有サイトなので、250,000ファイルと数千のシンボリックリンクが含まれています。
ハードディスクは1500GB SATAディスクです。
hdparmを使用すると、ハードディスクの速度が15-2 MB/sに低下していることがわかりました。これは8 MB/sでした。
そこで、fsckを実行して、ディスクの問題を修正します。
fsckはこの問題を解決しますか？fsckが完了するまでにどのくらいの時間がかかりますか？（予定しているダウンタイムを計算したいだけです）？
同時にアクセスされるファイルの数が増えると、速度の低下が予想されます。ハードディスクドライブは、並行してアクセスされることを好みません。読み取り/書き込みヘッドがシリンダーを切り替える必要があるたびに、数ミリ秒を失います。 2つのファイルが同じシリンダーまたは同じトラック上にある場合でも、ローテーションが1つから別のローテーションに移動するのを待たなければならない場合があります。メガビット/秒でドライブのパフォーマンスを測定する場合は、並列アクセスが増加するにつれて、指数関数的に低下すると予想されます。
fsckはこれには役立ちません。ディレクトリ構造の損傷を修復するだけで、最適化は行いません。
理想的なソリューションは、ソリッドステートストレージへの切り替えです。これには、回転するプラッターの物理的な制限がないためです。しかし、それはおそらく法外な費用です。
次善の策は、並列アクセス用に最適化されたRAIDを使用することです。 RAIDは多くの異なるパフォーマンスプロファイルに合わせて構成できるため、特定のRAIDハードウェアとドライバーの設定を理解するには、少し時間がかかることに注意してください。
アグレッシブなファイルシステムキャッシングを使用すると、問題を軽減できる場合があります。システムに十分なRAMがある場合、Linuxはすでにこれをかなりうまく行っているはずです。 topのようなプログラムを実行して、空き容量を確認しますRAMがあります。ただし、最も一般的に使用されるファイルがRAM（またはRAM獲得する可能性が高い）、これは実際には役に立ちません。
貧乏人の回避策は、ファイルをいくつかの異なる物理ハードドライブ（同じドライブ上の異なるパーティションだけではない）に分割することです。これは実際には長期的なスケーラブルなソリューションではなく、まともなRAIDよりもコストがかかることになります。しかし、ドライブが横になっている場合は、すぐに解決できるかもしれません。
ハードディスクドライブを含むソリューションの場合は、回転速度が速く、シーク遅延が少ないことを確認してください。
私はここにハードドライブのパフォーマンスに関するいくつかの一般的な背景を持つ記事を書きました：
Fsckが完了するまでに5時間かかると思います。
私は代わりにreiserfsへの移行を検討します（つまり、テスト、テスト、およびテスト）。
- いいえ（fsckは破損したファイルシステムメタデータを修正できますが、破損したディスクを修正することはできません。また、最適化ツールでもありません）。
- ファイルシステムに依存します。 ext3では、耐え難いほど長いので、数時間は予約しておきます。 ext4やxfsなどの最新のファイルシステムは、簡単に1桁速くなります。
hdparmは順次読み取りを行います。他の人が言ったように、ファイルサーバーディスクは多くのシークを実行しているはずです。
HDエラーが発生している場合は、/ var/log /のどこかに表示されているはずです。
「smartctl -t short/dev/sda」、「smartctl -t long/dev/sda」を試してみませんか?? ...ほとんどの新しいHDDでは、HDを使用しているときでもこのコマンドを発行できます。スマートはあなたにいくつかの結果を与えます。 「smartctl --all/dev/sda」を使用してHDDの状態を読み取ることができます。
同時アクセスでマウントされているHDDにhdparmを送信する場合、それが結果が以前よりもはるかに少ない理由である可能性があります。
できるだけ早くRAIDセットアップにデータを移動する必要があります。