Dotaz: Zpomalení systému při práci s HDD

[Jardík]

Už delší dobu se mi projevuje taková nepříjemná věc při kopírování a tou je skoro nemožnost normálního používání při kopírování souborů. Věc se má takto: začnu kopírovat nějaký soubor (na velikosti nezáleží, ale příkladem budiž 4GB soubor, který se kopíruje dostatečně dlouho, abych při tom něco stihl dělat) a spustím např. Firefox, tak když už dokáže naběhnout před dokopírováním souboru, tak je skoro nepoužitelný, protože to nic nestíhá. Na aplikaci nezáleží, dělá to se všemi. Systémem to ale také nebude, protože stejná věc se mi projevuje i ve Windows. A vůbec nezáleží, jestli kopíruji z disku na disk, oddílu na oddíl, nebo ze stejného oddílu na stejný oddíl. Na mém NB se toto neprojevuje a při kopírování můžu klidně dělat, co chci.

Už to pozoruji delší dobu, tak 2 měsíce a už mě to opravdu deptá. Podezřívám DMA, Windows ve správci zařízení ukazuje DMA a je tam zaškrtlé, že se bude používat, co řekne BIOS. Chtěl bych si to radši ověřit i v Linuxu, ale nevím jak. hdparm se SATA disky nespolupracuje a sdparm nic jako DMA neukáže:

# sdparm /dev/sda
/dev/sda: ATA       WDC WD3200YS-01P  21.0
Read write error recovery mode page:
  AWRE        1
  ARRE        0
  PER         0
Caching (SBC) mode page:
  WCE         1
  RCD         0
Control mode page:
  SWP         0

# sdparm /dev/sdb
    /dev/sdb: ATA       WDC WD2500YS-01S  20.0
Read write error recovery mode page:
  AWRE        1
  ARRE        0
  PER         0
Caching (SBC) mode page:
  WCE         1
  RCD         0
Control mode page:
  SWP         0

A pokud to není DMA, v čem by mohl být problém? V řadiči na desce? Teď mě napadá, že to možná začalo dělat po přidání druhého disku, ale nevím to určitě. Nejdřív bych si chtěl ověřit do DMA, než se začnu hrabat ve skříni.

Odpovědi

[Jardík]

Tak jsem něco našel v dmesg:

ata3: SATA max UDMA/133 cmd 0xc480 ctl 0xc400 bmdma 0xbc00 irq 23       
ata4: SATA max UDMA/133 cmd 0xc080 ctl 0xc000 bmdma 0xbc08 irq 23
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-7: WDC WD3200YS-01PGB0, 21.00M21, max UDMA/133
ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 1)
ata3.00: configured for UDMA/133
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATAPI: ASUS    DRW-2014L1T, 1.00, max UDMA/66
ata4.00: configured for UDMA/66
sata_nv 0000:00:05.1: PCI INT B -> Link[LSA1] -> GSI 22 (level, low) ->IRQ 22
sata_nv 0000:00:05.1: Using SWNCQ mode
sata_nv 0000:00:05.1: setting latency timer to 64
scsi4 : sata_nv
scsi5 : sata_nv
ata5: SATA max UDMA/133 cmd 0xb880 ctl 0xb800 bmdma 0xb080 irq 22
ata6: SATA max UDMA/133 cmd 0xb480 ctl 0xb400 bmdma 0xb088 irq 22
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ATA-7: WDC WD2500YS-01SHB1, 20.06C06, max UDMA/133
ata5.00: 490234752 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata5.00: configured for UDMA/133

Nějak se mi to nezdá, proč pro SATA DVD palírnu jen UDMA/66 a pro disky jen UDMA/133 - je to SATA2 a to má být přece 300 (jestli to 133 znamená přenosovou rychlost). Ještě se zkusím pohrabat v BIOSu.

[Jardík]

Teda ne 300 ale 375 (MB).

[pht]

nejde v biosu nastavit ahci?

[Jardík]

Nic takového v BIOSu nemám

[Jardík]

Tak jsem v BIOSu natvrdo nastavil UDMA6 na obouch discích a UDMA4 na DVD palírně a stále stejná chyba. Aktualizoval jsem BIOS na nejnovější verzi, stále stejný problém.

[frr]

Pomohl by výpis smartctl -d ata -a /dev/sda .

Pak si přihřeju polívčičku - co ukazuje hddtest?

http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz

 

[Jardík]

hddtest.cc: In member function ‘void test_thread::seq_test(char)’:
hddtest.cc:383: error: ‘malloc’ was not declared in this scope
hddtest.cc:471: error: ‘free’ was not declared in this scope
hddtest.cc: In member function ‘void test_thread::rnd_test(char)’:
hddtest.cc:501: error: ‘malloc’ was not declared in this scope
hddtest.cc:604: error: ‘free’ was not declared in this scope
hddtest.cc: In function ‘void my_exit(int)’:
hddtest.cc:956: error: ‘exit’ was not declared in this scope
make: *** [hddtest] Error 1

Pomohlo #include <stdlib.h>

Teď to běží, asi na dlouho u 320GB disku? Ale jetli to kontroluje disk, tak je to asi zbytečné, když to dělá na obouch.

A to smartctl nemám, jaký je to balíček?

[Jardík]

A zajímavé je, že se mi systém nezpomalil ... asi se tedy zpomaluje jen při zápisu.

[Jardík]

Beru to zpět, ke zpomalení dochází. On ten program totiž poprvé nedělal nic, nevypsal ani čárku a pak když jsem zmáčknul entern tak ukázal přístup odepřen, tak jsem ho spustil pod rootem. Teď ukazuje průběh, ale systém je skoro nepoužitelný, jdu koukat na telku, než se to udělá.

[frr]

Nemá asi moc smysl, nechat hddtest běžet přes celý disk (pokud nechcete vyloženě kontrolovat celý povrch disku). On jede pořád dokola, na konci passu nic nevypíše / nezaloguje. Spíš mě zajímala sekvenční přenosová rychlost - tu program ukazuje průběžně. Jaká je typická hodnota? Vyskytují se krátkodobé výkyvy? Případně zkuste parametr -2 a dejte vědět, kolik Tps disk zvládá. Nejlépe je testovat disk odmontovaný / bez zátěže, ale to leda z nějakého live CD.

Napadá mě, jestli nemáte nějaký problém se zvoleným schedulerem (za určitých méně běžných okolností mi pomohlo změnit CFQ na "noop") - ale to by se neprojevovalo pod Windows. Zkusil jste se taky podívat programem iostat z balíku "sysstat", jaká je na disku zátěž ve chvíli, kdy "je systém pomalý" ? Ještě mě napadá LatencyTop, ale s tím jsem nikdy nepracoval...

Hmm... mohl byste přihodit výpis /proc/meminfo ?

 

[Jardík]

S parametrem -2 to lítá mezi 4000 kB/s a 3500 kB/s a 60 TPS, bez -2 se to pohybuje okolo 65000 kB/s a 1015 TPS, odmountovaný je. Ještě zkusím ten iostat.

[Jardík]

Při kopírování z oddílu na ten samý (sdb), cca 1GB dat v cca 40MB souborech ukazuje iostat:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.24    0.00    3.58   42.30    0.00   51.88

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             363.29     91966.90         0.00 2864408488          0
sdb               5.63       277.33       283.50    8637758    8829824

Skoro to samé ukazuje při spuštění hddtest -2 na sda (odmountovaný), akorát se mění ty bloky a minimálně tps. Ale moudrý z toho nejsem.

[Jardík]

Po rozbalení raru při kopírování 4GB souboru z sda1 na sdb1 a současném pokusu o spuštění firefoxu ukázal iostat

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.41    0.00    3.54   41.36    0.00   52.69

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             351.64     88942.03       127.90 2864456279    4119136
sdb               7.41       603.35       522.36   19431270   16823168

Firefox dokázal naběhnout asi 10s po dokončení kopírování a dalších 5s byl absolutně nepoužitelný, než se uklidnily disky.

[frr]

Hele tohle všecko vypadá zdravě. Ty průchodnosti jak sekvenční tak náhodná tak "sekvenční do FS" jsou v naprostém pořádku. 10 s na start Firefoxu taky žádná tragédie. Sice nevím, co přesně hledá na discích dalších 5 s po zobrazení hlavního okna, ale vcelku proč ne.

Jak jsem chtěl ten výpis /proc/meminfo, tak z něj je vidět, kolik má stroj fyzické RAM, kolik z toho je volného, kolik zabírají I/O buffery (systémová disková cache), jak moc je využitý swap. Počítač se typicky tragicky zpomalí ve chvíli, kdy dochází fyzická RAM a systém musí začít swapovat. Pozor, pod Windowsama se swapovací algoritmus chová trochu jinak, a nejde ladit.

Možná ještě by byl zajímavý výpis "df" s namountovanými svazky. Z něj by se dalo usoudit na zaplnění filesystémů, což v kombinaci s dalšími nepříznivými okolnostmi (rychlá obrátka dat) může mít vliv na fragmentaci...

Jo a jestli je ten disk třeba pomalý při zápisu, to se dá otestovat prakticky jenom destruktivně (smažou se data) Už jsem viděl disky, které četly OK, ale při zápisu ukázaly pravou tvář... BTW v těch típancích z iostatu je vidět jenom čtení, skoro žádný zápis. Blok je 512B, takže ta hodnota v blocích/s děleno dvěma znamená kBps. Iostat doporučuju nechat běžet kontinuálně, např. v jednosekundovém intervalu (iostat  -1).

A ten scheduler se dá případně přehodit takhle:

cat /sys/block/sda/queue/scheduler
echo "noop" > /sys/block/sda/queue/scheduler

Dneska je default "cfq", který je na desktopu údajně subjektivně nejsvižnější - ale v některých verzích kernelu se mi choval líp noop

[Jardík]

Já jsem nemyslel, že mi FF naběhl do 10s. Já ho spustil chvilku poté, co se spustilo kopírování a okno se zobrazilo až 10s poté, co bylo kopírování dokončeno a dalších 5s v tom nešlo vůbec nic dělat. Ram mám 2GB, swap nemém. Skusím ho kdyžtak zapnout, ale pochybuji, že pomůže - ve Windows swap je zaplý. Zítra zkusím ještě ten /proc/meminfo, teď musím ve Windows pokročit v jedné nejmenované hře Ještě zkusím vždy zapojený jen 1 disk. Jestli nic nepomůže, tak ten krám hodím do popelnice.

[frr]

Jasně - pořídit jiný/nový disk a naklonovat na něj obsah starého disku. A ten starý pak můžete potrápit ještě zápisovým testem. Dobrý nápad.

Vyměňovat postupně jednotlivé díly, to je obecně nejjistější způsob, jak najít závadu - jenom člověk běžně nemá za zády sklad náhradního hardwaru, pokud se tím vysloveně neživí

Pokud budete pořizovat nový disk, hodně dobrou sekvenční rychlost a spotřebu mají nové Barracudy 7200.12 (500 GB na jedné plotně). Ale ani starší Barracudy 7200.11, třeba 250GB model, nejsou žádná ořezávátka.  Hodně rychlé seeky mají ze SATA disků WD Raptor resp. Velociraptor. A pak jsou tu samozřejmě klasické enterprise disky, třeba dnešní Cheetahy na SASu... ale SAS asi onboard mít nebudete

[Honza]

On ten problém ale nemusí být způsobený harwarem. Dokud jsem na desktopu používal Fedoru, mohl jsem klidně kopírovat jakkoliv velké soubory a odezva v Gnome byla stále stejná. Ve verzi 8 mě ale už naštvala nutnost každý rok upgradovat na novou verzi distribuce a přešel jsem na CentOS.Když teď kopíruji velký soubor (xGB), CPU tráví téměř veškerý čas v IOWait a odezva systému na cokoli co potřebuje I/O je šíleně pomalá. Přitom vlastní kopírování proběhne normálně rychle.

Předpokládám, že důvod bude pravděpodobně ve verzi jádra (Fedora 8 = 2.6.26, CentOS 5.2 = 2.6.18) a nejspíš i v jeho konfiguraci. Vzhledem k tomu, že to je jediná nevýhoda, kterou mi přechod na CentOS přinesl oproti obrovskému množství výhod, nechávám to být.

[Jardík]

S jádrem můj problém ale nesouvisí, dělá to i ve Windows