# [gelöst] Festplatten I/O bremst System aus

## astaecker

Moin,

mich stört es, dass, wenn emerge mal wieder ein neuen Kernel / kdelibs / mono entpackt, manche Sachen zu lange dauern. Dabei tritt fast ausschließlich Festplatten I/O auf, es liegt nicht am Rest des Systems. Programme, die schon laufen, laufen auch weiterhin in normaler Geschwindigkeit weiter. Aber z.B. das Starten von neuen Programmen dauert seine Zeit. Und dies ist was mich stört.

Den Gebrauch der CPU kann über "nice" priorisieren, kann man so etwas vielleicht auch für Festplatten I/O ?

P.S.: Mein System ist Stand der Technik: Intel Core 2 Duo, 1GB DDR2, SATA HDD.Last edited by astaecker on Tue Dec 12, 2006 11:45 am; edited 1 time in total

----------

## Keruskerfuerst

Welches Filesystem wird verwendet?

Und die make.conf posten.

----------

## astaecker

Seit neuestem XFS, aber das war bei ext3 auch so.

make.conf:

```
USE="3dnow 3dnowext a52 aac acpi apache2 -arts bash-completion bluetooth bzip2 css curl -cups dvdread dxr3 -eds -encode -esd ffmpeg -fortran -gnome -gpm -gstreamer -gtk hbci -ipv6 kdeenablefinal kdehiddenvisibility -ldap -mikmod mmx mmxext mono mplayer musicbrainz nsplugin nvidia -oss pdf pic -qt4 real samba -sdl slang sse sse2 svg threads x264 xcomposite xvid xvmc"

INPUT_DEVICES="keyboard evdev"

VIDEO_CARDS="i810 vesa"

# Host Setting

HOST="i686-pc-linux-gnu"

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs"

CXXFLAGS="${CFLAGS}"

# Advanced Masking

# ================

ACCEPT_KEYWORDS="~x86"

# Portage Directories

# ===================

PORTDIR_OVERLAY="/usr/local/portage"

source /usr/portage/local/layman-wrapper/make.conf

# Fetching files

# ==============

GENTOO_MIRRORS_BASE="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"

#GENTOO_MIRRORS="${GENTOO_MIRRORS_BASE}"

GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ${GENTOO_MIRRORS_BASE}"

#GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ${GENTOO_MIRRORS_BASE}"

# Synchronizing Portage

# =====================

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

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

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

# emerge options

EMERGE_DEFAULT_OPTS="--with-bdeps y --nospinner"

# Advanced Features

FEATURES="ccache parallel-fetch prelink"

MAKEOPTS="-j3"

CCACHE_SIZE="5G"

PORTAGE_NICENESS=19

LINGUAS="de"

#Mozilla-Firefox

LANGS="de"

#Logging

PORTAGE_ELOG_CLASSES="warn error log"

PORTAGE_ELOG_SYSTEM="save"
```

----------

## Keruskerfuerst

Hier liegt ein Fehler: ACCEPT_KEYWORDS="~x86" 

Muß heißen: ACCEPT_KEYWORDS="x86 ~x86" 

Vielleicht auch noch die Kernel config checken.

----------

## ConiKost

 *Keruskerfuerst wrote:*   

> Hier liegt ein Fehler: ACCEPT_KEYWORDS="~x86" 
> 
> Muß heißen: ACCEPT_KEYWORDS="x86 ~x86" 
> 
> Vielleicht auch noch die Kernel config checken.

 

Hä?

Das doch falsch ?!

Entweder ACCEPT_KEYWORDS="x86" oder ACCEPT_KEYWORDS="~x86" ?

Man darf doch nicht beides reinschreiben?

----------

## Finswimmer

Jaein. In die make.conf wird nur ~x86 geschrieben.

emerge --info interpretiert das dann als: x86 ~x86

Tobi

----------

## astaecker

 *Keruskerfuerst wrote:*   

> Hier liegt ein Fehler: ACCEPT_KEYWORDS="~x86" 
> 
> Muß heißen: ACCEPT_KEYWORDS="x86 ~x86"

 

Nein, das schon richtig so, obwohl deine Variante wahrscheinlich auch nicht falsch ist. Beides kenne ich nur von emerge --info.

 *Keruskerfuerst wrote:*   

> Vielleicht auch noch die Kernel config checken.

 

Hast du da etwas Bestimmtes im Sinn ?

Wie kann man eigentlich aus der Kommandozeile Text in die Zwischenablage kopieren ?

----------

## Keruskerfuerst

Kernel config:

ob eben die Treiber für den Chipsatz und die SATA Ports im Kernel enthalten sind.

----------

## astaecker

Ja, sind sie.

Ich habe ein Intel DG965MK Mainboard mit ICH8 Southbrigde. Im BIOS habe ich AHCI aktiviert und dementsprechend auch den Kernel konfiguriert:

```

#

# SCSI device support

#

# CONFIG_RAID_ATTRS is not set

CONFIG_SCSI=y

CONFIG_SCSI_PROC_FS=y

#

# SCSI support type (disk, tape, CD-ROM)

#

CONFIG_BLK_DEV_SD=y

# CONFIG_CHR_DEV_ST is not set

# CONFIG_CHR_DEV_OSST is not set

# CONFIG_BLK_DEV_SR is not set

# CONFIG_CHR_DEV_SG is not set

# CONFIG_CHR_DEV_SCH is not set

#

# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

#

# CONFIG_SCSI_MULTI_LUN is not set

# CONFIG_SCSI_CONSTANTS is not set

# CONFIG_SCSI_LOGGING is not set

#

# SCSI Transport Attributes

#

# CONFIG_SCSI_SPI_ATTRS is not set

# CONFIG_SCSI_FC_ATTRS is not set

# CONFIG_SCSI_ISCSI_ATTRS is not set

# CONFIG_SCSI_SAS_ATTRS is not set

#

# SCSI low-level drivers

#

# CONFIG_ISCSI_TCP is not set

# CONFIG_BLK_DEV_3W_XXXX_RAID is not set

# CONFIG_SCSI_3W_9XXX is not set

# CONFIG_SCSI_ACARD is not set

# CONFIG_SCSI_AACRAID is not set

# CONFIG_SCSI_AIC7XXX is not set

# CONFIG_SCSI_AIC7XXX_OLD is not set

# CONFIG_SCSI_AIC79XX is not set

# CONFIG_SCSI_DPT_I2O is not set

# CONFIG_SCSI_ADVANSYS is not set

# CONFIG_MEGARAID_NEWGEN is not set

# CONFIG_MEGARAID_LEGACY is not set

# CONFIG_MEGARAID_SAS is not set

CONFIG_SCSI_SATA=y

CONFIG_SCSI_SATA_AHCI=y

# CONFIG_SCSI_SATA_SVW is not set

# CONFIG_SCSI_ATA_PIIX is not set

# CONFIG_SCSI_SATA_MV is not set

# CONFIG_SCSI_SATA_NV is not set

# CONFIG_SCSI_PDC_ADMA is not set

# CONFIG_SCSI_HPTIOP is not set

# CONFIG_SCSI_SATA_QSTOR is not set

# CONFIG_SCSI_SATA_PROMISE is not set

# CONFIG_SCSI_SATA_SX4 is not set

# CONFIG_SCSI_SATA_SIL is not set

# CONFIG_SCSI_SATA_SIL24 is not set

# CONFIG_SCSI_SATA_SIS is not set

# CONFIG_SCSI_SATA_ULI is not set

# CONFIG_SCSI_SATA_VIA is not set

# CONFIG_SCSI_SATA_VITESSE is not set

CONFIG_SCSI_SATA_INTEL_COMBINED=y

# CONFIG_SCSI_BUSLOGIC is not set

# CONFIG_SCSI_DMX3191D is not set

# CONFIG_SCSI_EATA is not set

# CONFIG_SCSI_FUTURE_DOMAIN is not set

# CONFIG_SCSI_GDTH is not set

# CONFIG_SCSI_IPS is not set

# CONFIG_SCSI_INITIO is not set

# CONFIG_SCSI_INIA100 is not set

# CONFIG_SCSI_SYM53C8XX_2 is not set

# CONFIG_SCSI_IPR is not set

# CONFIG_SCSI_QLOGIC_1280 is not set

# CONFIG_SCSI_QLA_FC is not set

# CONFIG_SCSI_LPFC is not set

# CONFIG_SCSI_DC395x is not set

# CONFIG_SCSI_DC390T is not set

# CONFIG_SCSI_NSP32 is not set

# CONFIG_SCSI_DEBUG is not set

```

Das funktioniert auch alles soweit. Ich kann mich sonst nicht beklagen.

Aber das Problem bestand IMHO mit meinem alten Rechner. Wie ist es denn bei euch ?

----------

## Keruskerfuerst

Dies liegt vielleicht an den fehlenden LDFLAGS:

Meine lauten:

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

----------

## Finswimmer

 *Keruskerfuerst wrote:*   

> Dies liegt vielleicht an den fehlenden LDFLAGS:
> 
> Meine lauten:
> 
> LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,-znow -Wl,-s -Wl,--enable-new-dtags -Wl,--as-needed"

 

Wo hast du  die her? Im gentoo-wiki steht da nicht sonderlich viel.

Tobi

----------

## Keruskerfuerst

Aus man ld.

----------

## astaecker

Ich nutze ja eigentlich die sicheren LDFLAGS.

Ich kann mir vorstellen, dass optimierte LDFLAGS das Laden von Programmen etwas beschleunigt, aber nicht einen derartigen Ausfall verhindert (ich habe einen Portage Baum extrahiert und dabei Firefox unter KDE geladen, was eine knappe Minute gedauert hat).

----------

## Finswimmer

Wie sicher sind die denn? Will mir nicht mein System zerschießen.

Dass wir verschiedene Systeme haben, dürfte auch nichts machen?

Wenn nein, dann übernehm ich sie einfach mal  :Smile: 

Tobi

----------

## ConiKost

Hi!

Also ich habe schon öfters mit LDFlags Probleme gehabt ...

Das einzige, was bei mir wirklich und immer safe war ist "-Wl,-O1"

----------

## Keruskerfuerst

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

Ich habe mit diesem Flags das ganze System kompiliert. Also: Basis, X11, GTK,Gnome, VLC, ein paar kleine Programme.

Nur gst-plugins 0.8.11 (stabile Version) läßt sich damit nicht kompilieren. Da mußte ich -Wl,--as-needed weglassen. Ein Patch, der dieses Problem behebt, ist schon programmiert und wird gestestet.Last edited by Keruskerfuerst on Tue Nov 28, 2006 4:03 pm; edited 2 times in total

----------

## Klaus Meier

Ich denke mal, daß dein System einfach nicht mehr hergibt. Irgendwo ist halt Schluß mit CPU und Festplattenleistung. Bei mir war dieser Effekt unter XFS extrem, welches du ja auch benutzt. Da dauert ein emerge --sync stellenweise eine halbe Stunde, wenn man noch was anderes nebenher gemacht hat. Kann dir in diesem Zusammenhang nur zu ext3 raten. Reiser3 frißt mehr CPU-Leistungs als ext3.

Bezüglich der CFLAGS und LDFLAGS gab es ja vor kurzem einen Artikel in den GWN. Da stand ganz deutlich: Bei CFLAGS maximal -O2 -fomit-frame-pointer setzen. Und keine LDFLAGS. Alles andere bringt mehr Streß als Nutzen. Alles andere soll nutzen wer will, aber ich wäre mit solchen Empfehlungen vorsichtig.

Pakete, die von höheren Optimierungen profitieren und damit auch keine Probleme machen, setzen diese Flags meistens alleine.

----------

## dakjo

1.)Zusätzlich LDFLAGS halte ich für den falschesten Lösungsansatz. Weil

a)Es hier um Hardware geht.

b)Genau das zu mehr fehlern als nutzen führt.

2.)Mit bonnie datendurchsatz messen und dann kontrollieren ob dies auch beim emerge eintritt iostat.

3.)Ist Preempt im Kernel an?

4.)Filesystem ext3 oder reiserfs(kann ich nicht empfehlen aber ok), xfs ist für TB-FS gedacht.

5.)Was ist das für eine HDD? 5400/7500/10000rpm? Cache? Evtl ist die Platte einfach langsam?

----------

## astaecker

 *dakjo wrote:*   

> 2.)Mit bonnie datendurchsatz messen und dann kontrollieren ob dies auch beim emerge eintritt iostat.

 

Ohne Last:

```
                -------Sequential Output-------- ---Sequential Input-- --Random--

                -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---   

Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU

              100 55706 87.0 775381 75.7 1050321 65.6 57074 92.5 2661676 83.2 111129.6 100.0
```

Mit Last (extrahieren von gcc):

```
                -------Sequential Output-------- ---Sequential Input-- --Random--

                -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---

Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU

              100 57529 95.5 643002 57.8 471824 40.5 57846 95.1 804215 37.7 16893.1 16.9
```

Nun, ich kenne mich bonnie nicht so aus. Was bedeuten die Zahlen ?

 *dakjo wrote:*   

> 3.)Ist Preempt im Kernel an?

 

Jupp

 *dakjo wrote:*   

> 5.)Was ist das für eine HDD? 5400/7500/10000rpm? Cache? Evtl ist die Platte einfach langsam?

 

SAMSUNG SP2004C, 7200 UPM, 8MB Cache , 8.9 ms mittlere Zugriffszeit

----------

## Keruskerfuerst

Ich habe zwei Samsung SP1614C und mit diesem Festplatten läuft mein System (Athlon64 3200) sehr flüssig.

Ich benutze das Filesystem ext3 mit ein wenig Tuning. Einfach dazu mal die Boardsuche benutzen.

----------

## AROK

Hallo,

bei mir geht die CPU Last bei operationen mit großen Dateien immer auf 100%. Ist das normal? Sollte das mit DMA (ist auch AN) nicht eigentlich ohne große CPU Belastung gehen?

Gruß

AROK

----------

## Keruskerfuerst

Dies hängt auch vom verwendeten Filesystem ab.

----------

## AROK

 *Keruskerfuerst wrote:*   

> Dies hängt auch vom verwendeten Filesystem ab.

 

tritt bei mir auf bei ext3 zu ext3, ext3 zu fat und fat zu ext3.

----------

## Keruskerfuerst

Die Schreib/Leserate ist natürlich bei den Festplatten immer begrenzt.

Daran ist nichts zu ändern.

----------

## mrsteven

 *arlsair wrote:*   

> Den Gebrauch der CPU kann über "nice" priorisieren, kann man so etwas vielleicht auch für Festplatten I/O?

 

Wenn du den CFQ-IO-Scheduler verwendest, dann wirkt sich der nice-Wert so weit ich weiß auch auf die Festplattenzugriffe aus. Aber im Prinzip ist das mehr Symptombekämpfung, dein Problem ist die hohe CPU-Last bei Zugriffen auf die Platte.

Steht denn in deinen Logs etwas verdächtiges? Insbesondere die Kernelmeldungen nach dem Booten (dmesg) wären interessant.

----------

## astaecker

Ja, ich nutze den CFQ Scheduler. Aber bei mir tritt keine hohe CPU-Last bei Festplatten I/O auf. Im Gegenteil, die CPU Last geht eher gegen Null. 

Und ja, ich habe zwischenzeitig in der Tat festgestellt, dass meine Festplatte selten Aussetzer hat. Dann gibt es eine lustige Nachricht über einen Timeout, gefolgt von einem Soft-Reset der Festplatte. In der Zeit ist meine Festplatte natürlich komplett tot. Der Fehler tritt willkürlich auf und soll wohl was mit dem Treiber zu tun haben. Daher habe ich nun testweise zum AHCI Treiber auch den Intel Treiber eingebunden. Vielleicht ergänzt er ja den AHCI Treiber (, obwohl dies gegen mein Verständnis von AHCI als generischer SATA-Treiber spricht). Mal gucken, vielleicht löst dies auch mein eigentliches Problem.

----------

## mrsteven

Überprüfe mal die Verkabelung der Platte.

----------

## astaecker

 *mrsteven wrote:*   

> Überprüfe mal die Verkabelung der Platte.

 

Guter Ansatz, aber dafür tritt der Fehler zu selten auf.

Auch scheinen die hinzugefügten Intel Treiber zu helfen. Bis jetzt keine Soft-Reset mehr. Auch scheint sich mein eigentliches Problem damit gebessert zu haben.

----------

## Keruskerfuerst

Welche Art von Kabeln werden denn verwendet?

Ich hatte Standart SATA Kabel (Farbe: orange); diese funktionierten nicht besonders gut.

Dann ein paar Qualitäts SATA Kabel von Revoltec verwendet.

Diese funktionieren besser.

----------

## astaecker

Ich verwende das Kabel, dass dem Intel Mainboard beilag. Und das Mainboard macht einen überaus hochwertigen Eindruck.

----------

## astaecker

 *mrsteven wrote:*   

> Wenn du den CFQ-IO-Scheduler verwendest, dann wirkt sich der nice-Wert so weit ich weiß auch auf die Festplattenzugriffe aus.

 

Ich habe jetzt die Lösung gefunden. Seit 2.6.13 hat CFQ einen solche Funktionalität, die aber nicht über den normalen nice Befehl gesteuert wird, sondern über ein eigenes Programm namens "ionice". Mehr dazu in der Kernel-Doku (/usr/src/linux/Documentation/block/ioprio.txt).

Ich habe dann etwas gesucht und ein ebuild gefunden. Das war allerdings veraltet, deshalb hier ein neues ebuild:

```
# Copyright 1999-2004 Gentoo Technologies, Inc.

# Distributed under the terms of the GNU General Public License v2

# $Header: $

DESCRIPTION="Con Kolivas' ionice application for the cfq scheduler"

HOMEPAGE="http://ck.kolivas.org/"

SRC_URI="ionice.c"

RESTRICT="fetch"

LICENSE="GPL"

KEYWORDS="x86"

S=${WORKDIR}

pkg_nofetch() {

    einfo "Please copy the ioprio.txt from your kernel docu to your distfiles"

    einfo "cp /usr/src/linux/Documentation/block/ioprio.txt ${DISTDIR}/ionice.c"

    einfo "Then edit the file and remove all lines except the C code"

    einfo "nano ${DISTDIR}/ionice.c"

}

src_unpack() {

   cp ${DISTDIR}/${A} ${WORKDIR}

}

src_compile() {

   gcc -o ionice ionice.c

}

src_install() {

   mkdir ${D}/bin

   cp ionice ${D}/bin/ionice

}
```

Unter http://www.die.net/doc/linux/man/man1/ionice.1.html gibt es auch eine man-page. Ob die aktuell ist: Keine Ahnung. Auf jeden Fall funktioniert: "ionice -c3 Befehl" sehr gut bei mir.

Dank nochmal an alle für die Hilfen und Ideen.

----------

## AROK

Hallo,

was ist der "CFQ-IO-Scheduler"? Wann lohnt sich der Einsatz und welche Erfahrungen habt ihr damit gemacht?

Gruß

AROK

----------

## astaecker

Scheduler verteilen die zur Verfügung stehenden Resourcen (CPU, Festplatten IO, RAM) auf die Programme, die sie anfordern. Und hierbei gibt es verschiedene Strategien.

Z.B. war lange Zeit der "Anticipatory" Scheduler der Standard Scheduler vom 2.6 Kernel. Dieser war darauf optimiert, möglichst großen Durchsatz zu erzielen, also möglichst alle Resourcen möglichst gut auszunutzen. Dies gut für einen Server, aber auf einem Desktop-System ist schon ärgerlich, wenn du amarok starten willst und er erstmal noch irgendeinen Cronjob abarbeitet.

Deshalb ist heutzutage CFQ (Complete Fair Queue) der Standard-Scheduler. Der verteilt die Resourcen gleichmäßig auf die Aufgaben. Damit z.B. starten die Programme nicht schneller, aber du siehst, dass sich was tut. Und das erhöht die gefühlte Schnelligkeit eines Desktop-Systems.

P.S.: Wir sprechen hier meistens von Zeitunterschieden im Millisekunden-Bereich. Was sich halt ändert ist die gefühlte Schnelligkeit.

----------

## schachti

Interessant wäre es meiner Meinung, das Programm nice so zu patchen, daß automatisch ionice mit aufgerufen wird.

----------

