web-dev-qa-db-ja.com

(Linux-Ubuntu 13.04)小さなファイルを含む信じられないほど遅いSSD

SSD(Crucial M4-256GB)を入手して以来、小さなファイルで何かをしているときはいつでも、486でWindows7を実行するのと同じくらい遅く書き込むという問題がありました。 Intel Rapid Storage Technologyドライバー/サービスをインストールすることにより、Windows7でこれを「修正」することができました。

ただし、Linux(Ubuntu 13.04を実行)では、このためのドライバーはないようです。私は多くの異なる解決策を試してきましたが、今のところどれもうまくいかなかったようです。

私のSSDは、/としてマウントされた1つのEXT4パーティションに分割されています。/homeにマウントする別の2TBハードディスクがあります

ブロックサイズに関して私が入手したいくつかの情報は次のとおりです。

# Sudo blockdev --getbsz /dev/sda
> 4096

# Sudo hdparm -I /dev/sda | grep -i physical
> Physical Sector size: 512 bytes

SSDのfstabエントリは次のようになります。

UUID=c954288b-e1bd-4d3b-93ab-6a688210d070 /               ext4    errors=remount-ro,relatime,barrier=0,noatime,nodiratime,discard,commit=120  0       1

オプションからわかるように、私はたくさんのことを試しましたが、どれも正しく機能していないようです。例を挙げると、「apt-getinstallvim」を使用してViMをインストールするのに2分以上かかりました。

完全なapt-getdist-upgradeには4時間半以上かかりました。私は通常のHDD(5200 rpm)でUbuntuを実行していますが、これよりもはるかに高速です。

Partedによると、私のパーティションは適切に配置されています。次のコマンドを使用して確認しました。

# Sudo parted /dev/sda
<parted> align-check opt
partition: 1

> aligned 1

また、SSDが「ビジー」になるたびにiotopを実行すると、jbd2が約99〜100%の時間をノンストップで消費していることがわかります。

誰かがこの問題に光を当てることができれば、それは完全に素晴らしいでしょう!

編集:いくつかの追加情報:

Hdparm -t/dev/sdaを実行すると、次の出力が得られます(これは私にはまったく問題ないように見えます)

Timing buffered disk reads: 680 MB in  3.01 seconds = 226.16 MB/sec

アイドル時のiotop出力:

TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                                               
 2346 be/4 harold      0.00 B/s   31.04 K/s  0.00 %  0.00 % chrome
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]
    7 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u:0H]

アプリケーションやその他の重いもののインストールを実行しているときに、このプロセス「jbd2」がすべてのリソースを使い果たしてしまうことがありますが、実際にアプリケーションを実行している間(たとえば、mysqldがデータベース関連のものを更新したり、apt-getがソフトウェアをインストールまたは更新したりする場合は、約3のままです。 〜4%)

奇妙な部分は、時々それがうまく機能していることです(私はここに結果を投稿するために問題を再現しようとしましたが、明らかにそれはランダムな時間に起こっています)。以下のiotopの出力を更新して、再び問題が発生したときの結果を示します。

私のコンピューターが今私を荒らしているような気がします:(

edit2:いくつかの追加機能を追加するのを忘れました(Craig Watsonに感謝)

/etc/rc.localファイルの内容は次のようになります。

echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
exit 0

そして/ etc/default/grubの中に、私は:

GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline"

最初にスケジューラーを試した後、スケジューラーだけではまだ良い結果が得られなかったため、fstrim部分も追加しました。

前もって感謝します。

ハロルド。

4
Harold

I/Oスケジューラを変更してみてください。

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

次に、それをGrubのデフォルトに追加して、起動時にロードされるようにします。

Sudo nano /etc/default/grub

変化する GRUB_CMDLINE_LINUX_DEFAULT to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"

そして実行します:Sudo update-grub2

また、RAMの使用状況を確認してください-SSDにスワップしている可能性があり、(長期的には)悪影響を与える可能性があります。十分なRAMがある場合は、swappinessをゼロに設定できます。そのRAMは、RAMが完全に不足していない限り使用されません。

Sudo echo 0 > /proc/sys/vm/swappiness

参照: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm

1
Craig Watson