| View previous topic :: View next topic |
| Author |
Message |
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
 Posted: Fri May 12, 2006 9:25 am Post subject: [solved] Welche Werte habt ihr für iowait beim Kernelbau? |
 |
|
Moin,
ihr könnt mein Problem sicher schon erahnen. Mein System erzeugt extrem hohe Werte für iowait unter . Dies tritt bei allen I/O-lastigen Aktionen wie | Code: | | emerge, make && make install, gunzip usw. |
auf.
Sagt bitte nicht: "RTFM" oder "Nutz' mal die SuFu!" - ich hätte gerne erst einmal Vergleichswerte!
Zur Info:
| Code: | root@pir187> emerge info
Portage 2.0.54-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.6-r3, 2.6.16-gentoo-r7 i686)
=================================================================
System uname: 2.6.16-gentoo-r7 i686 AMD Athlon(tm) XP 3200+
Gentoo Base System version 1.6.14
dev-lang/python: 2.3.5-r2, 2.4.2
dev-python/pycrypto: [Not Present]
dev-util/ccache: [Not Present]
dev-util/confcache: [Not Present]
sys-apps/sandbox: 1.2.12
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils: 2.16.1
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS=""
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /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 /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/overlay/local"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext 7zip X a52 aac alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt cups curl dri dts dvb dvdr eds emboss encode exif expat fam ffmpeg flac foomaticdb fortran gd gdbm gif glut gpm gstreamer gtk2 hal idn imagemagick imlib ipv6 isdnlog java jpeg junit kde lcms libg++ libwww live lm_sensors mad matroska mikmod mmx mmxext mng motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png pppd python qt quicktime readline real recode reflection samba scanner sdl session spell spl sse sse2 ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb v4l vorbis win32codecs wxwindows xine xml2 xmms xorg xv xvid zlib linguas_de userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS |
| Code: | root@pir187> hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0 |
| Code: | root@pir187> hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 2000 MB in 2.00 seconds = 1000.26 MB/sec
Timing buffered disk reads: 206 MB in 3.01 seconds = 68.47 MB/sec |
Im Kernel habe ich folgende wie ich finde relevante Optionen fest einkompiliert aktiviert:
| Code: | [x] ATA/ATAPI/MFM/RLL support
[x] Enhanced IDE/MFM... support
[x] Include IDE/ATA-2 DISK support
[x] Use multi-mode by default
[x] Include IDE/ATAPI CDROM support
[x] generic/default IDE chipset support
[x] PNP EIDE support
[x] PCI IDE chipset support
[x] Generic PCI IDE support
[x] Generic PCI bus-master DMA support
[x] Use PCI DMA by default when available
[x] AMD and nVidia IDE support |
Mit diesen Settings habe ich die hohen Werte für iowait. Wie schauen Eure Werte, evtl. bei gleichem Grundsystem, aus?
Danke schon mal, pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788
Last edited by pir187 on Sun Jul 02, 2006 4:00 pm; edited 1 time in total |
|
| Back to top |
|
 |
schmutzfinger
Veteran
Joined: 26 Oct 2003
Posts: 1287
Location: Dresden/Germany
|
| Posted: Fri May 12, 2006 1:32 pm Post subject: |
|
|
| Wo steht diese böse hohe Zahl in top? Was ist hoch? In meinem top hab ich kein iowait gefunden und in der manpage steht dieses Wort auch nicht drinne. Ich hab kein vergleichbares System aber ich denke mal das viele nicht wissen welchen Wert du meinst, und mit dem Wert "hoch" vergleichen ist sowieso schonmal ziemlich schwer. |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Fri May 12, 2006 2:00 pm Post subject: |
|
|
Bei deinem IDE-Kramm kannst du aber einiges rausschmeissen. Generic-IDE etc.
_________________
Just you and me strogg! |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Fri May 12, 2006 2:07 pm Post subject: Re: Welche Werte habt ihr für iowait beim Kernelbau? |
|
|
| pir187 wrote: | Mein System erzeugt extrem hohe Werte für iowait unter . Dies tritt bei allen I/O-lastigen AktionenIm Kernel habe ich folgende wie ich finde relevante Optionen fest einkompiliert aktiviert:
| Code: | [x] ATA/ATAPI/MFM/RLL support
[x] Enhanced IDE/MFM... support
[x] Include IDE/ATA-2 DISK support
[x] Use multi-mode by default
[x] Include IDE/ATAPI CDROM support
[x] generic/default IDE chipset support
[x] PNP EIDE support
[x] PCI IDE chipset support
[x] Generic PCI IDE support
[x] Generic PCI bus-master DMA support
[x] Use PCI DMA by default when available
[x] AMD and nVidia IDE support |
Mit diesen Settings habe ich die hohen Werte für iowait. Wie schauen Eure Werte, evtl. bei gleichem Grundsystem, aus? |
Definiere 'hoch' bitte.
Ich hab je nach System irgendwo zwischen 0.0-0.5% wa und 90% wa (SCSI-System), beschweren kann ich mich über deren Performance aber trotzdem nicht.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Fauli
l33t
Joined: 24 Apr 2004
Posts: 760
Location: Moers, Germany
|
| Posted: Fri May 12, 2006 6:32 pm Post subject: |
|
|
Du kannst auch mal einen anderen I/O-Scheduler testen, beispielsweise mit: | Code: | | echo deadline >/sys/block/hda/queue/scheduler |
Der Scheduler muss natürlich fest im Kernel oder als Modul geladen sein. | Code: | CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_IOSCHED="anticipatory" |
_________________
Do your part to beautify the web! Turn off link underlining! |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Fri May 12, 2006 9:40 pm Post subject: |
|
|
Hallo @all.
Sorry für die ungenaue Angabe. Also, mit den genannten Kerneloptionen befindet sich das System, wenn ich z.B. gerade ein ausführe und der Zähler am Ende des Vorganges dann von 0 bis 100% läuft, so locker im Bereich von 70% wait-Auslastung. Das ist der Anteil, zu dem das System auf IO-Vorgänge warten muss.
| Code: | top - 23:38:26 up 9 min, 5 users, load average: 0.80, 1.68, 1.21
Tasks: 108 total, 1 running, 106 sleeping, 0 stopped, 1 zombie
Cpu(s): 2.2% us, 0.4% sy, 0.0% ni, 0.0% id, [b]96.6% wa[/b], 0.6% hi, 0.2% si
Mem: 904600k total, 728700k used, 175900k free, 46348k buffers
Swap: 2008084k total, 0k used, 2008084k free, 498588k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
202 root 15 0 0 0 0 D 0.2 0.0 0:00.09 pdflush
11806 kay 18 0 1804 444 300 D 0.2 0.0 0:03.44 gunzip
949 root 10 -5 0 0 0 D 0.0 0.0 0:00.00 reiserfs/0
11823 kay 16 0 2084 1128 856 R 0.0 0.1 0:00.04 top
11835 root 18 0 2660 1608 508 D 0.0 0.2 0:00.00 hddtem |
Dieser Anteil (Auszug zeigt Stand während Entpackens einer 5GB gzip-Datei) schwankt so um 70%.
Vorhin habe ich einen Test gemacht und habe mal | Code: | | AMD and nVidia IDE support |
aus der Konfig rausgenommen. Plötzlich gab es im Schnitt nur noch ca. 10% wait-States, dafür war die Platte arschlahm. hdparm -tT brachte eine Wertekombination von 1150MB/s zu 4MB/s. Da stehen sonst 1100MB/s zu 70MB/s. reiserfsck meckerte aber beim Start rum, dass kein DMA verfügbar wäre. Es muss also irgendwie an dem nVidia-Treiber liegen. Vielleicht beisst er sich mit dem generic-Treiber? Ich teste das gleich mal weiter aus.
@fauli: ich habe schon sämtliche Scheduler getestet, es war jedes Mal das selbe. Wenn ich z.B. mit XMMS Webradio höre und nebenbei ein emerge-Vorgang ausführe, stockt der Radioempfang manchmal, wenn die Netzlast des Vorganges schon vorbei ist und dann von 0 bis 100% gezählt wird. Deutet auch auf IO-Probleme hin.
Deshalb nehme ich den anticipatory-Scheduler. Der interne Timer des Kernels steht auf 1000Hz und ist als Preemptible Kernel eingestellt. Preempt Big Kernel Lock ist ebenfalls gewählt.
Der Kernel kompiliert gerade neu...
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Fri May 12, 2006 10:50 pm Post subject: |
|
|
Ein neuer Kernel ohne | Code: | | generic/default IDE chipset support |
und | Code: | | Generic PCI IDE support |
hat keine Verbesserung gebracht. Die iowait-Rate liegt beim Entpacken eines gzip2-Archives bei 100%! Das ist sicher nicht normal, oder?
*ratlos*
pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
pepinot
n00b
Joined: 03 May 2005
Posts: 23
|
| Posted: Fri May 12, 2006 11:41 pm Post subject: |
|
|
Hallo pir187.
Deine Kernel-Config scheint IMHO in Ordnung zu sein. Dagegen machen mich deine HD-Einstellungen etwas stutzig.
| Quote: | root@pir187> hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0 |
Versuch doch zunächst einmal, etwas "konservativere" Werte einzustellen ("unmaskirq = 0 (off)", "IO_support = 0 (16-bit)"), auch wenn dies zunächst auf Kosten der Leistung geht. Vielleicht liegt hier ein Problem. Just a guess.
Gruß,
pepinot |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Sat May 13, 2006 1:37 am Post subject: |
|
|
| pir187 wrote: | | Die iowait-Rate liegt beim Entpacken eines gzip2-Archives bei 100%! Das ist sicher nicht normal, oder? |
Natürlich ist das normal. Es kann entweder die CPU oder die Festplatte der limitierende Faktor sein. In diesem Fall ist das halt die Festplatte. Das bedeutet, dass die CPU die Daten schneller entpacken kann als sie auf die Platte geschrieben werden können. |
|
| Back to top |
|
|
misterjack
Veteran
Joined: 03 Oct 2004
Posts: 1655
|
| Posted: Sat May 13, 2006 3:31 am Post subject: |
|
|
edit: müll geschrieben
_________________
„Meine Meinung steht fest! Bitte verwirren Sie mich nicht mit Tatsachen.“
Last edited by misterjack on Sat May 13, 2006 1:09 pm; edited 1 time in total |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sat May 13, 2006 8:25 am Post subject: |
|
|
@misterjack: unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states.
das ist genau das gegenteil von dem, was ich unter gentoo erlebe. wenn ich einen i/o-lastigen vorgang starte, ist das ganze system dann zeitweise lahm gelegt. für emerge nutze ich tmpfs (siehe wiki-eintrag "emerge beschleunigen") und niceness 19! trotzdem stockt das system, wenn ich software aktualisiere. das ist auf keinen fall normal! ich bin kein gentoo-dev, aber mein bisheriges it-leben hat mir soviel intuition beigebracht, um das festzustellen.
jetzt müsste ich nur noch wissen, woran es liegen könnte. wie gesagt, unter kubuntu rennt das system, unter gentoo stockt es i/o-mäßig.
ich bin für alle vorschläge offen, die mir helfen könnten! danke schon mal.
vg, pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
mrsteven
Veteran
Joined: 04 Jul 2003
Posts: 1938
|
| Posted: Sat May 13, 2006 9:34 am Post subject: |
|
|
Hmm, hast du CONFIG_PREEMPT aktiviert? Damit sollte das System etwas reaktionsschneller werden...
_________________
Unix philosophy: "Do one thing and do it well."
systemd: "Do everything and do it wrong." |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sat May 13, 2006 10:01 am Post subject: |
|
|
Ja, das habe ich:
| Code: | root@pir187> cat /usr/src/linux/.config | grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y |
.
Ist schon so, seit ich mein System neu installiert hatte. Leider reagiert es auch seit damals so träge unter Last  .
pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Sat May 13, 2006 11:33 am Post subject: |
|
|
| pir187 wrote: | | unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states. |
Das ist auch normal. In diesem Fall ist eben die CPU der limitierende Faktor.
Das bedeutet, dass das Komprimieren CPU-intensiver ist als das De-Komprimieren. |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sat May 13, 2006 1:43 pm Post subject: |
|
|
| Quote: | | Code: | | unter kubuntu dapper drake flight7 habe ich beim gzippen eines tar-files 100% cpu-last und 0% iowait-states. |
Das ist auch normal. In diesem Fall ist eben die CPU der limitierende Faktor. |
Ja, das ist ja auch richtig, dass die CPU ausgelastet wird - soll sie ruhig. Aber hier tritt eben nicht das Phänomen auf, dass so lange auf die Festplatte gewartet werden muss. Ich habe jetzt mehrere Systeme getestet: meins mit Gentoo und Kubuntu, mein Notebook (Samsung P35 XVM 1600 III) und einen Rechner an meiner Hochschule. Kein anderer Rechner stockt so und erzeugt so oft solch hohe iowait-Werte. Es ist also definitiv ein Problem meiner aktuellen Kernelkonfiguration.
Ich nutze einen monolithischen Kernel, der alle Funktionen einkompiliert hat. Aber daran sollte es nicht liegen, oder?
Unter Kubuntu werden die Module | Code: | | ide_generic, ide_cd, ide_disk, generic und scsi_mod |
geladen. Komisch, denn das Modul für "AMD/nVidia chipset" wird von Kubuntu nicht als benötigt erkannt. Als ich es unter Gentoo weggelassen habe, hatte sich auch nichts verändert .
Ich bin echt ratlos, ich dachte, ich habe das Thema "Kernel kompilieren" halbwegs im Griff...
*ratlos* pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Sat May 13, 2006 2:35 pm Post subject: |
|
|
| pir187 wrote: | | Ja, das ist ja auch richtig, dass die CPU ausgelastet wird - soll sie ruhig. Aber hier tritt eben nicht das Phänomen auf, dass so lange auf die Festplatte gewartet werden muss. Ich habe jetzt mehrere Systeme getestet: meins mit Gentoo und Kubuntu, mein Notebook (Samsung P35 XVM 1600 III) und einen Rechner an meiner Hochschule. Kein anderer Rechner stockt so und erzeugt so oft solch hohe iowait-Werte. Es ist also definitiv ein Problem meiner aktuellen Kernelkonfiguration. |
Mir ist das alles ehrlich gesagt viel zu schwammig. Erst hast du vom Komprimieren gesprochen, dann vom De-Komprimieren. Dann hast du von Ubuntu gesprochen und nicht geschrieben, welche Befehle du auf welchem System ausgeführt hast.
Du kannst Gentoo und Ubuntu hinsichtlich IO-lastiger Aktionen nur vergleichen, wenn du
(1) beide Systeme auf derselben Hardware laufen lässt
(2) bei beiden Systemen der DMA-Modus funktioniert
(3) wenn du darauf achtest, dass die Systeme vor dem Test jeweils idle sind
(4) für den Test denselben Befehl mit denselben Eingabedaten verwendest.
Grundsätzlich kann man bei der Kernelkonfiguration hinsichtlich der Festplatte nicht viel falsch machen. Es ist absolut ausreichend, wenn der DMA-Modus beim Festplattenzugriff funktioniert. Alles andere ist für einen einzelnen Test unerheblich. Für das Komprimieren oder das De-Komprimieren einer einzelnen Datei auf einem System, das ansonsten idle ist, ist die Wahl des IO-Schedulers beispielsweise völlig unerheblich.
Hier ein paar Beispiele für einzelne Tests:
* Auf einem idle-System updatedb laufen lassen. Das ergibt im wesentlichen 0% CPU und 100% iowait auf allen Systemen, egal wie schnell CPU und Festplatte sind.
* Auf einem idle-System emerge --metadata laufen lassen. Ist für den Test nicht geeignet, weil unter Ubuntu nicht möglich, aber auch hier wird bei den meisten Systemen die Festplatte der limitierende Faktor sein, wenn auch nicht ganz so krass wie bei updatedb.
* auf einem idle-System gzip für eine einzelne Datei, die Zufallsdaten enthält, laufen lassen. Anschliessend dann gunzip. Hier kann der limitierende Faktor je nach Hardware entweder die CPU oder die Festplatte sein. Aber das Komprimieren ist CPU-intensiver als das De-Komprimieren. Und gzip -9 ist CPU-intensiver als gzip -1. Und bzip2 hat Modi, die noch CPU-intensiver als gzip selbst bei höchster Kompressionsstufe sind.
Wenn du also sowohl unter Ubuntu als auch unter Gentoo auf derselben Hardware jeweils mit funktionierendem DMA-Modus und jeweils 100% idle denselben Befehl mit denselben Eingabedaten ausführst, und du dann während der Ausführung des Befehls eine signifikante Abweichung bei %cpu und %iowait feststellst, dann stimmt etwas nicht. Aber ich würde mal vermuten, dass du so etwas nicht festellen wirst!
Ein ganz anderes Thema ist das "Gefühl" bezüglich der Desktop-Reaktionszeit bzw. der "Interaktivität". Das ist alles andere als trivial und läßt sich nicht mal eben mit top oder vmstat messen. Auch die relevanten Kernel-Optionen sind in diesem Fall vielfältiger.
Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen.
Edit: Stockende Soundausgabe ist übrigens wieder ein anders Thema, denn das kann etwas mit der Desktop-Interaktivität zu tun haben, muss aber nicht. Es kann sich auch um Treiber- oder Interrupt-Probleme handeln, obwohl die Desktop-Interaktivität grundsätzlich in Ordnung ist. |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sun May 14, 2006 8:37 am Post subject: |
|
|
| Quote: | | Mir ist das alles ehrlich gesagt viel zu schwammig. Erst hast du vom Komprimieren gesprochen, dann vom De-Komprimieren. Dann hast du von Ubuntu gesprochen und nicht geschrieben, welche Befehle du auf welchem System ausgeführt hast. |
Ich habe das seltsame Verhalten meines Systems bei mehreren Aufgaben (tar, gzip, gunzip), aber unter Verwendung der selben Befehle beobachtet. Auch die verwendeten Befehle auf den jeweiligen Linux-Maschinen waren jeweils die selben.
| Quote: | Du kannst Gentoo und Ubuntu hinsichtlich IO-lastiger Aktionen nur vergleichen, wenn du
(1) beide Systeme auf derselben Hardware laufen lässt
(2) bei beiden Systemen der DMA-Modus funktioniert
(3) wenn du darauf achtest, dass die Systeme vor dem Test jeweils idle sind
(4) für den Test denselben Befehl mit denselben Eingabedaten verwendest. |
zu (1): Gentoo ist fest installiert, die Live-CD von Kubuntu lief auf diesem System - nutzt also dieselbe Hardware.
zu (2): Ist gegeben, siehe obere Ausgabe von hdparm.
zu (3): Waren sie. System gebootet, KDE fertig geladen, zu Konsole gewechselt, CPU idle, Befehl ausgeführt -> Beobachtung gemacht
zu (4): siehe erste Antwort
| Quote: | Grundsätzlich kann man bei der Kernelkonfiguration hinsichtlich der Festplatte nicht viel falsch machen. Es ist absolut ausreichend, wenn der DMA-Modus beim Festplattenzugriff funktioniert. Alles andere ist für einen einzelnen Test unerheblich. Für das Komprimieren oder das De-Komprimieren einer einzelnen Datei auf einem System, das ansonsten idle ist, ist die Wahl des IO-Schedulers beispielsweise völlig unerheblich.
|
Anscheinend reicht es nicht aus oder es klemmt noch woanders, denn die Konfiguration habe ich nun zig Mal geändert (generische Treiber rein/raus, nVidia-Treiber zusätzlich/allein rein/raus)
| Quote: | Hier ein paar Beispiele für einzelne Tests:
* Auf einem idle-System updatedb laufen lassen. Das ergibt im wesentlichen 0% CPU und 100% iowait auf allen Systemen, egal wie schnell CPU und Festplatte sind.
* Auf einem idle-System emerge --metadata laufen lassen. Ist für den Test nicht geeignet, weil unter Ubuntu nicht möglich, aber auch hier wird bei den meisten Systemen die Festplatte der limitierende Faktor sein, wenn auch nicht ganz so krass wie bei updatedb.
* auf einem idle-System gzip für eine einzelne Datei, die Zufallsdaten enthält, laufen lassen. Anschliessend dann gunzip. Hier kann der limitierende Faktor je nach Hardware entweder die CPU oder die Festplatte sein. Aber das Komprimieren ist CPU-intensiver als das De-Komprimieren. Und gzip -9 ist CPU-intensiver als gzip -1. Und bzip2 hat Modi, die noch CPU-intensiver als gzip selbst bei höchster Kompressionsstufe sind. |
Dass die CPU der limitierende Faktor ist, sehe ich ja, wenn ich die selbe Datei per Kubuntu (Gentoo-Partition nach Kubuntu gemountet) gunzippe. Dann rennt die CPU auf Anschlag und es gibt 0% waitstates. Das ist ok und mir egal. Unter Gentoo dreht die CPU aber Däumchen und die Zeit wird in den waitstates verbraten.
| Quote: | | Wenn du also sowohl unter Ubuntu als auch unter Gentoo auf derselben Hardware jeweils mit funktionierendem DMA-Modus und jeweils 100% idle denselben Befehl mit denselben Eingabedaten ausführst, und du dann während der Ausführung des Befehls eine signifikante Abweichung bei %cpu und %iowait feststellst, dann stimmt etwas nicht. |
Nun sind wir uns endlich einig. Denn das habe ich nun einmal beobachtet.
| Quote: | | Aber ich würde mal vermuten, dass du so etwas nicht festellen wirst! |
Leider habe ich das festgestellt. Sonst würde mein Topic nicht existieren.
| Quote: | | Ein ganz anderes Thema ist das "Gefühl" bezüglich der Desktop-Reaktionszeit bzw. der "Interaktivität". Das ist alles andere als trivial und läßt sich nicht mal eben mit top oder vmstat messen. Auch die relevanten Kernel-Optionen sind in diesem Fall vielfältiger. |
Die Trägheit, die ich an meinem Gentoo-System feststelle, finde ich nicht auf anderen Systemen. Sonst wäre es mir nicht aufgefallen.
Beispiel: ich lasse ein laufen. Während | Code: | | Calculating world dependencies |
geschrieben steht, dauert es z.B. 5s, bis ein neues Konsolenfenster in xterm geöffnet wird. Dabei ist die CPU-Last ca. 10%, der Rest waitstates. Die Platte macht 70MB/s im Zugriff (siehe hdparm-Ausgabe weiter oben). Auch ein Klick auf das K-Menü wird nicht unter 2s ausgeführt. Sorry, aber bei einem halbwegs aktuellen System mit 2,2GHz, konfiguriert als "Low latency Desktop", mit Preemptive Kernel und dem ganzen Spaß ist das sowohl subjektiv und objektiv langsam! Da kannst Du sagen, was Du willst. Das ist nicht nomal.
| Quote: | | Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen. |
Das ist nicht nötig, da ich meinen subjektiven Eindruck sehr wohl in den zwischen mehreren System unterschiedlichen Ausgaben von top bei Ausführung der selben Aufgaben bestätigt sehe.
pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sun May 14, 2006 8:40 am Post subject: konservativere hdparm-Einstellungen |
|
|
@pepinot: habe dies auch schon mal versucht. Es hat aber leider nichts gebracht. Zumal Kubuntu die selben "scharfen" Einstellungen nutzt.
pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Sun May 14, 2006 9:32 am Post subject: |
|
|
| pir187 wrote: | Die Trägheit, die ich an meinem Gentoo-System feststelle, finde ich nicht auf anderen Systemen. Sonst wäre es mir nicht aufgefallen.
Beispiel: ich lasse ein laufen. Während | Code: | | Calculating world dependencies |
geschrieben steht, dauert es z.B. 5s, bis ein neues Konsolenfenster in xterm geöffnet wird. Dabei ist die CPU-Last ca. 10%, der Rest waitstates. Die Platte macht 70MB/s im Zugriff (siehe hdparm-Ausgabe weiter oben). Auch ein Klick auf das K-Menü wird nicht unter 2s ausgeführt. Sorry, aber bei einem halbwegs aktuellen System mit 2,2GHz, konfiguriert als "Low latency Desktop", mit Preemptive Kernel und dem ganzen Spaß ist das sowohl subjektiv und objektiv langsam! Da kannst Du sagen, was Du willst. Das ist nicht nomal.
|
Für mich klingt das alles nicht ungewöhnlich. Wenn man nur eine einzelne IDE-Platte benutzt, kommt man schnell an die Grenzen. Du kannst in einer solchen Situation ja mal
laufen lassen. In der Spalte await kann man ablesen, wie lange es durchschnittlich dauert, bis die Festplatte eine Anfrage abgearbeitet hat. Bei einer IDE-Platte ohne NCQ stauen sich die Anfragen schnell (avgqu-sz), und so kommt es, dass es 5 s dauert, bis ein xterm geladen wird. Da kann man halt nichts machen, ausser mehr Daten im RAM zu cachen oder die Zugriffe auf mehrere Festplatten zu verteilen.
| pir187 wrote: |
| Quote: | | Ich würde aus diesem Grund vorschlagen, diese beiden Themen in der Diskussion zu trennen. |
Das ist nicht nötig, da ich meinen subjektiven Eindruck sehr wohl in den zwischen mehreren System unterschiedlichen Ausgaben von top bei Ausführung der selben Aufgaben bestätigt sehe.
|
Hör mal, es geht doch nicht darum, dass ich dir nicht glaube oder sowas. Es geht darum, dass diese beiden Dinge technisch gesehen total unterschiedlich sind, dass sie unterschiedliche Auswirkungen haben und auch andere Lösungen. Und bis jetzt habe ich noch keinen Hinweis darauf gefunden, dass es etwas mit "Desktop-Interaktivität" zun tun hat. So wie ich es sehe, bringt es zu diesem Zeitpunkt nichts, mit CONFIG_PREEMPT zu experimentieren. Das kann einer IDE-Platte ohne NCQ auch nicht helfen.
Aber mir ist das alles immer noch zu unkonkret. Aus diesem Grund würde ich vorschlagen, dass du einen kleinen Test sowohl unter Gentoo als auch unter Ubuntu machst und die Messwerte hier postest. Lasse "vmstat 5" oder "iostat -d -x hda 5" laufen. Und dann führe die folgenden Befehle aus und poste die Ausgaben der Befehle sowie jeweils mindestens eine Zeile der vmstat- oder iostat-Ausgabe während der Ausführung eines jeden Befehls.
| Code: | # time dd if=/dev/urandom of=random.data bs=1M count=100
# time gzip -1 random.data
# time gunzip random.data.gz
# time gzip -9 random.data
|
Mein System ist gerade alles andere als idle, aber wenn das später mal idle ist, poste ich meine Ergebnisse inklusive der groben Eckdaten der Hardware. |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Sun May 14, 2006 10:14 am Post subject: |
|
|
| Quote: | | Aber mir ist das alles immer noch zu unkonkret. Aus diesem Grund würde ich vorschlagen, dass du einen kleinen Test sowohl unter Gentoo als auch unter Ubuntu machst und die Messwerte hier postest. Lasse "vmstat 5" oder "iostat -d -x hda 5" laufen. Und dann führe die folgenden Befehle aus und poste die Ausgaben der Befehle sowie jeweils mindestens eine Zeile der vmstat- oder iostat-Ausgabe während der Ausführung eines jeden Befehls. |
OK, mache ich gleich mal.
Bis dann, pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Mon May 15, 2006 10:28 am Post subject: |
|
|
@sschlueter: könntest Du bei Deinem nächsten gleichzeitig mal laufen lassen und mir sagen, welcher Wert dort angezeigt wird, wenn z.B. | Code: | | Calculating world dependencies... |
oder | Code: | | >>> Updating Portage cache |
auf den Bildschirm steht? Das würde mir wenigstens mal einen Vergleichswert mit einem weiteren System geben.
Den Test mit den Programmen aus Deinem letzten Post mache ich gleich noch...
VG, pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Mon May 15, 2006 12:45 pm Post subject: |
|
|
Das verwendete System hat einen Athlon XP 1600+ mit 1Gb RAM und einer 80GB Seagate Barracuda IV.
| Code: | # hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 872 MB in 2.00 seconds = 435.19 MB/sec
Timing buffered disk reads: 104 MB in 3.02 seconds = 34.48 MB/sec |
Wenn ich "emerge --metadata" ausführe, dann habe ich 80% iowait, wenn das System vorher halbwegs idle gewesen ist.
Ich habe auch "iostat -x hda 5" laufen lassen, um zu überprüfen, warum dieser Befehl so unperformant ist. Das Performance-Problem bei "emerge --metadata" scheint daher zu kommen, dass relativ viele, relativ kleine Leseanfragen an die Festplatte gestellt werden, so dass diese ausgelastet ist, obwohl sie nur eine Netto-Leserate von 250-500KB/s schafft. Hier macht sich dann die Seek-Time der Platte bemerkbar.
Ich muss dazu sagen, dass ich keinerlei Massnahmen ergriffen habe, um Portage zu beschleunigen, insbesondere verwende ich keine tmpfs Laufwerke dafür.
Damit das Ergebnis nicht vom Filesystem Cache des Kerns verfälscht wird (Wenn ich "emerge --metadata" zweimal direkt hintereinander aufrufe, geht es beim zweiten Mal aufgrund gecachter Daten wahnsinnig schnell), habe ich den Cache vorher mit "dd if=/dev/hda of=/dev/null bs=1M count=1000" durcheinander gebracht.
Nebenbemerkung: Das ist auch der Grund, warum ich für den g(unzip) Test Zufallsdaten gewählt habe. Diesen Test kann man nämlich problemlos wiederholen, ohne den Filesystem Cache explizit durcheinander bringen zu müssen, indem man random.data(.gz) einfach löscht und durch Zufallsdaten erneut erzeugen lässt. |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Mon May 15, 2006 2:58 pm Post subject: |
|
|
Hier mal vorweg die einfachen Tests:
| Code: | root@pir187> time dd if=/dev/urandom of=random.data bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 22,7636 Sekunden, 4,6 MB/s
real 0m22.819s
user 0m0.002s
sys 0m21.818s
---
root@pir187> time gzip -1 random.data
real 0m8.687s
user 0m7.628s
sys 0m0.562s
---
root@pir187> time gunzip random.data.gz
real 0m1.510s
user 0m0.979s
sys 0m0.419s
---
root@pir187> time gzip -9 random.data
real 0m8.761s
user 0m7.892s
sys 0m0.558s |
pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
| Posted: Mon May 15, 2006 4:18 pm Post subject: |
|
|
| Auf welchem System ist das gewesen? Gentoo oder Ubuntu? Und wir brauchen auch die vmstat-Ausgaben während und kurz nach der Ausführung der einzelnen Tests. Kurz danach deshalb, weil die Schreibzugriffe auf die Platte eventuell etwas versetzt stattfinden, zumindest ist das bei mir so gewesen. Bei diesem Punkt bin ich mir nicht ganz sicher, ob das eine grundsätzliche Eigenschaft des Kernels oder eine Eigenschaft von ReiserFS ist. Ich vermute jedoch letzteres. |
|
| Back to top |
|
|
pir187
Guru
Joined: 19 Feb 2004
Posts: 309
Location: Papstdorf : Sachsen : Deutschland
|
| Posted: Mon May 15, 2006 10:17 pm Post subject: |
|
|
Das Ergebnis wurde auf meinem Gentoo-System erzielt. Kritisch oder zumindest nachdenklich finde ich den ersten Test: 4MB/s auf 'ner IDE-Festplatte (als Master ohne weiteres Gerät)? Scheint mir etwas wenig...
Ich melde mich am Donnerstag abend wieder, bin bis dahin nicht zu Hause.
Es wäre schön, wenn Ihr mir dann weiter helfen könntet, dem Problem auf den Grund zu gehen.
VG, pir187
_________________
Linux 2.6.24-gentoo-r8, Athlon XP 3200+@ASUS A7N8X-E Deluxe 2.0, 2GB MDT DDR-RAM PC3200@2,5-3-3-7, Gainward GF7800GS+ (G71), Creative Audigy 2 ZS, 2x Seagate 750 GB@RAID1 + LVM2
(sehr zufriedener) registrierter Linux-Nutzer #360788 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
