Optimierung:Stromsparen
Aus IPFireWiki
Dieser Artikel ist auch für viele Embedded Systeme interessant, da diese meist weniger leistungsfähige Hardware einsetzen, einzelne Änderungen greifen sehr tief ins System ein und führen auch dazu dass das System an Stabilität verliert
Stromverbrauch senken
Der Stromverbrauch eines 30W Systems hinterlässt pro Jahr etwa eine Haushaltslücke von ca. 50EUR. Es wird schnell klar, dass hier jedes gesparte Watt fast einen EUR bedeuted. Es gibt auch Embedded Syteme die gerade einmal 10Watt verbrauchen, aber natürlich auch in der Leistung und im Funktionsumfang beschränkt sind. Wesentlich erschreckender finde ich, wenn alte PCs als Dauerbetriebserver verwendet werden, hier laufen schnell einige hundert Watt auf.
Die einfachsten Tricks sollte denke ich jeder bedenken, Monitor am Server ausschalten, 2,5 Zoll Platten verwenden, wenn nicht sogar USB Sticks, unnötige Schnittstellen abschalten und Karten ausbauen, allein dadurch kann man immens sparen. Natürlich ist Virtualisierung auch im heimischen Wohnzimmer gefragt, hier kann auch der ein oder andere Stromfressende Zweitserver durch ein virtuelles Gegenstück ersetzt werden (eine Sicherheitsdiskussion erspare ich mir an dieser Stelle). Eine Ersparnis im Bereich 50-150 EUR sind in einigen Fällen möglich.
Was aber wenn diese ganzen Ratschläge bereits befolgt wurden was kann noch getan werden?
Nun der IPFire hat zwar an der einen oder anderen Ecke bereits etwas in Richtung Strom sparen an Board, aber die Wenigsten wissen, dass es noch einige Stellschrauben zur optimierung gibt.
CPU Geschwindigkeit regulieren
Das Addon cpufrequtil z.B. ermöglicht es die bekannten Prozessor Stromspartechniken zu verwenden. die hilft den Prozessor nur auf niedrigen Frequenzen laufen zu lassen, da kaum ein Server permanent 100% Auslastung hat. Unterstüzt werden dabei;
- generic ACPI P-States based driver (acpi-cpufreq)
- AMD Elan - SC400, SC410 (elanfreq)
- AMD mobile K6-2/3+ PowerNow! (powernow-k6)
- AMD mobile Athlon PowerNow! (powernow-k7)
- AMD Cool&Quiet PowerNow! (powernow-k8)
- Intel SpeedStep using the SMI BIOS interface (speedstep-smi)
- Intel SpeedStep on ICH-based chipsets (speedstep-ich)
- Intel Enhanced SpeedStep (acpi-cpufreq and speedstep-centrino)
- Intel Pentium4/Xeon clock modulation (p4-clockmod)
- NatSemi Geode GX / Cyrix MediaGXm (gx-suspmod)
- Transmeta Crusoe / Efficeon LongRun (longrun)
- VIA Cyrix Longhaul (longhaul)
- VIA C7 (e_powersaver)</nowiki>
Festplatten schlafen legen
Ein weiterer Stromfresser sind die Festplatten, erst recht die 3,5 Zoll Pendants, der IPFire versucht hierbei alle 30min die Festplatte in einen Standby Modus zu versetzen, hierbei werden die gelesenen/geschriebenen Bytes auf der Platte mit dem vorherigen Lauf verglichen, hat sich hier nicht geändert wird ein hdparm -y ausgeführt. Das ist nur ein manuell erzwungener Spindown. Natürlich gibt es auch noch den Modus -Y, dieser würde jedoch ein Sleep erzwingen und nur durch einen Hard/soft Reset wieder die Platte erwecken lassen. 3,5 Zoll / Server Platten sind nicht dafür gedacht permanent rauf und runter gefahen zu werden, daher ist die Lösung mit 30 Minuten durchaus gangbar.
Wer noch schneller schalten will kann in der crontab die Ausführung auf alle 15 Minuten setzen, oder anstelle des -y ein -Y verwenden, was zumindest bei 3,5 Zoll Platten nochmal ein wenig was heraus holt, allerdings nicht zu häufig gemacht werden sollte. Die Werte für Standby/Sleep unterscheiden sich meist um 0,x
Weitere Stellschrauben sind das verwenden von APM. Bei vielen Platten ist es mittlerweile möglich über hdparm -S n /dev/xxx das eigentständige Ausschalten nach n Sekunden zu aktivieren, ebenso kann über hdparm -B das von 0(aggressiv) bis 255(deaktiviert) das Powermanagement der Platte gesteuert werden.
Eine 3,5 Zoll Platte braucht im Betrieb gute 10Watt im Ruhezustand (Nichtstun,kein Sleep/Standby) immernoch fast doppelt soviel Strom wie eine 2,5 Zoll Platte im Betrieb (5 Watt zu 2,5 Watt).
Soviel zur Hardware Seite, natürlich kann auch auf Software Seite einiges getan werden, allen voran am System logging. Die Ureigenste Funktion der Firewall besteht ja nicht nur darin Zugriffe zu steuern sondern diese auch zu protokollieren, natürlich kollidiert dies massiv mit unseren Stormsparwünschen.
Mit der richtigen Konfiguration die Festplatten schonen
Die radikalste Methode ist sicherlich den syslog zu deaktivieren, feiner ist es natürlich dediziert zu konfigurieren was geloggt werden soll und bei dem ein oder anderen Dienst das Logging zu deaktivieren. Mögliche Stellschrauben wäre hier das kernel Logging über printk, der Squidlog, die Firewalllogs, das apache Log, collectd usw.
Auch der Syslog-Daemon verhindert oft das Einschlafen der Platte, da er regelmäßig Logdaten schreibt und aus Sicherheitgründen dabei standardmäßig den Plattencache umgeht. Ein "-" zu Beginn eines Konfigurationseintrags in "/etc/syslog.conf" verbietet das Umgehen des Caches bzw verhindert das sofortige schreiben des Syslogs und ermöglicht ihm eine sammeln für 30 Sekunden.
Anstelle von
cron.none;daemon.*;local0.*;local2.*;*.info;mail.none;authpriv.* /var/log/messages
sollte folgende Zeile verwendet werden
cron.none;daemon.*;local0.*;local2.*;*.info;mail.none;authpriv.* -/var/log/messages
ebenso könnte man ein paar Informationen weniger loggen
cron.none;*.warn;mail.none;authpriv.none -/var/log/messages
Ebenso kann in der httpd.conf / in den vhost.conf Dateien das logging des Webservers abgeschalten werden. Squid und Firewalllog können sogar einfach per Webinterface deaktiviert werden.
Kernel Parameter
Auch nach Festlegen eines Spindown-Wertes schlafen die Systemplatten auf einem nicht angepassten Linux-System so gut wie nie ein, da der Kernel das Zurückschreiben des Caches für optimale Performance auf viele kleine Schreibzugriffe verteilt. Für diesen speziellen Fall wurde seit dem 2.6er Kernel eine Art Laptop Modus eingebaut dieser hierbei fasst der Kernel kleine Schreibzugriffe zusammen, so dass die Chance eines Spindowns der Platten wächst. Steht in der Datei "/proc/sys/vm/laptop_mode" ein Wert größer 0, dann ist der Laptop-Mode aktiv.
Wichtig in diesem Zusammenhang ist die "dirty writeback time", also die Zeit, die der Kernel höchstens wartet, bis er den Festplatten-Cache leert: Um die Gefahr eines Datenverlusts zu minimieren, steht unter "/proc/sys/vm/dirty_writeback_centisecs" normalerweise der Wert "500" (5 Sekunden), die Festplatte kommt also in der Praxis selten zur Ruhe. Je nach Sicherheitsbedürfnis bei Crashs kann der Administrator diesen Wert auf stark erhöhen, beispielsweise auf 10 Minuten. Zu Bedenken ist, dass bei einem Systemstillstand sich die Platten noch auf dem Stand von vor 10 Minuten befinden. Dafür führt sogar das Speichern eines Dokuments, dessen Größe die des Plattencaches nicht übersteigt, nun nicht mehr zum Anlaufen der Platte.
Hier noch ein paar Parameter / Informationen
The kernel also has a setting known as laptop_mode, which makes it delay writes to disk (initially intended to allow laptop disks to spin down while not in use, hence the name). A number of files under /proc/sys/vm/ controls how this works: /proc/sys/vm/laptop_mode: How many seconds after a read should a writeout of changed files start (this is based on the assumption that a read will cause an otherwise spun down disk to spin up again). /proc/sys/vm/dirty_writeback_centisecs enthält die Verzögerung bis ein pdflush-Thread in Hundertstel Sekunden reaktiviert wird. /proc/sys/vm/dirty_expire_centisecs definiert, nach welchem Zeitabschnitt eine schlechte Seite spätestens ausgeschrieben werden sollte. Der Standardwert ist 3000, was 30 Sekunden bedeutet. /proc/sys/vm/dirty_background_ratio maximaler Prozentsatz an schlechten Seiten bis pdflush damit beginnt, sie zu schreiben. Der Standardwert ist 5%. /proc/sys/vm/dirty_ratio wenn die schlechten Seiten diesen Prozentsatz des gesamten Arbeitsspeichers überschreiten, werden Prozesse gezwungen, während ihres Zeitabschnitts Puffer mit schlechten Seiten anstelle von weiteren Daten zu schreiben.
Das Filesystem
Der Ureigenste verursacher von Schreibzugriffen ist allerdings das Filesystem selbst, allen voran die journaling filesysteme wie ext3/reiserfs. Diese schreiben in der Regel in kurzen Zyklen (alle 5-30 Sekunden)ihre Journale neu um bei einem Absturz keinen Datenverlust zu haben und schnell wieder zur Verfügung stehen
Das Anpassen der fstab kann diesen Zeitraum erheblich herauf setzen
/dev/hda2 / ext3 defaults,commit=200 0 1
Ein solcher Aufruf sorgt dafür, daß das Journaling des ext3-Dateisystems erst nach 200 Sekunden auf die Platte geschrieben wird. Der Vorteil von Journaling FS liegt in der schnellen Verfügbarkeit nach einem Absturz, bedeutet allerdings auch ein regelmäßiges Journal schreiben auf der Platte.
Zusätzlich schreibt linux per default eine Timestamp wann eine Datei zuletzt gelesen wurde, das ist auch für den ein oder anderen Datenträger ein Horrorszenario, es empfiehlt sich also auf die atime Informationen zu verzichten und folgende mount Option zu verwenden
/dev/hda2 / ext3 defaults,commit=200,noatime,nodiratime 0 1
Journaling ade - ext3 zu ext2
Der Unterschied von ext3 zu ext2 ist eigentlich NUR das Journal, der Rest ist gleich. Das ist auch der Grund, warum man problemlos zwischen beiden hin und her wechseln kann. Folgendes muss man dafür machen:
in der Datei /etc/fstab “ext3″ in “ext2″ ändern In der fstab den Dateisystem-Typ aller Platten, die auf ext2 gewechselt werden sollen, entsprechend anpassen, da sonst beim Neustart nach den Änderungen das System nicht mehr hochfahren würde.
Das System über den Installer/anderes Linux System booten Das ist nötig, da die Festplatte die als / verwendet wird, nur im Read-Only Modus angepasst werden kann oder wenn sie gar nicht eingehangen ist. … Zum entfernen der Journals dann tune2fs -O ^has_journal /dev/sda1 Die Journal Markierung von den gewünschten Festplatten entfernen fsck /dev/sda1 Das Journal entfernen. Das passiert bei einem Check automatisch. Ohne diesen Schritt ändert sich gar nichts
Das System wieder ganz normal starten
Stürzt das System einmal unerwartet ab, dauert das reparieren/der FS-Check bei ext2 natürlich länger, da kein Journal vorhanden ist und somit das ganze FS überprüft werden muss.
Squid ohne Festplattencache
Seit der 2.3 besteht die Möglichkeit den Squid ohne Festplattencache zu betreiben, hierfur muss einfach bei Festplattencachegröße eine 0 eingetragen werden.
Verlagerung von häufig geschriebenen Dateien in eine Ramdisk
Die Verlagerung von häufig geschriebenen aber systemunkritischen Dateien in eine Ramdisk wurde mit der 2.3 bereits releaisiert. Die Systenstatistiken sind in den Speicher gewandert (auch ohne rrdcache zu verwenden), ebenso /var/run und /var/lock.
Wer viel Ram hat kann das ganze natürlich auch auf die komplette Log Partiton ausweiten und /var/log in eine Ramdisk schieben, eine periodische Rücksicherung sollte hier dennoch statt finden, Anregungen kann man sich im init Skript tmpfs holen.
Wie finde ich jetzt raus was auf meine Platte schreibt
trap clean_exit 1 2 3 6 15
clean_exit () {
echo 0 > /proc/sys/vm/block_dump
/etc/init.d/sysklogd start
echo "Adios"
exit 0
}
/etc/init.d/sysklogd stop
echo 1 > /proc/sys/vm/block_dump
while true; do
clear
date
dmesg | tail -n60
sleep 1
done
Was ist noch möglich
Erzeugen eines unionfs mit einem Flash Medium und Ram, diese Technologie wird heutzutage bei LiveCDs verwendet, alle Änderungen werden im tmpfs geschrieben, vorher wurde das CD Medium ro gemountet(was bei einer CD ja meist eh der Fall ist). Selbiges ist natürlich auch mit dem IPFire denkbar, allerdings gehört hier auch einiges an Arbeit investiert, wenn man die Daten dann nach einem Absturz/shutdown nicht wieder im Urzustand finden will, dh irgenwie muss man auf den Stick zurück schreiben.
