[linux-l] LVM: wie gejht dat?

[Steffen Dettmer]

* Peter Ross wrote on Tue, Jan 07, 2003 at 09:47 +1100:
> abloesend PostgreSQL) mit ReiserFS auf LVM geerbt. Drunter liegt ein
> Raid-5 mit einem vmware-IDE-Raid-Controller 

Ein IDE RAID5, ja? Ist natürlich nicht der I/O Hammer.

> und vier 80-GB-Platten.

Also recht neu, das System?

> Ein Problem ist die niedrige I/O-Bandbreite. Mein Vorgaenger hat mir
> erzaehlt, dass er im Testbetrieb beim Aufbau phantasische Werte erreicht
> hst, 

Was heißt das eigentlich? Ohne LVM und mit RAID 0+1 oder wie?

> 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.

Ja, langsam ist immer noch viel besser als gar nicht :)

> 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. 

Hast Du ein modernes PostgreSQL mit fsync und so verwendet und
viel Shared Memory zugewiesen? Soll ja angeblich viel bringen
(ich hab mal einen Server versuchsweise bißchen getunt, aber eine
herrausreißende Leistungssteigerung konnte ich in der kleinen
Testdatenbank nicht feststellen).

> (Ich kenne dies Phaenomen eigentlich nur aus der MS-Welt sonst,
> wo ploetzlich die Platte "prasselt" und das naechste Fenster
> fuenf Sekunden warten muss).

Das ist bei Datenbanken eigentlich komisch. PostgreSQL verwendet
auch so ein WAL, so ein Transaktionslog, da sollten dann alle
Änderungen an einer Stelle stehen. Damit ist (wenn ich das
richtig verstehe) der Plattencache nicht wichtig - macht die
Datenbank selbst recht effizient. 

> Dem habe ich nach googlen mit dem Eintrag
>   vm/bdflush=10 0 0 0 60 300 60 0 0
> It's slightly less efficient to do things this way, since the
> kernel will have fewer opportunities to combine writes. 

Bei Datenbankservern sollte das ja fast egal sein. Das DBMS kann
ja besser optimieren. Sollte es zuindestens :) 

> Nichts destotrotz ist die Performance nicht grossartig, wenn es zu
> ordentlichem Disk-I/O kommt. 

Ist das ein Hardware-RAID5 mit eigenem Controller je Platte? Oder
zwei Platten je Controller? Oder gar Software-RAID?

I/O Durchsatz von bestehenden Systemen zu erhöhen, wird wohl
nicht so ganz einfach ;)

> Besonders, wenn ueber NFS schon fleissig zugegriffen wird, die
> Datenbanken am Roedeln sind und dann als Sahnehaeubchen ein
> rsync ueber einen Verzeichnisbaum draufkommt. 

Komische Datenbank :) Sind Universal-Server? Das man mit rsync
und diversen NFS Aktionen einen Server platt kriegt, ist ja klar
:)

> Gibt es die Moeglichkeit, daran etwas zu aendern?

Längere Timeslices müßten bei sowas effizienter sein (höheres
Delay aber insgesammt schneller). Kann man bestimmt im Kernel
einstellen, oder? Keine Ahnung. Solaris hat ja bei den Servern
vergleichbar großes Slices; man merkt richtig, wie ne Shell
"ruckt", wenn der Server nur ein bißchen load hat. Spart
jedenfalls Contextswitches (ist ja ne teuere Operation). Nur mal
als Idee.

> Tips, wie ich die Probleme noch naeher eingrenzen kann, nehme
> ich auch gern entgegen. 

DMA und der ganze IDE Kram ist an, ja?

> Nur, Rechner aufschrauben und andere
> Platten rein oder anderes FS geht so gerade nicht, dazu stehen
> die Rechner zu weit weg..

Wieso? Machste ein Schraubenzieher-Script zum Umbauen, schickst
das per Mail (Schraubenzieher an die Mail anhängen) direkt an
Herrn Cron Daemon... :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.