[linux-l] LVM: wie gejht dat?

[Schlomo Schapiro]

Hello Peter,

leider kann ich Dir auch keine konkreten Tipps geben, aber ein paar Ideen,
wo ich mal schauen würde:
- Network load zwischen File/DB Server und Webservern ?
- kernel oder user-space nfsd ?
- nfs v2 oder nfs v3 (geht zusammen mit kernel-nfsd)
- Kannst Du einen neuen Kernel installieren ? Wenn ja, vielleicht kannst Du
dann im Kernel was am Caching-Verhalten drehen (ich weiß, sehr vage ...)

Ist echt eine blöde Situation, so was. Das die Manager immer mehr Leistung
für 0 $ wollen ist leider nicht so selten.

Wie kam das alles eigentlich hoch ? Wurde die Performance der Webserver
plötzlich schlechter ?

Schlomo

Wednesday, January 8, 2003, 6:09:22 AM, you wrote:

PR> Hi Schlomo,

PR> On Tue, 7 Jan 2003, Schlomo Schapiro wrote:

>> Hello Peter,
>>
>> kannst Du nicht noch ein oder zwei Rechner dazustellen und Funktionen
>> auslagern ? ..

PR> Leider nicht. Sowie eine Loesung hinten ein $ hat, wird es hier kniffelig.
PR> Diese Einstellung wird sicher mittelfristig zum Arbeitsplatzwechsel eines
PR> System Administrators fuehren.

PR> Bis dahin werde ich allerdings damit noch zu leben haben..

PR> Deswegen denke ich drueber nach, ob es Moeglichkeiten gibt, die Server
PR> "schneller" zu machen.

PR> Was mir besonders aufstoesst, ist die Tatsache, dass bei vorhandener Last
PR> auf dem File- und DB-Server die daran "angeschlossenen" Webserver
PR> (Apache, PHP oder Perl) recht langsam erst Resultate liefern.

PR> Die Last auf den Webservern ist dabei unbedeutend, es sind vorallem die
PR> langsamen Antworten des Servers, wobei ich das generell sagen muss (nicht
PR> auf MySQL oder PostgreSQL oder NFS beschrankt).

PR> Mir scheint nach eigenen Linux-Erfahrungen (und Vergleichen mit anderen
PR> OSen wie Solaris und FreeBSD), dass die Strategie des Swappens und Cachen
PR> von Files nicht besonders optimal ist. Wenn ich daran etwas tun koennte,
PR> waere nicht schlecht.

PR> Linux verwendet ja, wie andere Betriebssysteme auch, nichtgenutzten
PR> Hauptspeicher, um Filesysteme zu cachen. Da meine Server (und auch andere
PR> Konfigurationen in der Vergangenheit) daran krankten, dass bei
PR> einigermassen vorhandener Last neue Prozesse eine recht lange
PR> "Anlaufphase" hatten, vermute ich, dass es dem Kernel schwerfaellt, dafuer
PR> Platz zu schaffen. Dabei scheint es von Bedeutung zu sein, dass es einen
PR> Mix unterschiedlicher Anforderungen gibt, was sicherlich die Entscheidung
PR> "Was kann ich wegwerfen?" schwieriger macht. Linux hat nach meinen
PR> Erfahrungen keine Probleme, wenn lediglich ein ressourcenfressender
PR> Prozess laeuft. Das wuerde auch erklaeren, warum Benchmarks in der iX z.B.
PR> Linux Geschwindigkeitsvorteile gegenueber FreeBSD geben, die ich im
PR> Realbetrieb nie sehen konnte (ich habe mehrfach Linux platt gemacht und
PR> FreeBSD installiert, um Performanceprobleme zu loesen)

PR> Das schon geschilderte "vorbeugende" Flushen mit dem sysctl-Eintrag
PR>   vm/bdflush=10 0 0 0 60 300 60 0 0
PR> hat die Lage schon etwas verbessert, was ich auch als Bestaetigung der
PR> Theorie ansehe.

PR> Um das System zu verbessern, sehe ich drei Wege (ohne Hardwareanschaffung)
PR> 1. Verbessern der Auslagestrategie
PR> 2. Verbessern der Auslagerungsgeschwindigkeit
PR> 3. Verbesserung auf Applikationsebene

PR> Zu 2.:

PR> Ich habe eben ein dd auf ein File im LVM-Slice gemacht (bei laufendem
PR> Produktionsbetrieb) und Schreibwerte von 6-10 MByte/sec gesehen. Finde ich
PR> nicht berauschend, muss aber auch gestehen, dass ich im Serverbetrieb ein
PR> wenig "SCSI-verwoehnt" bin.

PR> Ich verwende eben reiserfs und LVM, unten liegt ein
PR> 3ware-ATA-RAID-Cotroller und vier 80GB-Harddisks, betrieben mit RAID Level
PR> 5.

PR> Der Controller und die Platten wurden vom Hersteller konfiguriert, der
PR> zumindest kompetent wirkt. Wie auch immer, ich kann von hier aus da
PR> schlecht was aendern.

PR> An Teil 3. arbeiten unsere Web- und DB-Programmierer.

PR> Im Moment sehe ich so recht nicht, wo ich an Punkt 1 oder 2 was drehen
PR> kann.

PR> Daher waere ich fuer Hinweise sehr dankbar. Auch fuer Tips, wie man Teile
PR> des Systems besser messen kann, um Probleme einzugrenzen.

PR> Es gruesst
PR> Peter

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