Re: platten io minimieren
Gruesse!
* Thomas <jade@ares.dyndns.biz> schrieb am [01.12.06 00:36]:
>
> ich würde den physischen Platten IO meines Debian Servers gern verringern, bzw. damit
> experimentieren.
Vorweg: Ich stehe dem eher skeptisch gegenüber. Warum?
Entweder, ich habe einen Server der mir rund um die Uhr bzw. zu
definierten Zeiträumen *uneingeschränkt* zu Verfügung steht - oder eben
nicht. Ein Server stellt normalerweise Vorgänge bzw. Daten zur
Verfügung, die andere Rechner nicht haben. Daraus ergibt sich eine
Priorität, die ich als Besitzer in keinster Weise einschränken bzw.
konterkarieren darf.
Wenn ich (nebem reinem Experimentieren) bei dir einen Nutzen aus deinen
Überlegeungen rauszulesen versuche, dann komme ich auf
Lautstärke- oder Stromkosten-Reduzierung.
Beides läßt sich IMHO heutzutage im Privat-Bereich ohne nenneswerte
Kosten durch die geeignete Wahl an (IDE)-Platten erreichen. Neuere
Platten sind weder im Idle-Modus noch im Last-Betrieb hörbar, die
Stromaufnahme ist IMHO sehr gering und läßt sich evtl. durch den Einsatz
von "Notebook-Platten" noch verringern. Wenn ich dagegen "ältere" (gar
nicht lange her) 20-30GB IDE-Platten nehme bzw. 2 oder 9 GB SCSI-Platten
(volle Bauhöhe = 2 x 5,25"), dann waren diese extrem laut und hatten
einen erheblichen Stromverbrauch.
Außerdem steigt die Gefahr eines Hardware-Ausfalls. "Warmes" Aufwachen
ist AFAIK nicht ganz so abnutzend wie "kaltes" Anfahren, aber nach m.E.
ist es so: wenn Platten kaputt gehen passiert es immer nach einem
Reboot/PowerOn.
> Meine Idealvorstellung:
>
> Platte im Sleep mode.
> Wenn auf die Platte geschrieben wird, sammelt sich das bis zu 500 MB im Ram.
> Die 500 MB werden in einem Zug auf die Platte geschrieben.
> Platte Fällt (schnell) wieder in den Sleep mode.
Das ist zu statisch. Dazu bräuchtest du einen Device-Treiber, der sich
z.B. zwischen Kernel und IDE-Treiber hängt. Weil: das Schreiben findet
ja auf unterschiedliche Ebenen (Swap, /var, Userland) statt. Und
*gelesen* werden Daten ja schließlich auch noch.
Weiterhin: bei einer RAM-Disk (die einzige Möglichkeit, wo du und nicht
der Kernel bestimmt, wie lange Daten im RAM behalten werden) klaust du
dem System Lebenselexier. Wenn nicht gerade "üppig" RAM vorhanden ist
(s.u.) verkehrt sich der Nutzen evtl. ins Gegenteil: die RAM-Disk wird
nur unzureichend genutzt bzw. ist überdimensioniert und dem System fehlt
dieser Speicher, was mit verstärktem IO beantwortet wird. Weiterhin
steht dieser RAM der Ram-Disk dem System *nicht* zur Verfügung bzw. erst
wieder nach einem Reboot ohne Ram-Disk.
Was kannst du IMHO trotzdem machen bzw. wo kannst du ansetzen?
Angenommen, du möchtest die IO nachts (00:00 bis 08:00) verringern, da
niemand *und* nichts den Server nutzt (auch der Server muß "nichts"
machen):
a) RAM kaufen und einbauen. Mehr RAM kaufen und einbauen. Noch mehr
RAM...
Diese "500 MB", die du oben anführst wird vom Kernel schon durch Caching
(sowohl lesend als auch schreibend) bewerkstelligt. Es gibt Parameter
über /proc bzw. sysctl, mit denen du die Effizienz des Cachings
beeinflussen kannst (wieviel, wie lange). Genau kann ich es dir momentan
nicht sagen, ich komme an keine Kernel-Doku ran.
b) Die Platten einfach in den Sleep-Modus stellen. Um Kernel bzw.
Server-bedingte Lese/Schreib-Zugriffe und somiz Aufwachen aus diesem zu
minimieren bieten sich an:
b1) Die Dateisysteme mit noatime mounten. Dadurch verringerst du
Schreib-Zugriffe, da die Veränderung eines der drei Zeitstempel für
jede Datei wegfällt. Privat IMHO durchweg vertretbar, im Firmen-Umfeld
evtl nicht gewünscht da eine Log-Funktion wegfällt.
b2) Dienst in diesem Zeitraum deaktivieren (Datenbanken, Webserver, cron,
etc)
b3) Verzeichnisse wie /var, auf die trotzdem geschrieben werden muß, in
eine RAM-Disk verlagern. Wenn der rechner allerdings abstürzt ist der
Schaden evtl. größer als durch ein (teil)korruptes Dateisystem.
Dadurch kannst du evtl. dafür sorgen, daß eine Platte im Sleep-Modus
bleibt.
c) Wenn es dein Server-"Umfeld" zuläßt: nach dem Booten daß komplette
System in eine RAM-Disk auslagern, ähnlich diverser Live-CD's mit
-to-ram. Auch hier wieder die Gefahr des kompletten Datenverlustes und
es muß sicher sein, daß reale Nutzdaten (ex. /home, /daten, etc.)
trotzdem auf eine HD geschrieben werden.
Sowas ist IMHO eher für einen Funktions-Rechner (Print-, MP3-,
Router/FW-Rechner) geeignet.
> Grüße, Thomas
Gruß
Gerhard
--
HAL is running Windows...
Reply to: