[linux-l] LVM: wie gejht dat?

[Schlomo Schapiro]

Hello Peter,

kannst Du nicht noch ein oder zwei Rechner dazustellen und Funktionen
auslagern ? Z.B. lohnt bei entsprechender load ein extra Rechner für eine
Datenbank, ein anderer für Filestorage und ein dritter für alles andere.
Zumindest NFS Server und Datenbank würde ich trennen (kannst sie ja mit ner
extra Netzwerkkarte direkt verbinden, wenn du dedizierte Bandbreite
zwischen den Rechnern willst.

Sowas kann man auch erst mal parallel aufziehen und dann in sehr kurzer
Zeit (downtime) migrieren.

Schlomo

Monday, January 6, 2003, 11:47:44 PM, you wrote:

PR> Hi,

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

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

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

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

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

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

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

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

PR> Gibt es die Moeglichkeit, daran etwas zu aendern?

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

PR> Es gruesst
PR> Peter

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


PR> _______________________________________________
PR> linux-l mailing list
PR> linux-l at mlists.in-berlin.de
PR> https://mlists.in-berlin.de/mailman/listinfo/linux-l


-- 
Best regards,
 Schlomo                            mailto:belug at schapiro.org