Ubuntuでファイルをコピー/ダウンロードする際のパフォーマンス低下を修正

ファイルをコピーするときにパフォーマンスの問題がいつ発生したかは覚えていませんが、ファイルをコピーすることはめったにないので、これをあまり重視しませんでした。 比較的最近、高速インターネット接続が自由に利用できるようになり、今では大きなファイルをコピー/ダウンロードすることが多くなり、パフォーマンスの低下の問題が私にとって非常に緊急になっています。



表面的なググルは結果を出さず、より深く掘り始めましたが、多くのubuntovodsはすべてではないにしてもCPU負荷が高いという問題があり、この問題の迅速な解決策はなかったので、ファイルをコピーするときのプロセッサ。



問題

高速ダウンロードトレント、ディスクからディスクへ、フラッシュドライブへのマルチスレッドコピーにより、プロセッサの負荷は100%を超え、 LAは急速に成長しています。



同時に、少数のスレッドでのファイル操作では、すべてがうまく機能します。



理論のビット

オペレーティングシステムには、 IOデバイスと呼ばれるものがあります。これは、ブロックデバイスと低レベルドライバーの間のレイヤーです。 スケジューラのタスクは、プロセスに対して要求されたディスクデバイスへのアクセスを最適に提供することです。 ハードディスクの場合、これは読み取りヘッドの動きを最小限に抑えることを意味します。

プランナーの活動は、次の側面に分類されます。

多くのプランナーがいますが、結局のところ、この投稿で解決された問題が結びついたのは彼らでした。

最も一般的なものを簡単に検討してください。



うん
最も単純なFIFOベースのスケジューラ。 並べ替えはなく、キュー内の近くにあるリクエストのみをマージできます。 フラッシュメモリなど、ランダムアクセスを備えたデバイスに最適です。



締め切り
書き込み要求ではなく読み取り要求を優先するスケジューラー。 リクエストは並べ替えられますが、リクエストの処理時間は指定された制限(デフォルトでは、読み取りで0.5秒、書き込みで5秒)を超えてはなりません。



実装には、4つのキューが使用されます。2 sorted-by-start-sector



キュー(読み取りと書き込み用)と2つのFIFOキュー(読み取りと書き込み用)です。 通常、リクエストはソートされたキューから取得されますが、FIFOキューからの最初のリクエストの期限(タイムアウト)がプッシュされると、クエリ処理はこの要素からのソートされたキューで続行されます。



データベースの整理に最適です。



CFQ-完全に公平なキューイング
このスケジューラの目的は、すべてのリクエスタのリソースにアクセス時間を正直に割り当てることです。 CFQは、プロセス、プロセスグループ、ユーザーを調整するように構成できます。



実装により、CFQは要求イニシエーターごとに1つのFIFOキューを暗黙指定し、 ラウンドロビンキューを切り替えます。



誰がそのような誠実さを必要としているのかはわかりませんが、このスケジューラーのハードディスクの読み取りヘッドの動きを最小限にするためのリクエストの並べ替えはありません。



予想的
重要なアイデア-リクエストを処理する前に、少し待ってリラックスしてください。 しかし、これらの数ミリ秒で、情報が事前に収集されるため、要求に応じて、より多くの情報に基づいた決定を行うことができます。



予測スケジューラは期限に基づいています。 次のようなデスクトップに適しています 出力入力サブシステムの応答性が維持されます。 RAID、 TCQには適していません。 同期リクエストが異なるプロセスによって送信される状況にはあまり適していません。



解決策

Ubuntu 10.10のデフォルトのスケジューラーはCFQですが、実践が示すように、マルチスレッドのコピー中にCPUの負荷が高くなるのはこのスケジューラーです。 スケジューラーを別のスケジューラー、例えばDeadlineやvoilaに変更します-100%のCPU負荷はもうありません。



上記のように、SSDとフラッシュメモリ全般では、Noopを使用することをお勧めします。



ちょっとした練習



アクティブスケジューラーを学ぶ
システムで利用可能なすべてのスケジューラを調べて、アクティブなスケジューラを見つけるには、次を実行します:

$ cat /sys/block/{DEVICE-NAME}/queue/scheduler





ここで、 {DEVICE-NAME}



はブロックデバイスの名前、たとえばsda



です。

たとえば、ドライブがsda



場合、次を実行する必要があります。

$ cat /sys/block/sda/queue/scheduler





出力は次のような行です。

noop anticipatory deadline [cfq]





角括弧内に、現在のスケジューラが示されています。



オンザフライでのスケジューラーの変更
再起動せずにリアルタイムでスケジューラを変更するには、次の手順を実行します。

$ sudo -i

# echo {SCHEDULER-NAME} > /sys/block/{DEVICE-NAME}/queue/scheduler








ここで{SCHEDULER-NAME}



はシステムに存在するスケジューラーの1つです。これは次のnoop anticipatory deadline cfq



です: noop anticipatory deadline cfq



。 たとえば、 deadline



スケジューラを設定するには、次を実行します

$ sudo -i

# echo deadline > /sys/block/sda/queue/scheduler








スケジューラ設定のコミット
次に、再起動後に選択したスケジューラーをUbuntuに強制的に使用させる必要があります。 これを行うには、 GRUB_CMDLINE_LINUX_DEFAULT="elevator={SCHEDULER-NAME}"



という行をGRUB 2構成に追加します。

$ sudo nano /etc/default/grub







UPD:変更を行った後、grub構成を更新する必要があります。

$ sudo update-grub







grub2ではなくgrubがある場合は、 elevator={SCHEDULER-NAME}



/boot/grub/grub.conf



追加します。



スケジューラーの選択に役立つ
ハブで、スケジューラーの自動化された選択についてすでに書いています。 もちろん、単純な読み取り速度のチェックだけでは最適な選択にはなりませんが、ある程度のアイデアは得られます。



便利なリンク

投稿の作成時に使用されるリンク:

LinuxでのI / Oスケジューラに関するプレゼンテーション

Linux Ioスケジューラ-Waikato Linux Users Group

I / Oスケジューラーの比較

Linux I / Oスケジューラー(LinuxカーネルIOスケジュール最適化チューニング)

ブックオブグラブ2



この微調整について友人に話した後、彼は誰もそれを知らなかったことに驚き、Habrに投稿することに決め、突然誰かのために役立つでしょう。



PS



UPD:

この記事では、実際に最も単純な、いわゆるいわゆる バグ12309 この問題を解決するためのヒントはまだあります。

-CFQスケジューラーを変更しないで、 構成する

- 禅コアを入れる

- スワップアグレッションを設定

-ハードウェアスケジューラと大量のRAMを備えたハードドライブを購入する(スワップに行かないように)



このテキストはCC BY-SAでライセンスされています

元の著者(問題、解決策)はg3n1ussです。 共著者(理論、デザイン)-謙虚な僕。



All Articles