Bandbreite vom SATA controller ermitteln

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Bandbreite vom SATA controller ermitteln

Beitrag von reox » 31.12.2016 15:40:10

Gibt es eine Möglichkeit die Bandbreite des SATA controllers (also nicht eines Ports bzw der Festplatte) zu ermitteln?

Folgender SATA Controller wird verwendet und ich habe das Gefühl das die Bandbreite des Controllers nicht aussreicht um 4 (eigentlich sogar nur 3) Platten gleichzeitig zu betreiben. Einzeln sind die Platten nämlich schnell aber wenn ich RAID5 verwende bricht die Geschwindigkeit des Gesamtsystems ziemlich ein. (Alleine: ~100MB/s, RAID: <20MB/s)

Code: Alles auswählen

$ lspci -vvv -n -s 00:11.0
00:11.0 0106: 1002:4391 (rev 40) (prog-if 01 [AHCI 1.0])
	Subsystem: 103c:1609
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 41
	Region 0: I/O ports at d000 [size=8]
	Region 1: I/O ports at c000 [size=4]
	Region 2: I/O ports at b000 [size=8]
	Region 3: I/O ports at a000 [size=4]
	Region 4: I/O ports at 9000 [size=16]
	Region 5: Memory at fe6ffc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] MSI: Enable+ Count=1/4 Maskable- 64bit+
		Address: 00000000fee0200c  Data: 4181
	Capabilities: [70] SATA HBA v1.0 InCfgSpace
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP+
	Kernel driver in use: ahci
Wenn ich das richtig sehe, wird der Controller über zumindest einen PCI2.1 mit 64bit angebunden und sollte daher max 4266Mbit/s können - klar rein theoretischer Wert.

Benutzeravatar
Tintom
Beiträge: 1294
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Bandbreite vom SATA controller ermitteln

Beitrag von Tintom » 31.12.2016 16:20:19

Die Bandbreite sollte schon ausreichen um die Festplatten mit ordentlicher Geschwindigkeit auszulasten. Wenn du die Einschränkungen nur bei RAID hast würde ich auf eine zu schwache CPU tippen. Welche CPU hast du verbaut und wie hoch ist die Auslastung wenn du Schreib-/Leseoperationen mit dem RAID durchfürst?

reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: Bandbreite vom SATA controller ermitteln

Beitrag von reox » 31.12.2016 16:28:32

Tintom hat geschrieben:Die Bandbreite sollte schon ausreichen um die Festplatten mit ordentlicher Geschwindigkeit auszulasten. Wenn du die Einschränkungen nur bei RAID hast würde ich auf eine zu schwache CPU tippen. Welche CPU hast du verbaut und wie hoch ist die Auslastung wenn du Schreib-/Leseoperationen mit dem RAID durchfürst?
AMD Turion(tm) II Neo N54L Dual-Core Processor

Aktuell kopier ich was herum übers Netzwerk:

Code: Alles auswählen

top - 16:23:13 up  2:15,  1 user,  load average: 0,88, 0,96, 1,18
Tasks: 148 total,   4 running, 144 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  4,0 sy,  0,0 ni, 79,8 id, 15,9 wa,  0,0 hi,  0,3 si,  0,0 st
KiB Mem:   2025172 total,  1960492 used,    64680 free,    57532 buffers
KiB Swap:  8388604 total,        0 used,  8388604 free.  1711756 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                 
  527 root      20   0       0      0      0 S   3,7  0,0   5:14.20 mdX_raid5                                                                               
 1082 root      20   0       0      0      0 S   1,7  0,0   1:22.94 nfsd                                                                                    
 1083 root      20   0       0      0      0 R   1,3  0,0   1:17.65 nfsd                                                                                    
 1086 root      20   0       0      0      0 S   0,7  0,0   1:23.28 nfsd                                                                                    
  538 root      20   0       0      0      0 D   0,3  0,0   0:00.61 jbd2/dm-11-8                                                                            
 1085 root      20   0       0      0      0 R   0,3  0,0   1:24.24 nfsd                                                                                    
 1088 root      20   0       0      0      0 S   0,3  0,0   1:20.91 nfsd                                                                                    
 1194 root      20   0       0      0      0 S   0,3  0,0   0:08.55 kworker/1:1                                                                             
 1451 root      20   0       0      0      0 S   0,3  0,0   0:01.19 kworker/0:1                                                                             
 1537 reox      20   0   26224   3012   2500 R   0,3  0,1   0:00.08 top                                                                                     
    1 root      20   0   28800   4940   2932 S   0,0  0,2   0:02.47 systemd                                                                                 
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd      
dH den nfs daemon muss man da auch noch abziehen... 15% IO Wait, klingt jetzt nicht danach als ob die CPU da das Bottleneck wäre?
Auf der anderen Seite, ja die CPU ist jetzt kein i5 und die Load geht auch eher so gegen 2..

Hier mal dstat:

Code: Alles auswählen

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  0   6  84   9   0   1| 193k   16M|   0     0 |   0     0 |2392  3516 
  2   5  70  23   0   1|2808k   29M|1266B 1786B|   0     0 | 440   781 
  1   5  65  29   0   0|2012k   28M| 140B  524B|   0     0 | 437   689 
  1   7  58  33   0   1|2148k   28M| 210B   12k|   0     0 |1710  2370 
  1   6  38  56   0   0|1516k   30M| 140B  524B|   0     0 | 851  1874 
  1   6  39  55   0   0|1492k   25M| 208B  370B|   0     0 | 929  2048 
  0   5  43  51   0   1|1280k   30M| 140B  524B|   0     0 |1014  2214 
  3   4  36  58   0   0|8408k 3862k| 140B  524B|   0     0 | 565   975 
  2  28  30  36   1   3|7936k 1076k| 420B 1164B|   0     0 |  15k   22k

# Hier empfängt die Netzwerkkarte mal wieder nen Block:
  1  40  30  24   0   5|6136k 4458k|  99M  922k|   0     0 |  21k   30k
  1  23  33  36   1   6|2156k   25M| 118M 1097k|   0     0 |  12k   12k
  0   6  73  21   0   0|1460k   30M|  52M  294k|   0     0 | 557  1312 
  1   5  61  34   0   0|1548k   23M|  70B  370B|   0     0 | 651  1419 
  1   7  34  57   0   1|1896k   28M| 140B   11k|   0     0 |1822  2415 
  1   4  72  22   0   1|1476k   28M|  70B  370B|   0     0 | 929  1225 
  0   5  78  17   0   1|1736k   29M| 140B  524B|   0     0 | 542  1251 
  1   4  30  65   0   1|2216k   28M| 140B  524B|   0     0 | 902  1897 
  1   4  48  46   0   2| 976k   27M|  70B  370B|   0     0 | 618  1274 
  1   6  73  20   0   0|2132k   28M| 204B  588B|   0     0 | 461   827 
  1   5  72  22   0   0|2512k   29M|  70B  370B|   0     0 | 417   776 
  1   7  75  18   0   0|2136k   31M| 140B  524B|   0     0 | 434   803 
  1   5  68  26   0   1|2496k   27M| 140B  524B|   0     0 | 356   638 
  0   5  73  22   0   0|1568k   25M| 140B  524B|   0     0 | 425   770 
  2   6  65  27   0   1|1460k   27M| 140B   10k|   0     0 |1252  1650 
  1   5  38  56   0   1|1796k   30M|  70B  370B|   0     0 |1044  1897 
  1   5  70  25   0   0| 820k   26M| 140B  524B|   0     0 | 760  1653 
  1   5  71  24   0   0|1372k   29M|  70B  370B|   0     0 | 532  1206 
  0   5  31  64   0   1|4128k   15M| 140B  524B|   0     0 |1457  1439 
  1  24  13  59   1   3|5628k  454k|3350k 4756B|   0     0 |  12k   15k
# Bis hier hin braucht es damit es geschrieben ist... (20s)
  1  41  17  32   0  10|7956k 2238k|  80M  681k|   0     0 |  22k   29k
  1  30  41  24   1   4|1984k   23M| 118M 1037k|   0     0 |  16k   22k
  1   6  65  28   0   0|1976k   27M|  68M  619k|   0     0 | 778  1719 
  0   5  86   9   0   1| 864k   28M| 140B  524B|   0     0 | 550  1376 
  2   8  17  72   0   1|1748k   31M|  70B   11k|   0     0 |2215  2794 
  1   5  19  74   0   1|1924k   33M|  70B  370B|   0     0 |1383  1911 
  0   7  50  43   0   0| 988k   31M| 140B  524B|   0     0 |1090  1762 
  1   6  79  14   0   1|2476k   25M|  70B  370B|   0     0 | 736  1119 
  1   6  67  26   0   1|2116k   27M| 140B  524B|   0     0 | 386   692 
  1   6  69  24   0   1|2508k   28M| 140B  524B|   0     0 | 414   781 
Wie man sieht klatscht die Netzwerkkarte mal schnell 300MB hin und dann braucht das ne Zeit bis es auf der Platte landet.
Die CPU kernel load geht auch nur hoch wenn IO von der Netzwerkkarte kommt (ist eine Broadcom Corporation NetXtreme BCM5723).

Wenn ich nen PCIe Controller hier herumliegen hätte würde ich den mal einbauen und schauen ob es schneller wird ;)

edit: Ok mir is da gerade ein Test eingefallen: Ich hab eine 4. Platte an dem Controller. Wenn ich auf die schreibe wärend auf das RAID geschrieben wird, komm ich da auch locker auf 120MB/s auf der einen Platte + die 30MB/s aufs RAID. Sehr interessant ist dann aber, dass vom Netzwerk interface dann nicht mehr 100MB/s geholt werden sondern kontinuierlich 30MB/s:

Code: Alles auswählen

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  0   6  81  11   0   1| 304k   17M|   0     0 |   0     0 |2519  3684 
  0  17   8  69   0   6|   0   148M|  16M   23k|   0     0 |3871  2274 
  1  18   4  73   0   5|  48k  171M|  17M   21k|   0     0 |3950  2411 
  0  19   5  68   0   8|  96k  160M|  23M   30k|   0     0 |4920  2736 
  0  20  14  58   0   8|   0   155M|  24M   40k|   0     0 |5746  4432 
  0  17  10  68   0   4|  92k  163M|  28M  119k|   0     0 |1615  1934 
  0  14   8  76   0   2| 352k  154M| 922B 3304B|   0     0 |1541  2556 
  0  12   2  81   0   5| 156k  125M| 274B   10k|   0     0 |2559  1981 
  0  17   7  67   0   8| 152k  156M|6830k   12k|   0     0 |5428  2168 
  0  20  15  59   0   6|   0   157M|  35M   54k|   0   432k|5639  2922 
  0  17   8  70   0   5|  20k  162M|  28M   71k|   0     0 |3687  1946 
  0  17   5  71   0   7| 116k  161M|  20M   26k|   0     0 |4490  2096 
  0  18  11  65   0   6|  64k  149M|  23M   30k|   0     0 |4263  2170 
  0  26   7  60   0   7|  80k  174M|  39M  153k|   0     0 |7646  4866 
  0  16   5  74   0   5|  20k  158M|  21M   26k|   0     0 |3093  1893 
  1  16   6  72   0   5|  32k  147M|  15M   20k|   0     0 |3419  2042 
  0  21   7  65   0   6|  48k  177M|  18M   23k|  48k    0 |4193  2212 
  1  20   9  63   0   7|  44k  151M|  23M   41k|  16k    0 |4722  2658 
  0  21   7  65   0   7| 120k  155M|  20M   26k|   0     0 |5094  3225 
  0  17   9  71   0   3|  32k  176M|  18M   74k|   0     0 |1480  2400 
  0  14  17  65   0   3| 108k  131M| 204B  636B|   0     0 |2630  2187 
  0  23   2  67   0   8|  32k  151M|  28M   67k|   0     0 |7241  4043 
  0  18  10  67   0   5|   0   171M|  34M   90k|   0     0 |3910  2105 
  0  19   9  65   0   6|  68k  145M|  21M   27k|   0     0 |4544  2306 
  0  24  10  60   0   7|  64k  159M|  26M   34k|   0     0 |6250  4346 
  1  19   8  66   0   6|  88k  163M|  36M  118k|   0     0 |3575  2046 
  0  19   5  70   0   6|  32k  154M|  19M   28k|   0     0 |4396  2242 
  1  21   7  63   0   9|  16k  161M|  27M   49k|   0     0 |4890  2497 
  0  18   8  66   0   8|   0   159M|  15M   20k|   0     0 |3668  2181 
  1  17   5  71   0   7| 116k  160M|  17M   22k|   0     0 |4522  2593 
  0  19   8  69   0   5|  64k  159M|  23M   31k|   0     0 |3280  1935 
Scheint so als ob der Controller trotzdem wohl auf alle Platten schreiben kann... (Ok, ich hab nur pv /dev/zero > /dev/mapper/lv-ontheotherdisk gemacht). Was dann zu der Frage führt wo das Bottleneck tatsächlich ist?

editedit: Das RAID5 LVM besteht ja aus 6 LV's: 3* ein rimage und 3* ein rmeta.
Ich hab mir iostat angesschaut welche devices IO abbekommen und das sind alle 6. die meta LVs liegen am Anfang bzw ganz am Ende der Platten, so dass beim schreiben auf das image LV immer trotzdem an den Anfang der Platte bzw an das Ende gesprungen werden muss. Also wenn ich eigentlich sequential IO habe, wird das zu random IO und somit langsamer?

editeditedit: Ich hab mal die Raid Metadaten auf andere Platten verschoben. Jetzt schaut das IO Pattern wieder anders aus. iostat sagt mir jetzt, dass die utiliazation von dem LV nur noch bei ca 65% liegt (vorher war es 100) (Nicht ganz - nur im 2s mittel, nimmt man iostat -x 1, dann ist es auch teilweise wieder bei 100%) und nun schreibt er auch nicht mehr kontinuierlich sondern alle 2s.
dH die metadaten beeinflussen die Leistung des LV's schon, jedoch auch nicht so super viel. Wenn ich von /dev/zero lese komme ich auch nur auf ca 40MB/s.
Spannend ist jetzt aber auch die IOWait Zeiten:

Code: Alles auswählen

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdd               2,00  1524,00    1,00   13,00    12,00  6656,00   952,57     0,31   23,86    8,00   25,08  12,57  17,60
sdc               0,00     0,00    0,00   16,00     0,00    57,00     7,12     0,45   27,25    0,00   27,25  15,88  25,40
sda               0,00  1526,00    0,00   13,50     0,00  6412,00   949,93     0,30   22,52    0,00   22,52  13,93  18,80
sdb               0,00  1526,00    0,00   14,00     0,00  6668,00   952,57     0,37   28,43    0,00   28,43  15,71  22,00
sde               0,00    37,00    0,00  105,50     0,00   600,50    11,38    20,28  192,23    0,00  192,23   2,24  23,60
dm-0              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-1              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-2              0,00     0,00    0,00  134,00     0,00   570,00     8,51    22,80  170,18    0,00  170,18   1,63  21,80 // hier liegt /var drauf
dm-3              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-4              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-5              0,00     0,00    0,00    8,50     0,00    30,50     7,18     0,20   22,59    0,00   22,59  23,29  19,80 // rmeta_0 -> sdc
dm-6              0,00     0,00    0,00 1539,00     0,00  6156,00     8,00    43,62   30,51    0,00   30,51   0,14  22,00 // rimage_0 -> sda
dm-7              0,00     0,00    0,00    8,50     0,00    30,50     7,18     0,25   28,71    0,00   28,71  29,41  25,00 // rmeta_1 -> sdc
dm-8              0,00     0,00    0,00 1539,00     0,00  6156,00     8,00    34,88   23,16    0,00   23,16   0,12  18,80 // rimage_1 -> sdb
dm-9              0,00     0,00    0,00    8,50     0,00    30,50     7,18     0,04    4,94    0,00    4,94   4,94   4,20 // rmeta_2 -> sde
dm-10             0,00     0,00    3,00 1536,00    12,00  6144,00     8,00    38,14   26,94    2,67   26,99   0,11  17,60 // rimage_2 -> sdd
dm-11             0,00     0,00    0,00  203,00     0,00 12812,00   126,23    12,91   63,54    0,00   63,54   2,32  47,00 // ganzes LV
Ich hab eines der meta volumes auf eine SSD gegeben und da ist ein großer unterschied zu sehen (überraschung :D).

Frage mich aber weiterhin ob nicht der controller das bottleneck ist?

editediteditedit: So jetzt rechnen wir mal kurz: Man sieht das dm-11 bei der iostat ausgabe oben durschnittlich 65ms für einen Request gebraucht hat. Was mich jetzt sehr stutzig macht ist, dass diese Zeit etwa 3x so lang ist wie die Zugriffe auf die einzelnen Platten... Wird das gar nicht parallel gescheduled?

reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: Bandbreite vom SATA controller ermitteln

Beitrag von reox » 01.01.2017 17:32:01

So jetzt bin ich komplett verwirrt...
Nach einigem lesen hab ich herausgefunden, dass für MD Raids456 es einen stripe_cache gibt, welcher sehr viel performance bringen soll. Nun wurde das RAID über LVM angelegt, aber die verwenden ja auch nur MD im Hintergrund, demnach sollte es ja irgendwie zu setzen sein... Scheinbar ist dem aber nicht so, obwohl diese option in den Design specs von LVM2-raid definiert wird (siehe https://git.fedorahosted.org/cgit/lvm2. ... 2-raid.txt , die option heißt --stripecache).
Jetzt hab ich mal ein wenig weitergesucht und herausgefunden, dass LVM dmsetup verwendet. Dort kann man die option stripe_cache für die raid parameter übergeben. In einer VM hab ich das mal ausprobiert, also zuerst ein neues RAID 5 LVM angelegt, dann mit dmsetup reload einen neuen wert setzen:

Code: Alles auswählen

$ pvcreate /dev/sd{b,c,d}1
$ vgcreate rte /dev/sd{b,c,d}1
$ lvcreate -L 5G -n testraid --type raid5 rte
$ dmsetup table
rte-testraid_rimage_0: 0 5242880 linear 8:17 10240
rte-testraid: 0 10485760 raid raid5_ls 3 128 region_size 1024 3 254:0 254:1 254:2 254:3 254:4 254:5
rte-testraid_rmeta_2: 0 8192 linear 8:49 2048
rte-testraid_rmeta_1: 0 8192 linear 8:33 2048
rte-testraid_rmeta_0: 0 8192 linear 8:17 2048
rte-testraid_rimage_2: 0 5242880 linear 8:49 10240
rte-testraid_rimage_1: 0 5242880 linear 8:33 10240
$ dmsetup reload rte-testraid --table '0 10485760 raid raid5_ls 5 128 stripe_cache 16384 region_size 1024 3 254:0 254:1 254:2 254:3 254:4 254:5'
Mit dem jessie kernel crasht das jedoch:

Code: Alles auswählen

Jan  1 15:36:24 jessie kernel: [   73.182813] BUG: unable to handle kernel NULL pointer dereference at 0000000000000044
Jan  1 15:36:24 jessie kernel: [   73.183284] IP: [<ffffffffa02ca364>] raid5_set_cache_size+0x24/0xe0 [raid456]
Jan  1 15:36:24 jessie kernel: [   73.183611] PGD 0 
Jan  1 15:36:24 jessie kernel: [   73.183818] Oops: 0000 [#1] SMP 
Jan  1 15:36:24 jessie kernel: [   73.184152] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc crc32_pclmul ppdev aesni_intel parport_pc aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd parport pcspkr evdev serio_raw i2c_piix4 dm_raid raid456 async_raid6_recov async_memcpy raid1 raid10 md_mod async_pq async_xor battery snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore ac97_bus i2c_core xor async_tx raid6_pq video processor thermal_sys button ac autofs4 ext4 crc16 mbcache jbd2 dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci floppy psmouse libata scsi_mod e1000
Jan  1 15:36:24 jessie kernel: [   73.191499] CPU: 0 PID: 940 Comm: dmsetup Not tainted 3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u1
Jan  1 15:36:24 jessie kernel: [   73.191779] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jan  1 15:36:24 jessie kernel: [   73.192046] task: ffff88001a63ebe0 ti: ffff88001c074000 task.ti: ffff88001c074000
Jan  1 15:36:24 jessie kernel: [   73.192297] RIP: 0010:[<ffffffffa02ca364>]  [<ffffffffa02ca364>] raid5_set_cache_size+0x24/0xe0 [raid456]
Jan  1 15:36:24 jessie kernel: [   73.192836] RSP: 0018:ffff88001c077bf8  EFLAGS: 00010287
Jan  1 15:36:24 jessie kernel: [   73.193191] RAX: 0000000000001fef RBX: 0000000000000001 RCX: 0000000000000000
Jan  1 15:36:24 jessie kernel: [   73.193591] RDX: 0000000000000000 RSI: 0000000000002000 RDI: ffff88001a470010
Jan  1 15:36:24 jessie kernel: [   73.194003] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000005
Jan  1 15:36:24 jessie kernel: [   73.194397] R10: 000000000000000a R11: f000000000000000 R12: 0000000000002000
Jan  1 15:36:24 jessie kernel: [   73.194793] R13: ffff88001a605158 R14: ffff88001a470010 R15: ffffffffa02e405b
Jan  1 15:36:24 jessie kernel: [   73.195189] FS:  00007fa31e600800(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
Jan  1 15:36:24 jessie kernel: [   73.195760] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan  1 15:36:24 jessie kernel: [   73.196123] CR2: 0000000000000044 CR3: 000000001a475000 CR4: 00000000000406f0
Jan  1 15:36:24 jessie kernel: [   73.196536] Stack:
Jan  1 15:36:24 jessie kernel: [   73.196816]  0000000000000001 ffff88001d00816f 0000000000000004 ffff88001a605158
Jan  1 15:36:24 jessie kernel: [   73.197715]  ffff88001a470000 ffffffffa02e2e03 ffffffffa02e405b ffffc90000121040
Jan  1 15:36:24 jessie kernel: [   73.198610]  0000000000000000 ffff88001a605150 0000000000a00000 000000020000000c
Jan  1 15:36:24 jessie kernel: [   73.199508] Call Trace:
Jan  1 15:36:24 jessie kernel: [   73.199801]  [<ffffffffa02e2e03>] ? raid_ctr+0x813/0x13c9 [dm_raid]
Jan  1 15:36:24 jessie kernel: [   73.200182]  [<ffffffffa0115cbe>] ? dm_table_add_target+0x15e/0x430 [dm_mod]
Jan  1 15:36:24 jessie kernel: [   73.200579]  [<ffffffffa0118f5c>] ? table_load+0x11c/0x330 [dm_mod]
Jan  1 15:36:24 jessie kernel: [   73.200960]  [<ffffffffa0118e40>] ? retrieve_status+0x1d0/0x1d0 [dm_mod]
Jan  1 15:36:24 jessie kernel: [   73.201353]  [<ffffffffa0119af5>] ? ctl_ioctl+0x205/0x430 [dm_mod]
Jan  1 15:36:24 jessie kernel: [   73.201732]  [<ffffffffa0119d2f>] ? dm_ctl_ioctl+0xf/0x20 [dm_mod]
Jan  1 15:36:24 jessie kernel: [   73.202110]  [<ffffffff811bce4f>] ? do_vfs_ioctl+0x2cf/0x4b0
Jan  1 15:36:24 jessie kernel: [   73.202475]  [<ffffffff811717b9>] ? do_munmap+0x299/0x3a0
Jan  1 15:36:24 jessie kernel: [   73.202834]  [<ffffffff811bd0b1>] ? SyS_ioctl+0x81/0xa0
Jan  1 15:36:24 jessie kernel: [   73.203187]  [<ffffffff8151a568>] ? page_fault+0x28/0x30
Jan  1 15:36:24 jessie kernel: [   73.203542]  [<ffffffff8151854d>] ? system_call_fast_compare_end+0x10/0x15
Jan  1 15:36:24 jessie kernel: [   73.203934] Code: 0f 1f 80 00 00 00 00 0f 1f 44 00 00 41 56 8d 46 ef 49 89 fe 41 55 3d ef 7f 00 00 41 54 41 89 f4 55 53 48 8b 2f 0f 87 ad 00 00 00 <8b> 45 44 41 bd 07 00 00 00 8d 58 ff 89 da c1 fa 1f c1 ea 1d 01 
Jan  1 15:36:24 jessie kernel: [   73.210475] RIP  [<ffffffffa02ca364>] raid5_set_cache_size+0x24/0xe0 [raid456]
Jan  1 15:36:24 jessie kernel: [   73.211112]  RSP <ffff88001c077bf8>
Jan  1 15:36:24 jessie kernel: [   73.211425] CR2: 0000000000000044
Jan  1 15:36:24 jessie kernel: [   73.211750] ---[ end trace 3ff84edca236e2e5 ]---
Dazu habe ich auch einen Bugreport gefunden: https://github.com/coreos/bugs/issues/1400 der wohl gefixed ist.

Und erst nach einem Upgrade auf einen 4.x Kernel scheint es dann auch tatsächlich zu funktionieren (ich hab mal den aus sid genommen in der VM):

Code: Alles auswählen

Jan  1 15:44:56 jessie kernel: [   33.857805] md/raid:mdX: device dm-1 operational as raid disk 0
Jan  1 15:44:56 jessie kernel: [   33.857807] md/raid:mdX: device dm-3 operational as raid disk 1
Jan  1 15:44:56 jessie kernel: [   33.857807] md/raid:mdX: device dm-5 operational as raid disk 2
Jan  1 15:44:56 jessie kernel: [   33.858003] md/raid:mdX: allocated 3316kB
Jan  1 15:44:56 jessie kernel: [   33.858017] md/raid:mdX: raid level 5 active with 3 out of 3 devices, algorithm 2
Jan  1 15:44:56 jessie kernel: [   33.858017] RAID conf printout:
Jan  1 15:44:56 jessie kernel: [   33.858018]  --- level:5 rd:3 wd:3
Jan  1 15:44:56 jessie kernel: [   33.858019]  disk 0, o:1, dev:dm-1
Jan  1 15:44:56 jessie kernel: [   33.858019]  disk 1, o:1, dev:dm-3
Jan  1 15:44:56 jessie kernel: [   33.858020]  disk 2, o:1, dev:dm-5
Jan  1 15:44:56 jessie kernel: [   33.858316] created bitmap (3 pages) for device mdX
Jan  1 15:44:56 jessie kernel: [   33.913336] device-mapper: raid: 16384 stripe cache entries
OK, die Schreibgeschwindigkeit war in beiden fällen ziemlich gut (etwa bei 200MB/s), allerdings wurde auch auf die selbe physische platte geschrieben... Also jo, der Benchmark ist nicht wirklich aussagekräftig.

Nun dachte ich mir, wenn das in der VM ja zumindest klappt, kann man das ja auch mal am Livesystem ausprobieren. Dort rennt aber auch ein Jessie Kernel. Also hab ich die ganze Kiste mal auf stretch gezogen.

Jetzt wirds aber interessant: Selbst ohne den stripe_cache hat sich die Schreibgeschwindigkeit mehr als verdoppelt. Ich schreibe jetzt mit ~80-100MB/s auf das RAID.
Scheinbar hat sich in den neuen kernel extrem viel getan!
Also ich schätze mal der Controller ist wirklich nicht schuld aber entweder der MD Raid treiber oder der treiber für die hardware...

edit: stupid me :facepalm: Man muss auch dmsetup resume ausführen um dann tatsächlich auch die einstellungen zu aktivieren. dmsetup scheint auch so ein tool zu sein das nicht viel verwendet wird ;)
und tatsächlich bringt das wirklich nochmal viel. Schreiben geht jetzt auch mit ~150 bis 200MB/s.

Lustig, was so ein neuer kernel alles rausholt...

reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: Bandbreite vom SATA controller ermitteln

Beitrag von reox » 02.01.2017 14:48:32

Ok aber zurück zum Thema: Mir wurde gesagt der HP N54L kann eigentlich gar nicht 3GBit SATA ohne das man das BIOS patched. Laut Kernel log wird der Port jedoch mit 3Gbit initialisiert.
Gibt es eine Möglichkeit Herauszufinden was er jetzt tatsächlich hat? Wenn man ein Gerät hätte das mit voller Bandbreite lesen und schreiben könnte, wäre das einfach...

Benutzeravatar
sbruder
Beiträge: 326
Registriert: 24.06.2016 13:54:36
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Wallmersbach

Re: Bandbreite vom SATA controller ermitteln

Beitrag von sbruder » 02.01.2017 16:25:25

Code: Alles auswählen

root@zopf / # dmesg|grep SATA
[    0.689514] ata1: SATA max UDMA/133 cmd 0x10c0 ctl 0x10c8 bmdma 0x10e0 irq 17
[    0.689519] ata2: SATA max UDMA/133 cmd 0x10d0 ctl 0x10d8 bmdma 0x10e8 irq 17
[    0.690077] ata3: SATA max UDMA/133 cmd 0x1400 ctl 0x1408 bmdma 0x1420 irq 17
[    0.690080] ata4: SATA max UDMA/133 cmd 0x1410 ctl 0x1418 bmdma 0x1428 irq 17
[    1.018134] ata3: SATA link down (SStatus 0 SControl 300)
[    1.029166] ata4: SATA link down (SStatus 0 SControl 300)
[    1.495121] ata2.00: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.495134] ata2.01: SATA link down (SStatus 0 SControl 300)
[    1.495288] ata1.00: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.495302] ata1.01: SATA link down (SStatus 0 SControl 300)
→ 2 mal 6 Gbps und 2 mal leer

Benutzeravatar
Tintom
Beiträge: 1294
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Bandbreite vom SATA controller ermitteln

Beitrag von Tintom » 02.01.2017 16:34:29

reox hat geschrieben: Wenn man ein Gerät hätte das mit voller Bandbreite lesen
pv /dev/<controller> > /dev/null ?
reox hat geschrieben: und schreiben könnte [...]
pv /dev/zero > /dev/<controller> ?

reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: Bandbreite vom SATA controller ermitteln

Beitrag von reox » 02.01.2017 17:09:42

@sbruder: das sagt ja nur, dass der Kernel max. mit 3Gbit dort hinschreiben würde - aber nicht das der controller das auch tatsächlich packt. Wenn ich zB den 4-Port SATA Controller nehme der 3Gbit pro Kanal können sollte, wird der das nicht über den PCI bus bekommen, da der nur mit 66MHz taktet und 64bit angebunden ist. Die 4 Ports würden tatsächlich 1430MB/s brauchen, der PCI bus schafft nur 503MB/s...

@Tintom: Ja klar, /dev/null und /dev/zero - ich meinte aber eher ein Gerät das am SATA Port hängt und wie /dev/null bzw /dev/zero agiert. Ich kann ja nur testen wie schnell die Festplatten sind, an die Limits vom Controller selber werde ich ja vermutlich nicht kommen. Könnte natürlich 4 SSDs nehmen, hab ich aber nicht.

MSfree
Beiträge: 2639
Registriert: 25.09.2007 19:59:30

Re: Bandbreite vom SATA controller ermitteln

Beitrag von MSfree » 02.01.2017 19:05:31

reox hat geschrieben:Wenn ich zB den 4-Port SATA Controller nehme der 3Gbit pro Kanal können sollte, wird der das nicht über den PCI bus bekommen, .... der PCI bus schafft nur 503MB/s...
Zeig mir doch bitte mal einen SATA-Controller für den PCI-Bus, noch dazu einen, der 3GBit-Sata kann, modernere Motherboards, also 7 Jahre und jünger haben überhaupt keinen PCI-Bus mehr. Wir sind inzwischen bei PCIexpress 3.0 und der trasportiert lockere 8GBit/s pro Lane, bei einem x8-Controller wären das 64GBit/s.

reox
Beiträge: 1252
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: Bandbreite vom SATA controller ermitteln

Beitrag von reox » 02.01.2017 19:59:39

MSfree hat geschrieben:
reox hat geschrieben:Wenn ich zB den 4-Port SATA Controller nehme der 3Gbit pro Kanal können sollte, wird der das nicht über den PCI bus bekommen, .... der PCI bus schafft nur 503MB/s...
Zeig mir doch bitte mal einen SATA-Controller für den PCI-Bus, noch dazu einen, der 3GBit-Sata kann, modernere Motherboards, also 7 Jahre und jünger haben überhaupt keinen PCI-Bus mehr. Wir sind inzwischen bei PCIexpress 3.0 und der trasportiert lockere 8GBit/s pro Lane, bei einem x8-Controller wären das 64GBit/s.
Ok dann die frage anders herum: lässt sich herausfinden wie der controller angebunden ist? lspci scheint mir da keine große hilfe.
Der Netzwerkchip scheint mir tatsächlich über PCIe angebunden, siehe ausgabe von lspci:

Code: Alles auswählen

$ lspci -vvv -n -s 00:06.0
00:06.0 0604: 1022:9606 (prog-if 00 [Normal decode])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 24
	NUMA node: 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fe900000-fe9fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v2) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag+ RBE+
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
			ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible+
		RootCap: CRSVisible+
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0300c  Data: 41b1
	Capabilities: [b0] Subsystem: 103c:1609
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [110 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Kernel driver in use: pcieport
	Kernel modules: shpchp
Bei dem SATA controller steht da nix von PCIe...

edit: Nach dem Databook von AMD: http://support.amd.com/TechDocs/47283.pdf s.18 hängt der SATA Controller auf einer PCIe Lane. Nur sehen tu ich das mit lspci nicht, nur beim Ethernet (der auf der selben Lane hängt)?

Antworten