[linux-l] LVM: wie gejht dat?

[Peter Ross]

Hi,

ich habe ebenfalls zwei NFS- und Datenbankserver (MySQL, zunehmend und
abloesend PostgreSQL) mit ReiserFS auf LVM geerbt. Drunter liegt ein
Raid-5 mit einem vmware-IDE-Raid-Controller und vier 80-GB-Platten.

Es ist bequem und laeuft auch ganz gut - bis auf die Performance.

Ein Problem ist die niedrige I/O-Bandbreite. Mein Vorgaenger hat mir
erzaehlt, dass er im Testbetrieb beim Aufbau phantasische Werte erreicht
hst, die im Alltagsbetrieb auf ca. 25% geschrumpft sind. Nun kann ich die
Teile, die physisch auf einem anderen Kontinent liegen, in San Diego,
nicht zum Testen ausser Betrieb nehmen, sie laufen 7x24 die Woche.

Gelegentlich kam es zu einem sogenannten "write storm", d.h. grosse Teile
des FS-Caches werden ploetzlich in einem Rutsch auf die Platte geschrieben
und das System knickt waehrenddessen ein. (Ich kenne dies Phaenomen
eigentlich nur aus der MS-Welt sonst, wo ploetzlich die Platte "prasselt"
und das naechste Fenster fuenf Sekunden warten muss).

Dem habe ich nach googlen mit dem Eintrag
  vm/bdflush=10 0 0 0 60 300 60 0 0
in der sysctl.conf ein wenig die Spitze nehmen koennen (sorry, dass es wie
ein Registry-Eintrag aussieht, sage keiner, Linux haette sowas nicht;-),
grob gesagt begrenzt es das Anwachsen des Caches und erwingt ein
reglmaessiges "Flushen".

Genaueres in http://www-106.ibm.com/developerworks/linux/library/l-fs8/ :

These new bdflush settings will cause kupdate to run every 0.6 seconds
rather than every 5 seconds. In addition, they tell the kernel to flush a
dirty buffer after 3 seconds rather than 30, the default. By flushing
recently-modified data to disk more regularly, these write storms can be
avoided. It's slightly less efficient to do things this way, since the
kernel will have fewer opportunities to combine writes. But for a busy
server, writes will happen more consistently, and interactive performance
will be greatly improved.

Nichts destotrotz ist die Performance nicht grossartig, wenn es zu
ordentlichem Disk-I/O kommt. Besonders, wenn ueber NFS schon fleissig
zugegriffen wird, die Datenbanken am Roedeln sind und dann als
Sahnehaeubchen ein rsync ueber einen Verzeichnisbaum draufkommt. Dann
steigt die Anzahl der Context-Switches je Sekunde (gesehen mit sar)
rapide an und es kommt zu erheblichen Verzoegerungen beim Abarbeiten von
Requests.

Gibt es die Moeglichkeit, daran etwas zu aendern?

Tips, wie ich die Probleme noch naeher eingrenzen kann, nehme ich auch
gern entgegen. Nur, Rechner aufschrauben und andere Platten rein oder
anderes FS geht so gerade nicht, dazu stehen die Rechner zu weit weg..

Es gruesst
Peter

On Mon, 6 Jan 2003, Stefan Bund wrote:

> "Baerwaldt, Ralf" <Ralf.Baerwaldt at Dresdner-Bank.com> writes:
> > Aus Erfahrung kann ich dir sagen, dass dir in diesem
> > Fall gar nichts anderes uebrig bleibt. Bei 7x24h Betrieb musst
> > du online resizing machen.
> [...]
> > Alles ohne Probleme (Source sind Suse-Distributionen).
>
> Super. Das beruhigt mich doch sehr, das noch jemand so ein System
> problemlos einsetzt ... Das online-resizing von ReiserFS scheint
> wirklich ziemlich stabil zu sein ...
>
> Stefan.
>
> --
> Stefan Bund, dipl.phys.  ---------------------------------------_-----
> Entwickler, Administrator ---              a   r   T   e   c  ,~|~-,
>                            ---             visual  solutions /_ |  /|
> sbund at artec-berlin.com      ---                              | 7~-/ |
> Fon: 030 / 884684-0          - Gottfried-von-Cramm-Weg 35-37 |Z  | /
> Fax: 030 / 884684-15          ---               14193 Berlin   ~-|/
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> https://mlists.in-berlin.de/mailman/listinfo/linux-l