# Miserable Schreibperfomance (iowait > 90%)

## malachay

Hallo,

habe jetzt seit ein paar Tagen einen AMD64 3000+auf einem Nforce4 Board. Mir gefiel allerdings die Perfomance bei Plattenzugriffen nicht

und habe deswegen mal einige Einstellungen überprüft bis hin zum Benchmark Bonnie++ gegen ein P4.

Tja als Ergebnis kann ich sagen das das AMD-Gespann recht flott lesen kann aber beim schreiben geht alles in die Knie. Wo ich bei den Schreibtests bei Bonnie++ auf dem P4 auf ~40% iowait komme, knallts mir auf den AMD immer auf ~97% . Die CPU hat indes natürlich so gut wie nichts zu tun (http://www.malachay.net/test_p4_amd64.html).

Habe jetzt schon diverse Einstellungen von hdparm durch (multicount, IO, DMA, Xfer) bringt alles nichts. Verschiedene Scheduler, deaktivieren von IRQ Shares bei IDE Devices, aber nichts hilft.

Hat jemand noch ein paar Tipps?

Scheduler:cfq

Kernel: 2.6.11ck-10 (2.6.11-gentoo-r10)

FS: XFS

Bios ist das aktuellste für das Board

```

hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   3208 MB in  2.00 seconds = 1603.44 MB/sec

 Timing buffered disk reads:  170 MB in  3.02 seconds =  56.36 MB/sec

```

```

disc0_args="-d1 -u1 -c3 -m16 -k1 -X70"

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  3 (32-bit w/sync)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  1 (on)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 65535/16/63, sectors = 122942324736, start = 0

```

Bonnie++ Ergebnise:

http://www.malachay.net/test_p4_amd64.html

Wie man sehr schön erkennen kann wird bei jedem Test die CPU recht wenig gefordert. Was bei den Lesetests auch voll OK ist, da sind die Werte ja auch recht gut, aber bei den Create-Tests bleiben die CPU Werte auch recht weit unten, iowait füllt sich bis zum Rand und das Ergebnis sind schlechte Werte.

iostat am AMD64 während bonnie++ schreibt.

```

avg-cpu:  %user   %nice %system %iowait   %idle

           0.50    0.00    4.46   95.05    0.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

a            0.00 6858.42  0.00 236.14    0.00 56637.62     0.00 28318.81   239.85   197.29  867.27   4.19  99.06

avg-cpu:  %user   %nice %system %iowait   %idle

           0.50    0.00    2.01   97.49    0.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

a            0.00 5483.42  0.00 262.31    0.00 45282.41     0.00 22641.21   172.63   159.37  718.28   3.83 100.55

```

P.S.

Der P4 scheint auch das eine oder andere Problem zu haben, das ist in diesem Fall aber irrelavant, ich will nur das Problem mit dem AMD64 lösen.  :Confused: 

----------

## hans0r

was für ein filesystem benutzt du denn?

----------

## malachay

XFS (bei dem AMD64 und bei dem P4)

----------

## Erlenmayr

 *malachay wrote:*   

> XFS (bei dem AMD64 und bei dem P4)

 

Wer hat dir denn erzählt, dass du das nehmen sollst?  :Very Happy: 

----------

## malachay

 *Erlenmayr wrote:*   

>  *malachay wrote:*   XFS (bei dem AMD64 und bei dem P4) 
> 
> Wer hat dir denn erzählt, dass du das nehmen sollst? 

 

???

Ich bin mit xfs sehr zufrieden. Wer hat denn dir erzählt das mir das jemand erzählt haben sollte?

Nachdem ich nun seit 4 Jahren Linux nutze und auch die "großen" Dateisysteme durchprobiert habe (ext3 war mir zu langsam, reiser hat mir dann doch mal einen bösen Crash verursacht) nutze ich xfs nun ca 1,5 Jahre und bin absolut zufrieden, es ist ausgeglichen in der Performance, und sollte dann doch mal was schiefgehen mit FS, konnte xfs_repair alles immer sehr gut wieder herstellen.

----------

## hans0r

ich nutze selbst auch xfs auf meinem notebook und bin höchst zufrieden. läuft schon seit monaten stabil.

@: kannst du starke fragmentierung deiner partition ausschliessen?

```

xfs_db -r /dev/[i]partition[/i]

[b]xfs_db>[/b] frag

```

was für ein "fragmentation factor" wird dabei gemessen? je niedriger der wert umso besser. ich hab grad z.B. 0.85%.

falls der wert sehr hoch sein sollte kannst du mit xfs_fsr die partition defragmentieren.

die zu defragmentierende partition muss dabei gemountet sein.

lies dir am besten vorher noch man xfs_fsr durch.

----------

## malachay

Hm, wohl eher niedrig  :Very Happy: 

```

actual 209390, ideal 208736, fragmentation factor 0.31%

```

----------

## hoschi

bin auch zufriedener xfs user, außer bei winzigen dateien skaliert es super (und da kommt nur portage in die quere, ich wurschtel ja nicht jeden tag auf /etc ), desktop + laptop

am dateisystem liegt das so oder so, sicher nicht

ehrlich gesagt haben aber nvidia-chipsätze unter linux nichts verloren, grundsätzlich nicht.

----------

## Stormkings

Ich glaube nicht, dass es am Nvidiachipsatz liegt. Ich habe einen Viachipsatz und beobachte das gleiche Problem. Besonders Portage ist durch die vielen kleinen Dateien sehr langsam. Ich habe genau wie "malachay" jegliche Scheduler, sowie Einstellungen von hdparm durchprobiert und keine Änderung feststellen können. Zeitweise war das System mal auf Reiser4, dass dann zwar beim "emerge --sync" sauschnell war, aber ansonsten die gleichen Symptome zeigte. Mittlerweile hab ich keine Ahnung mehr, bin mir aber fast sicher, dass es 2.6er Kernel gab (vor 2.6.6), die das Problem nicht hatten.

----------

## malachay

Der 2.6.12er Kernel bringt auch keine Verbesserungen. Ein paar Latenzzeiten sind zwar besser geworden, aber das iowait ist immernoch genauso hoch und somit der Durchsatz niedrig.  :Sad: 

----------

## new_nOOb

hallo hab auch mal ne frage zu ..benutze auch xfs und hab mal den frag befehl getestet.. bei mir kam folgendes..

actual 29434, ideal 2632, fragmentation factor 91.06%

was nicht sehr lustig aussieht.. wie kann ich das (sicher) defragmentieren???

hieß es nicht immer linux filesys fragmentieren net? (soll kein troll beitrag sein! sondern ist ernst gemeint.!)

sys läuft seit 1-2 monaten !

----------

## malachay

 *new_nOOb wrote:*   

> hallo hab auch mal ne frage zu ..benutze auch xfs und hab mal den frag befehl getestet.. bei mir kam folgendes..
> 
> actual 29434, ideal 2632, fragmentation factor 91.06%
> 
> was nicht sehr lustig aussieht.. wie kann ich das (sicher) defragmentieren???
> ...

 

 *hans0r wrote:*   

> 
> 
> falls der wert sehr hoch sein sollte kannst du mit xfs_fsr die partition defragmentieren.
> 
> die zu defragmentierende partition muss dabei gemountet sein.
> ...

 

xfs_fsr findest du im xfsdump Paket

----------

## malachay

Hab heute mal bei nem Freund mit einem P3 auf einem VIA Mainboard bonnie++ laufen lassen. Da komm ich zu ähnlich schlechten Ergebnissen betreffend iowait. (SuSE 9.3 2.6.11er Kernel).

Werd mal schauen das ich einen alten Kernel installier und dann noch mal testen.

Weiss jemand ob es bei SATA genauso schlecht aussieht?

----------

## SamStone

Was gibt iowait eigentlich überhaupt an?

Wie lange ein Prozess behindert wird weiterzulaufen, weil für ihn auf ein Gerät zugegriffen werden muss?

----------

## malachay

 *SamStone wrote:*   

> Was gibt iowait eigentlich überhaupt an?
> 
> Wie lange ein Prozess behindert wird weiterzulaufen, weil für ihn auf ein Gerät zugegriffen werden muss?

 

Kann dir das nicht so 100%ig erklären, das ein Kernelhacker bestimmt besser, aber grundsätzlich ist es wohl ein Kernelservice das einen Prozess zum warten zwingt bis der I/O Buffer abgearbeitet ist. Wenn das iowait sehr hoch ist muss der Prozess viel länger warten -> CPU bekommt nur wenig Daten ->Perfomance mies

Schau mal hier:

http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/ktechrf1/iowait.htm

----------

## malachay

Also:

Egal ob CK-Kernel, Love-Sources, mm-tree,Vanilla-2.6.12, Via oder Nvidia Chipsatz, das Ergbnis ist das selbe, alle haben die iowait Probleme.

Ich kam leider noch nicht dazu einen alten Kernel zu installieren(<2.6.6). Ich bekomme die Meldung das der Kernel zu alt sei. (FATAL Kernel too old) ich gehe davon aus das in dem Fall die Headers+glibc zu neu sind. Müsst ich vielleicht mal ein altes System installieren...vielleicht nehm ich ein aktuelles Debian *scnr*

----------

## malachay

Habe hier [1] einen interessanten Thread gefunden. Anscheinend tauchte dieses Problem schon im Kernel 2.5.60 auf  :Shocked:  !

Siehe auch hier[2]

Lösung gibts auch hier keine.

[1] http://www.linuxforen.de/forums/showthread.php?t=175905&page=1&pp=15&highlight=iowait

[2] http://kerneltrap.org/node/2251

----------

## 76062563

Ich habe exakt die gleichen Probleme wie sie hier beschrieben wurden...

Leider habe ich bis jetzt keine Lösung gefunden.

----------

## malachay

 *76062563 wrote:*   

> Ich habe exakt die gleichen Probleme wie sie hier beschrieben wurden...
> 
> Leider habe ich bis jetzt keine Lösung gefunden.

 

Es gibt dazu auch seit Ewigkeiten 2 Bugs auf bugzilla.kernel.org. Vielleicht sollte jeder dort sein Problem anhängen (inkl dmesg output und evtl noch ein paar Infos zur Hardware)

http://bugzilla.kernel.org/show_bug.cgi?id=2864

http://bugzilla.kernel.org/show_bug.cgi?id=3094

----------

## malachay

Also der 2.6.12-mm1 bringt schon einiges an Verbesserung!

Zwar ist die Queue immer noch randvoll, aber einige Festplattenintensive Aktionen laufen schon wesentlich schneller ab. (zB. große komprimierte Archive entpacken wie Kernel usw.)

Ich denke es könnte noch um einiges schneller gehen wenn die iowait queue nicht so voll wäre.

Der Benchmark zeigt zwar keine _starke_ Verbesserung, aber "fühlen" tut sich das System besser an ... keep on testing....

----------

## malachay

So, ich hab den iozone mal durchlaufen lassen:

```
iozone -a -g 1g -R
```

Getestet auf:

-AMD64

-Kernel 2.6.12-rc6-mm1

-CFQ

-XFS

-1 GB RAM

Ausgabe von emerge --info

```
Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.12-rc6-mm1 x86_64)

=================================================================

System uname: 2.6.12-rc6-mm1 x86_64 AMD Athlon(tm) 64 Processor 3000+

Gentoo Base System version 1.6.12

Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Jun 15 2005, 13:30:47)]

dev-lang/python:     2.3.5

sys-apps/sandbox:    [Not Present]

sys-devel/autoconf:  2.13, 2.59-r6

sys-devel/automake:  1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.5

sys-devel/binutils:  2.15.92.0.2-r10

sys-devel/libtool:   1.5.16

virtual/os-headers:  2.6.8.1-r4

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CFLAGS="-march=k8 -O2 -pipe -ftracer -funit-at-a-time -fforce-addr -fpeel-loops -funswitch-loops"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-march=k8 -O2 -pipe -ftracer -funit-at-a-time -fforce-addr -fpeel-loops -funswitch-loops"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror"

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="amd64 X acpi4linux alsa apache2 arts artswrappersuid audiofile avi bahamut bash-completion bitmap-fonts cdparanoia crypt cups dga dvd dvdr dvdread encode evms2 fbcon font-server gd gif gimpprint gphoto2 gpm gtk gtk2 hal imlib java javascript jpeg jpeg2k kde kdeenablefinal lm_sensors mad midi mozilla mp3 mpeg mpeg4 mplayer msql ncurses nptl nptlonly ogg oggvorbis ooo-kde opengl openssh pam perl php png ppds python qt quicktime readline samba scanner sdl ssl theora tiff transcode truetype truetype-fonts usb userlocales vorbis xine xpm xrandr xv xvid zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LINGUAS

```

Ergebnisse hier [1]

Ich denke ich kann soweit zufrieden sein, es ist alles recht flott unterwegs, vor allem sind die Verlaufskurven meistens recht gleichmäßig  :Smile: 

Ich teste noch auf 1-2 Rechnern und stell die Ergebnisse dann online.

[1] http://www.malachay.net/IoZone_AMD64_2.6.12-mm1_cfq_xfs_1024.htm

----------

## padarasa

Habe die selben Probleme. Bin erst seit einen halben Jahr dabei und dachte eigentlich, dass das einfach 'normal' ist.

Diese hohen iowait-Werte treten auf allen meinen Systemen auf (hab die Chipsätze nicht im Kopf, dürften alle VIA oder Intel sein, keine nvidia): 2x Athlon64, Sempron, 2x PentiumIII, Pentium M, PentiumII

Bei großen Dateien reagieren die Systeme merklich langsamer, Abstürze gibt es nicht. Das ganze ist mir erst aufgefallen, als ich auf Gigabit-LAN umgestellt habe und der Server (laut hdparm 50mb/s und das LAN schafft das auch) nur einen kleinen Teil seiner Leistung bringt.

Zu Abstürzen oder richtig dicken Hänger führt dies nicht (wie z.B. bei http://www.debianforum.de/forum/viewtopic.php?t=48212&highlight=iowait).

Es sind alles ext3-Syteme, mit Kernel 2.6.11.

Würde gerne den neuen Kernel testen... gibts schon ein ebuild? Als stable bekomme ich nur 2.6.11-gentoo-r11. Funktioniert ein Wechsel reibungsfrei und kann ich meine alte .config einfach übernehmen? Will mein Produktivsystem nicht unnnötig schrotten.

----------

## malachay

 *padarasa wrote:*   

> Habe die selben Probleme. Bin erst seit einen halben Jahr dabei und dachte eigentlich, dass das einfach 'normal' ist.
> 
> Diese hohen iowait-Werte treten auf allen meinen Systemen auf (hab die Chipsätze nicht im Kopf, dürften alle VIA oder Intel sein, keine nvidia): 2x Athlon64, Sempron, 2x PentiumIII, Pentium M, PentiumII
> 
> Bei großen Dateien reagieren die Systeme merklich langsamer, Abstürze gibt es nicht. Das ganze ist mir erst aufgefallen, als ich auf Gigabit-LAN umgestellt habe und der Server (laut hdparm 50mb/s und das LAN schafft das auch) nur einen kleinen Teil seiner Leistung bringt.
> ...

 

Es gibt neue gentoo-sources (unstable)

Und es gibt die mm-sources (auch unstable)

Die alte config File kannst du übernhmen, du musst allerding 'make oldconfig' im neuen Kernelverzeichnis aufrufen damit Neuerungen aufgenommen werden.

----------

