[HDD] Langsam bei kleinen Dateien - Alignment?

  • Thread starter Thread starter lichtmaschine
  • Start date Start date
L

lichtmaschine

Guest
Hallo,

Code: 
dd if=/dev/zero of=/testfile bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 236,411 s, 693 kB/s

Verbaut sind zwei WD RE4 1 TB Enterprise-Festplatten im SW-Raid1. Das Ergebnis kommt mir ein wenig langsam vor, ich vermute ein falsches Alignment, allerdings sehe ich den Fehler nicht:

Code: 
# sfdisk -l /dev/sda

Disk /dev/sda: 121601 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+   1991-   1992-  15998976   fd  Linux raid autodetect
/dev/sda2   *   1991+   2116-    125-   1000448   fd  Linux raid autodetect
/dev/sda3       2116+ 121601- 119485- 959761408   fd  Linux raid autodetect
/dev/sda4          0       -       0          0    0  Empty

Code: 
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/md2 during installation
UUID=955a16e4-4f2e-4353-8384-73a6baead163 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/md1 during installation
UUID=07680381-0dd3-44a8-ad56-057d368b0c35 /boot           ext4    defaults        0       2
# swap was on /dev/md0 during installation
UUID=2857768b-88cf-47a5-b072-97555be4caad none            swap    sw              0       0

Code: 
# hdparm -I /dev/sda

Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  268435455
	LBA48  user addressable sectors: 1953525168
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:      953869 MBytes
	device size with M = 1000*1000:     1000204 MBytes (1000 GB)
	cache/buffer size  = unknown
	Nominal Media Rotation Rate: 7200

Weitere Infos liefere ich, falls nötig, gerne nach. Hat vielleicht wer einen Tipp für mich?
 
Zwei Dinge, die beim ersten Überfliegen auffallen:

1. Ist das RAID1 im Hintergrund noch beim initialen Sync?
2. Was genau hast du mit dem 'oflag=sync' vor? Löst das u.U. einen entsprechenden Kernel-Call aus?
 
1. Nein, Sync hatte ich abgewartet.

Zu 2:

http://www.thomas-krenn.com/de/wiki/Direct_und_synchronized_I/O_unter_Linux said:
dd ermöglicht über die Angabe von iflag bzw. oflag Parametern diverse Optionen zum Lesen (iflag) sowie zum Schreiben (oflag) von Daten anzuführen. Die Parameter direct, dsync und sync sind hier vor allem für I/O Messungen interessant.
Click to expand...

Mit Performancemessungen bei Festplatten habe ich mich allerdings bisher weniger beschäftigt.
 
Falls du extrem viele kurze Zugriffe hast (z.B. IMAP-Server) kann es dir vielleicht helfen, den Stripe-Cache zu erhöhen.
Das ist allerdings ein wenig mit Vorsicht zu genießen, denn ich habe bisher nur wenig Informationen gefunden wie sich das auf die Datenintegrität bei plötzlichen Systemausfällen auswirkt.

Den aktuellen Wert (in Bytes) kannst du auslesen mit
cat /sys/block/mdX/md/stripe_cache_size
wobei "mdX" durch dein RAID-Gerät ersetzt werden muss.

Den Wert kannst du einfach mit einem
echo 2048 > /sys/block/mdX/md/stripe_cache_size
temporär zum Testen erhöhen, bootfest geht das über die sysctl.conf oder die mdadm.conf ;)

Der Standardwert ist normal 256 Bytes, ich habe mit einem Wert von 2048 Bytes schon ganz ordentlichen Performanceschub gesehen.
Denke auch daran, dass dieser Cache im RAM stattfindet und daher natürlich Arbeitsspeicher belegt.


Nachtrag:
Das Alignment sieht eigentlich gut aus, da die Festplatten intern mit 512 Bytes/Sektor arbeiten - da ist es praktisch egal, wo die Partitionstabelle anfängt.
Ansonsten kann man mit "parted" testen, ob die Partitionen vernünftig ausgerichtet sind.
 
Last edited by a moderator:
Bei meinem aktuellen Debian Wheezy gibt es die Datei gar nicht:

Code: 
ls /sys/block/md2/md/
array_size     degraded      metadata_version  reshape_position  sync_completed       sync_speed_min
array_state     dev-sda3      mismatch_cnt        resync_start      sync_force_parallel
bitmap         dev-sdb3      new_dev        safe_mode_delay   sync_max
bitmap_set_bits  layout          raid_disks        suspend_hi          sync_min
chunk_size     level          rd0            suspend_lo          sync_speed
component_size     max_read_errors  rd1            sync_action       sync_speed_max

Habe damals schon bei diesem Thema mitgelesen:

Postfix zu langsam

Hallo Gemeinde, suche schon seit einigen Nächten eine Lösung für meinen zu langsamen Postfix! Seit ich bei Hetzner bin bekomme ich keine Geschwindigkeit auf den Postfix, E-Maildurchsatz liegt bei 5 Mails innerhalb einer Sec.! Auf dem alten Server waren/sind es ca. 30 Mails innerhalb der...
serversupportforum.de serversupportforum.de

Die Unterschiede sind schon beachtlich, allerdings konnte ich aus dem Thema nicht wirklich eine Lösung rauslesen. Das Alignment scheint ja bei mir in Ordnung zu sein.
 
Lord Gurke said:
Falls du extrem viele kurze Zugriffe hast (z.B. IMAP-Server) kann es dir vielleicht helfen, den Stripe-Cache zu erhöhen.
Das ist allerdings ein wenig mit Vorsicht zu genießen, denn ich habe bisher nur wenig Informationen gefunden wie sich das auf die Datenintegrität bei plötzlichen Systemausfällen auswirkt.

[...]

Den Wert kannst du einfach mit einem
echo 2048 > /sys/block/mdX/md/stripe_cache_size
Click to expand...
Danke für den Tipp, hab es vorhin testweise auf dem Node eines Storage-Clusters (Softraid-5) gesetzt. Hier werden meist Dateien mit der Größe von ca. 600 KB abgerufen, aber auch sehr viele Dateien in der Größenordnung 2-8 KB.

Die I/O-Last ist tatsächlich ein Stückchen gesunken. Sind keine Luftsprünge (wobei das System generell schon ziemlich viel Tuning intus hat ^^), aber durchaus spürbar.
 
Der lazy init müsste schon abgeschlossen gewesen sein, kann mich nicht daran erinnern, diesen Prozess gesehen zu haben. Auf jedenfall ist das Ergebnis immer noch genau so schlecht, jemand eine Idee?
 
Zum Vergleich hier mein Wert ohne Raid auf einer standalone-Platte
Western Digital WD2500AAKX 250 GB (7200 U/min)

Code: 
root@fusi:/tmp# dd if=/dev/zero of=testfile bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 239,991 s, 683 kB/s

Ich würde daher vermuten die Größenordnung passt.

Mit blktrace sieht das so aus (hier ein einzelner 32k Request):

Code: 
252,1    1      171     3.072185613 15982  Q  WS 445399296 + 64 [dd]
252,1    1      172     3.072819276     0  C  WS 445399296 + 64 [0]
252,1    0      109     3.072900103   376  Q  WS 239484768 + 8 [jbd2/dm-1-8]
252,1    0      110     3.072907754   376  Q  WS 239484776 + 8 [jbd2/dm-1-8]
252,1    0      111     3.072909536   376  Q  WS 239484784 + 8 [jbd2/dm-1-8]
252,1    0      112     3.072911228   376  Q  WS 239484792 + 8 [jbd2/dm-1-8]
252,1    1      173     3.073165516     0  C  WS 239484768 + 8 [0]
252,1    1      174     3.073298610     0  C  WS 239484776 + 8 [0]
252,1    1      175     3.073367927     0  C  WS 239484784 + 8 [0]
252,1    1      176     3.073489808     0  C  WS 239484792 + 8 [0]
252,1    1      177     3.073520830   376  Q WBS 239484800 + 8 [jbd2/dm-1-8]
252,1    1      178     3.122237809     0  C  WS 239484800 + 8 [0]

Man sieht hier als Erstes den 32k-Requests von dd (64*512 Bytes, daher die 64), der sogar blitzschnell fertig war.
Darauf folgen aber noch 4 4k-Requests des Journals und schlussendlich ein Journal-Request mit gesetztem Barrier-Flag.

Unterm Strich braucht der einzelne 32k Request von dd bis alles fertig ist ~50ms. Davon schaffe ich 20 in einer Sekunde. Der Durchsatz ist also 32k*20/s=640k/s => passt.

Anders gerechnet sagt man, eine einzelne Platte schafft grob 100 IOPS, bei 6 IOPS pro 32k-request sind das (100/6*32k) 512kb/s.

Teste doch mal im Vergleich ohne Dateisystem direkt auf dem Raid (Achtung wegen Datenverlust).

schöne Grüße,
Nils
 
You must log in or register to reply here.
Back
Top