[Debian] Langzame disks?

[c0deaddict]

Hallo,

Als ik data (xvidje, 700mb) van m'n desktop naar de server pomp via samba dan gaat dit 'maar' met max. 60% v/d 100mbit connectie (volgens Windows Task Manager > Networking). De server zit aan dezelfde 100mbit switch als m'n workstation en zou imo dus makkelijk 90% of meer van de 100mbit moeten kunnen benutten.

De schijven waar de data naar toe wordt geschreven trekken volgens 'hdparm -t /dev/sd[b,c]' makkelijk 40mb/s dus daar kan het niet aan liggen. Ook de ethernetkaartjes op zowel de server als m'n desktop kunnen makkelijk 100mbit aan.

Wat me wel opviel op de server is dat de 'await' in 'iostat -x' ontzettend hoog is. De 'await' staat voor de schijven (sda, sdb en sdc) staat standaard op 200 of hoger, wat als ik het goed begrepen heb voor 200ms wachttijd staat. De 'await' loopt ook behoorlijk snel op als ik data op dezelfde schijf heen en [b]weer verplaats. Dan gaat ie gerust naar de 2000 tot 3000 Ook wordt de server een stuk trager als er data gelezen/geschreven wordt...

Het rare is dat de doorvoersnelheden van schijven wel gewoon normaal zijn. Terwijl ik juist zou verwachten dat die een stuk lager lag aangezien programma's (en de kernel) lang moeten wachten totdat hun aangevraagde data beschikbaar is..

Het probleem doet zich voor op alle disks, dus zowel /dev/sda als /dev/sdb en /dev/sdc. Dus volgens mij ligt het dus niet aan de RAID controller of de SATA controller, maar eerder aan linux SCSI subsystem ofzo.

Server

CPUs: 2x Pentium III 600mhz
RAM: 1 GB ECC SDRAM
Ethernet: Intel e100
HD1: sda 4x9.1GB SCSI @ RAID-5 64KB stripe [HP NetRAID 1Si]
HD2: sdb 300GB SATA [Promise Fasttrak TX4]
HD3: sdc 300GB SATA [Promise Fasttrak TX4]

Operating System

Distro: Debian
Kernel: Linux 2.6.16.14 (custom)

Schijf indeling:

swap /dev/sda2
/boot /dev/sda1 ext2
/root /dev/sda3 ext3
/home/secure /dev/vg_system/lv_secure_home reiserfs
/home/insecure /dev/vg_data/lv_insecure_home reiserfs
/tmp /dev/vg_system/lv_tmp ext3
/usr /dev/vg_system/v_usr ext3
/usr/local /dev/vg_system/lv_usr_local ext3
/var /dev/vg_system/lv_var ext3
/www /dev/vg_system/lv_www ext3
/pub /dev/vg_data/lv_pub reiserfs

vg_system = /dev/sda4
vg_data = /dev/sdb + /dev/sdc


BVD

[daft_dutch]

laat je er incryptie op los?

[nzyme]

linux scsi subsystem lijkt me niet iets waar een fout nog in kan zitten he

samba is nou niet echt een betrouwbare speedmeter, gebruik liever ftp.

die raid5 adapter, zit daar cache op ? want writes op raid5 zijn (bij ide iig) behooorlijk @$%#$%^%#!@$%&%*...

De schijven waar de data naar toe wordt geschreven trekken volgens 'hdparm -t /dev/sd[b,c]' makkelijk 40mb/s dus daar kan het niet aan liggen. [...]

Vergeet vooral niet dat hdparm slechts gaat over reads

gebruik anders eens bonnie++. (apt-get install bonnie++)

[c0deaddict]

@daft_dutch: Geen encryptie

@Hellraizer:
De HP NetRAID 1Si adapter heeft idd 16MB EDO cache, in de BIOS kan je de write modus instellen: WRITEBACK of WRITETHROUGH heb beide geprobeerd maar geen verschil...
FTP & bonnie++ zal ik ook ff proberen

Dit geeft 'iostat -x':

code:

choco:/usr/src/linux# iostat -x
Linux 2.6.16.14-choco (choco)   05/08/06

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.28    0.00    1.90    0.82    0.00   97.00

Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          0.13   7.24  1.24  0.71  115.23   56.29    57.61    28.15    88.03     0.52  269.10   4.17   0.81
sdb          0.83 100.34  2.16  0.89  501.23  809.84   250.61   404.92   430.85     0.31  102.26   6.50   1.98
sdc          0.74  66.20  1.17  0.68  259.59  535.91   129.79   267.95   428.75     0.21  115.49   6.25   1.16
dm-0         0.00   0.00  0.00  0.00    0.01    0.00     0.00     0.00     2.91     0.00    7.45   2.44   0.00
dm-1         0.00   0.00  0.07  1.20    0.44    2.40     0.22     1.20     2.23     0.27  210.74   0.95   0.12
dm-2         0.00   0.00  0.13  0.00    2.94    0.00     1.47     0.00    21.91     0.00    6.41   4.32   0.06
dm-3         0.00   0.00  0.00  0.00    0.01    0.00     0.00     0.00     3.31     0.00   13.76  10.29   0.00
dm-4         0.00   0.00  1.02  6.73  110.71   53.85    55.35    26.93    21.24     7.77 1002.71   0.87   0.67
dm-5         0.00   0.00  0.00  0.00    0.04    0.00     0.02     0.00    14.32     0.00    8.06   5.05   0.00
dm-6         0.00   0.00  0.15  7.17    1.23   57.38     0.62    28.69     8.00     6.28  857.01   0.10   0.07
dm-7         0.00   0.00  4.05 161.05  754.04 1288.37   377.02   644.18    12.37    44.20  267.71   0.18   3.01

Tijdens het runnen van bonnie++

code:

Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          0.13  15.21  1.28  1.25  119.61  124.07    59.81    62.03    96.14     1.17  461.96   5.12   1.30
sdb          0.83 105.64  2.34  0.94  544.30  852.70   272.15   426.35   425.56     0.32   96.82   6.46   2.12
sdc          0.73  66.17  1.17  0.69  257.45  535.74   128.73   267.87   427.92     0.21  114.70   6.25   1.16
dm-0         0.00   0.00  0.00  0.00    0.01    0.00     0.00     0.00     2.91     0.00    7.45   2.44   0.00
dm-1         0.00   0.00  0.07  1.20    0.44    2.40     0.22     1.20     2.23     0.27  213.66   2.98   0.38
dm-2         0.00   0.00  0.14  0.00    3.00    0.00     1.50     0.00    22.07     0.00    9.59   6.71   0.09
dm-3         0.00   0.00  0.00  0.00    0.01    0.00     0.00     0.00     3.25     0.00   20.90  17.58   0.00
dm-4         0.00   0.00  1.05 15.24  115.00  121.93    57.50    60.96    14.54    17.93 1099.57   0.71   1.16
dm-5         0.00   0.00  0.00  0.00    0.04    0.00     0.02     0.00    14.32     0.00    8.06   5.05   0.00
dm-6         0.00   0.00  0.15  7.10    1.22   56.77     0.61    28.39     8.00     6.21  857.01   0.10   0.07
dm-7         0.00   0.00  4.22 166.46  795.05 1331.66   397.53   665.83    12.46    44.85  262.77   0.18   3.15

Hmm raar, tijdens het runnen van bonnie++ begint m'n muziek te schokken (uit de public dir; gemount in windows). De public dir staat op sdb, sdc terwijl bonnie++ sda test. Linux zou toch gewoon met volle snelheid van beide schijven moeten kunnen lezen?
Wat ook raar is is dat 'top' aangeeft dat 1 of 2 CPU's constant 100% waiting heeft.

Oke, super raar. Bonnie++ is klaar met het hele schrijf gebeuren en begint nu met getc() testen. En opeens begint de wachttijd te dalen en staan de CPU's nog maar voor 5% of minder in waiting
Het is dus echt puur een probleem met het schrijven naar de RAID array..

Zo bonnie++ is klaar:

code:

Writing with putc()...^[^[[12~done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
choco            2G  7847  73  8688  11  4798   7  7118  76 21148  18 253.5   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  5846  95 +++++ +++  5333  92  5801  93 +++++ +++  5161  97
choco,2G,7847,73,8688,11,4798,7,7118,76,21148,18,253.5,2,16,5846,95,+++++,+++,5333,92,5801,93,+++++,+++,5161,97

Ziet er ook niet zo goed uit

code:

choco:/home/jos# vmstat -D
           12 disks
            4 partitions
       840451 total reads
        93301 merged reads
    137502380 read sectors
     21362392 milli reading
     12538328 writes
     12057029 merged writes
    195993720 written sectors
    704331008 milli writing
            0 inprogress IO
         7837 milli spent IO

[ Voor 135% gewijzigd door c0deaddict op 08-05-2006 16:01 ]

[lckarssen]

Op mijn Athlon XP 3000+, met twee 160GB Maxtor SATA disks in softraid1, met /home een LVM2 LV krijg ik:

code:

lennart@jerom:~/tmp/bonnie++-1.03a$ ./bonnie++ 
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
jerom            1G 30499  89 46267  33 16066   5 29314  52 46356   8 326.6   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
jerom,1G,30499,89,46267,33,16066,5,29314,52,46356,8,326.6,1,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

Behoorlijk wat verschil met jouw waarden dus.

[Jesse]

Zonder dollen, maar probeer serieus ook even een gewone ftp transfer inplaats van samba. (Wat Hellraizer zegt)

[axis]

Code Addict schreef op maandag 08 mei 2006 @ 15:26:
De HP NetRAID 1Si adapter heeft idd 16MB EDO cache, in de BIOS kan je de write modus instellen: WRITEBACK of WRITETHROUGH heb beide geprobeerd maar geen verschil...

Vreemd, bij de meeste RAID5 controllers geeft WRITEBACK meer dan 100% performancewinst op writes.. Zit toch een onboard BBU op die kaart?

[c0deaddict]

@Jesse: FTP heb ik geprobeerd, zelfde resultaat: download gaat @ full 100mbit maar up gaat tot max 6mb/s
@axis: Wat is een onboard BBU?

Het rare is is dat ik upload naar de sdb en sdc schijven die niet in de RAID-5 array zitten maar gewoon los op een SATA controller die geen RAID of wat dan ook doet. De sdb en sdc schijven halen per stuk zo'n 50mb/s (aldus hdparm).

[ Voor 46% gewijzigd door c0deaddict op 09-05-2006 12:33 ]

[JeroenE]

Vreemd, bij de meeste RAID5 controllers geeft WRITEBACK meer dan 100% performancewinst op writes..

Dat heeft alleen nut als je minder probeert te schrijven dan er in je cache past. Als je cache vol is dan moet de data eerst weggeschreven worden voordat je nieuwe data in je cache kan accepteren. Op dat moment is er dus geen verschil meer.

Afhankelijk van de rest van de situatie kan een writeback cache bij een crash er ook voor zorgen dat je applicaties de draad kwijt zijn (bijvoorbeeld: databases inconsistent omdat de database server dacht dat alles al weggeschreven was, maar het in de praktijk dus niet zo is).

Zit toch een onboard BBU op die kaart?

Als ik op dit linkje kijk dan maak ik daar uit op dat er geen hardware aanwezig is voor de raid5; de CPU moet dus alle berekeningen zelf doen.

@Code Addict
Zelf heb ik niet zo veel ervaring met dual processoren, maar als je CPU druk bezig is met het uitrekenen van alle XOR's en dergelijk dan kan ik me voorstellen dat samba even geen tijd krijgt.

Bovendien staat zo'n beetje alles op je sda, dus als er 'iets' opgehaald op weggeschreven moet worden dan zal dat toch moeten wachten tot dat 'even' tussendoor kan. Onder Windows is dat trouwens niet anders. Als je meerdere disken hebt moet je eens kijken wat er gebeurd als je c:\grotedir naar d:\ kopieert en terwijl dat bezig is ook c:\nogeengrotedir ook naar d:\ gaat kopieren. Dat gaat veel langzamer dan wanneer je die twee kopie-acties achter elkaar doet.

Heb je 1 PCI bus waar alle kaarten op zitten of heb je het verdeelt over meerdere bussen?

[c0deaddict]

@jeroene

Het rare is dat m'n public op twee SATA schijven staat, dus buiten de RAID array om. Daar schrijf ik op via samba (hoofdzakelijk tenminste) en dat gaat, net als FTP, met maar 6mb/s..

Promise SATA kaart @ PCI 0000:00:02.0
HP NetRAID 1Si @ PCI 0000:03:02.0

Zijn dat twee verschillende bussen? (ik gok van wel, maar heb er geen verstand van)

@Axis

Er zit geen onboard BBU (Battery Backup Unit) op de kaart.

[ Voor 10% gewijzigd door c0deaddict op 09-05-2006 18:27 ]

[JeroenE]

Het rare is dat m'n public op twee SATA schijven staat, dus buiten de RAID array om. Daar schrijf ik op via samba (hoofdzakelijk tenminste) en dat gaat, net als FTP, met maar 6mb/s..

Heb je bonnie++ al eens op je SATA schijven gedraaid?

Uit je eerdere berichten begrijp ik ook dat je tijdens het testen / overzetten van de gegevens bezig bent met andere zaken op dezelfde server. Als je de throughput wil testen moet je natuurlijk niet met meerdere processen op dezelfde schijven bezig zijn. Het ene proces zal het andere altijd verstoren en zorgen dat het minder snel gaat.

Zijn dat twee verschillende bussen? (ik gok van wel, maar heb er geen verstand van)

Als ik dal wil weten gebruik is altijd "lspci -tv". Als je meerdere PCI bussen hebt dan heb je gelijk een splitsing. Zo ziet het er bijvoorbeeld uit op een Compaq ML350. Die heeft 2 PCI bussen; 1 met 2 PCI-64-bit aansluitingen en 1 met 4 PCI-32-bit aansluitingen.

code:

ml350:~# lspci -tv
-+-[04]-+-02.0  Intel Corporation 82557/8/9 [Ethernet Pro 100]
 |      \-04.0  Digital Equipment Corporation DECchip 21554
 \-[00]-+-00.0  Broadcom CNB20LE Host Bridge
        +-00.1  Broadcom CNB20LE Host Bridge
        +-01.0-[01]--+-04.0  Adaptec AHA-3960D / AIC-7899A U160/m
        |            +-04.1  Adaptec AHA-3960D / AIC-7899A U160/m
        |            +-05.0  Intel Corporation 82557/8/9 [Ethernet Pro 100]
        |            +-06.0  ATI Technologies Inc Rage XL
        |            \-07.0  Compaq Computer Corporation Advanced System Management Controller
        +-0f.0  Broadcom OSB4 South Bridge
        +-0f.1  Broadcom OSB4 IDE Controller
        \-0f.2  Broadcom OSB4/CSB5 OHCI USB Controller

NB iostat geeft de eerste keer altijd de gegevens vanaf de laatste boot. Als je meer info wil hebben over de laatste tijd kan je beter iets als "iostat -xk 5 2" doen. Je krijgt dan de gelijk de gegevens vanaf de boto te zien en na 5 seconden de gegevens van die 5 seconden. Het is me niet helemaal duidelijk of je dit hebt gedaan in je output van iostat in je TS.