ディスク操作によりDebianがフリーズする

新しいデスクトップにDebianテストをインストールしましたが、パフォーマンスにあまり満足していません-システムでパッケージをアップグレードするなど、ディスク集中型の操作を実行すると、すべてがフリーズするように見えます。たとえば、Iceweaselのタブの変更には3秒かかります 私は3歳のThinkpad X60超ポータブルでDebianを実行していますが、これらの問題はありません。（ラップトップの単一のパラメーターはすべてデスクトップよりもはるかに悪いです）。

デフォルトのパッケージ化されたカーネルとスクリプトを使用しています。

走る

hdparm -t /dev/sda1

そして、予想通り96GB / sになりました。それをより良くするために他に何を試みることができますか？

編集：

grzes:/home/ga# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD15EARS-00Z5B1, FwRev=80.00A80, SerialNo=WD-WMAVU1362357
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=2930277168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

EDIT2：妻でさえ、「この新しいコンピューターでは、カメラから写真をコピーしても何もできず、古いコンピューターよりもはるかに悪い」と言いました。だから、それは深刻でなければなりません。

EDIT3：2.6.32に更新されましたが、まだ改善されていません

EDIT4：新しいディスクはext4、古いディスクはext3であることを忘れていました。

EDIT5：まだ解決していません。P43 ASUS P5QL-Eボードを持っています。関連性があると思われるdmesgの行：

[    0.370850] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)                              
[    0.370852] io scheduler noop registered                                                                      
[    0.370853] io scheduler anticipatory registered                                                              
[    0.370854] io scheduler deadline registered                                                                  
[    0.370876] io scheduler cfq registered (default)
...
[    0.908233] ata_piix 0000:00:1f.2: version 2.13                                                               
[    0.908243] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19                                 
[    0.908246] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]                                                        
[    0.908275] ata_piix 0000:00:1f.2: setting latency timer to 64                                                
[    0.908316] scsi0 : ata_piix                                                                                  
[    0.908374] scsi1 : ata_piix                                                                                  
[    0.909180] ata1: SATA max UDMA/133 cmd 0xa000 ctl 0x9c00 bmdma 0x9480 irq 19                                 
[    0.909183] ata2: SATA max UDMA/133 cmd 0x9880 ctl 0x9800 bmdma 0x9488 irq 19                                 
[    0.909199] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19                                 
[    0.909202] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]                                                        
[    0.909228] ata_piix 0000:00:1f.5: setting latency timer to 64                                                
[    0.909279] scsi2 : ata_piix                                                                                  
[    0.909326] scsi3 : ata_piix                                                                                  
[    0.910021] ata3: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19                       

パーティションのオフセットを確認します-4096テクノロジーがあるため、EARSの場合は4で割り切れる必要があります。そうでない場合は、パーティションを再分割してアライメントとパフォーマンスの問題を解決する必要があります（アライメントが合っていないEARSドライブは、1回の操作でより多くのセクター書き込みを行います）。

大量のディスクIOを実行すると、同様のフリーズ問題が発生しました。バックアップ中、バックアップが完了するまでデスクトップは数秒間何度もフリーズしていました。

これは、アライメントやhdparmの調整とは関係ありませんでした（ただし、助けになると思いますが）。

システムのロックアップは、よりインタラクティブなアプリケーション（Firefox、KDEなど）に必要なIOの遅延が大きすぎるIOスケジューラーが原因で発生しました。障害のあるIOスケジューラはcfgでした。

この問題を解決するには、期限IOスケジューラーを使用する必要があります。/etc/rc.localに追加できる次のコマンドを使用して、ディスク上でアクティブ化します。

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

詳細については、集中的なディスクI / Oの実行時にLinuxシステムのロックアップを解決するを確認してください。

それは暗闇の中でのショットですが、私はしばらく前にこのような問題を抱えていましたが、原因はカーネルがチップセットを完全にサポートしておらず、DMAがオフになっていることが判明しました。確認する

hdparm -i /dev/sda

DMAモードのいずれかが有効になっているかどうか。

（その場合の解決策は、新しいカーネルを入手することでした。）

多くのfsync（2）呼び出しを実行する操作がシステムの大幅なスローダウンを引き起こす問題に遭遇しました。私の場合、LUKSに含まれるLVMに含まれるルートパーティションで実行しています。LVMまたはLUKSを使用していますか？

（単にパッケージをインストールするのではなく）ディスクを噛み砕いているものを正確に特定するのに役立つツールはと呼ばれiotopます。これらのタスクのいずれかを実行しているときに実行することをお勧めします。また、同時にトリガーされ、すべてのI / Oスループットを消費する他のバックグラウンドプロセスが指摘される場合があります。

sudo fdisk -u / dev / sda

開始オフセットが得られるはずです。fdisk -o 64または何かを使用してパーティションを作成できると思います-fdiskでグーグルを行い、パーティションオフセットを手動で設定できるように、グーグルで検索する必要があります（デフォルトは63ですので、うまくいきません）。

そして、はい、ディスクは512bセクターでOSに見せかけているように表示されます-Vista / W7は正しいオフセットを設定することでこれを処理しますが、XPと私はほとんどすべてのlinus distros dont :(手動でしか考えられません（私のものは単なるストレージドライブであり、win7 / ntfsで作成されているので、問題はありません）

編集：-wdcで素敵な投稿を見つけました-これですぐに起動して実行できるはずです:)

http://community.wdc.com/t5/Desktop/Problem-with-WD-Advanced-Format-drive-in-LINUX-WD15EARS/mp/10920#M631

Debianを使用していることを考えると、これはばかげているように思えますが、同じHDDモデルを使用している人を助けていることがわかりました。

一般的な経験則として、デバイスでhdparmを使用できる場合、それは「古い」ATAインターフェイスであり、新しいSATA / SCSIインターフェイスです。その場合、問題はおそらく、割り込み中のディスク操作がデフォルトで有効になっていないことです。これは、古いATAインターフェイスを使用している一部のマシンで一般的な問題であり、I / O操作が多い場合はディスクまたはシステムのパフォーマンスが低下します。

あなたは本当にこれを試してみるべきです：

sudo hdparm -t -T /dev/sda
sudo hdparm -a8 -c3 -u1 /dev/sda
sudo hdparm -t -T /dev/sda

2回目のタイミング実行（3番目のコマンド）でパフォーマンスの改善が見られない場合は、別のことが行われています。

もう1つの要因は、UDMA6モードが非UDPケーブルで機能することを期待していることです（SATAインターフェイスではないことを前提としています）。80ピンATAケーブルを使用している場合は問題ありません。古い40ピンを使用している場合は、あらゆる種類の悲しみが生じます。ケーブルが古い40ピンの場合、転送レートを「安全に」サポートできるものに下げる必要があります。 警告：IDEインターフェースを調整すると、ドライブやインターフェースがハングする可能性があり、ドライブがルートファイルシステムの場合、システム全体がハングします！

ハードウェアに合わせて転送速度を下げる必要がある場合は、次を試してください。

sudo hdparm -t -T /dev/sda
sudo sync; sleep 3 ; sync    
sudo hdparm -d 1 -X mdma2 /dev/sda
sudo hdparm -t -T /dev/sda

繰り返しますが、2番目のタイミング（発行された3番目のコマンド）で改善が見られます。

最後に、ドライブ自体はわずかかもしれませんが、SMARTレポートがなければ、問題に気付かないかもしれません（手遅れになるまで）。smartmontools特に少しのTLCを必要とする古いドライブがある場合は特に、このパッケージをインストールすることをお勧めします。

sudo apt-get update && apt-get install smartmontools

他のすべてが失敗した場合は、/var/log/messagesディスクI / Oエラーを探します。

更新：

あなたは一人ではないようです。これらのユニットのあらゆる種類の心痛を報告するメッセージボードがネット全体にあります。

• http://community.wdc.com/t5/Desktop/WDC-WD15EARS-00Z5B1-awful-performance/mp/5242
• http://www.readynas.com/forum/viewtopic.php?f=21&t=40279
• http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg33347.html

また、4kセクターサイズを使用するドライブと「従来の」512バイトサイズのドライブについても言及しています。私はこれがどんな種類の問題を引き起こしているのか想像することができます。

最後に、出力をもう一度見ると、ジャーナリングスレッドがシステムをほとんど拘束しているようです。ジャーナリングされていないファイルシステムは一時的に問題を緩和するかもしれませんが、せいぜい予防的であり、最悪の場合は問題を解決しません。

これは最終的に修正されました！@Rachelが指摘したように、問題は確かに4kbセクターへのアライメントにありましたが、残念ながらリンクされた記事は間違っていました:(

パーティションを調整する正しい方法はこちらです：http : //www.linuxconfig.org/linux-wd-ears-advanced-format

また、この記事では、パーティションテーブルが正しいかどうかを確認できるように、非常に優れたベンチマークを提供しています。http： //article.gmane.org/gmane.linux.utilities.util-linux-ng/2955

ちなみに、このドライブがあり、Linuxを使用している場合は、ここで説明されているように、アイドルタイマーの1つを増やす必要があります。http： //wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp .PHP？p_faqid = 5357＆p_created = 1266947046＆p_sid = Os7DQL2k＆p_accessibility = 0＆p_redirect =＆p_srch = 1＆p_lva =＆p_sp = cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NTEsNTEmcF9wcm9kcz0yMjcsMjk0JnBfY2F0cz0xMzAmcF9wdj0yLjI5NCZwX2N2PTEuMTMwJnBfcGFnZT0x＆p_li =＆p_topview = 1