Archiv des Autors: David Scherfgen

Expedition ins schwarze Loch

… so hieß eine Dokumentation, die ich gerade auf N24 gesehen habe. Es handelte sich dabei um eine Folge von Sci Fi Science: Physics of the Impossible. Was einem da geboten wurde, war absolut haarsträubender Unfug, der aber so präsentiert wurde, als ob es sich dabei um wissenschaftliche Fakten handeln würde.

Laut Michio Kaku, dem Moderator der Sendung, sollte es möglich sein mit einem Raumschiff in ein schwarzes Loch zu fliegen. Es gibt da nur ein Problem, das er Spaghettisierung nennt: Das Raumschiff wird zu einem Punkt zerdrückt bzw. unendlich in die Länge gezogen. Aber das ist ja nicht so schlimm, dann nähern wir uns dem schwarzen Loch einfach von oben(!), wo sein Gravitationsring nicht so stark ist. Dort ist es ganz ruhig, wie im Auge eines Wirbelsturms, so dass wir bis zur Öffnung des „Wurmlochs“ vordringen können. Aber so ein Wurmloch ist sehr instabil, wir müssen es offen halten. Dazu brauchen wir die seltenste Substanz des Universums: negative Materie. Die gibt es in Form von negativen Asteroiden am Rand des Universums. Wir schicken also ein paar Drohnen zum Rand des Universums, um sie einzusammeln. Habe ich schon erwähnt, dass negative Materie Antigravitation erzeugt? Damit können wir das Wurmloch stabil halten und hinein fliegen. Natürlich ergibt sich all das aus den Gleichungen von Albert Einstein! Die Leute, die der Moderator fragte (es handelte sich sinnvollerweise um betrunkene Besucher einer Diskothek), hielten die Vorgehensweise jedenfalls für eine gute Idee und würden sich sofort mit Michio Kaku ins Raumschiff setzen.

N24 ist mit dieser Sendung in ein schwarzes Loch der Fernsehqualität eingetaucht. Ich habe mir die ganze Zeit überlegt, was Harald Lesch wohl dazu sagen würde. Wahrscheinlich würde er tot umfallen.

NVIDIA-Treiber müllen Systempartition voll

Wer unter Windows regelmäßig seine NVIDIA-Grafikkartentreiber aktualisiert oder gar ständig die neuesten Betaversionen installiert, dem könnte bereits aufgefallen sein, dass nach jeder solchen Aktion etwas weniger freier Speicher auf der Systempartition übrig bleibt. Gerade bei einer SSD ist das ärgerlich, da diese für gewöhnlich nicht so groß ausfallen wie normale Festplatten.

Der Grund für den Platzschwund liegt darin, dass der Installer immer noch eine Kopie der gesamten Treiberkomponenten aufbewahrt, und zwar für jede Version, die man jemals installiert hat!

Um diesem hirnrissigen Spuk ein Ende zu bereiten, kann man ganz einfach alle Unterverzeichnisse aus folgendem Verzeichnis löschen:

C:\Program Files\NVIDIA Corporation\Installer2

Natürlich sollte man auch nicht vergessen, den temporären Ordner zu löschen, in den der Installer extrahiert wird. Standardmäßig ist das C:\NVIDIA. Auch hier fällt gerne nochmal ein halbes Gigabyte an Müll an.

Nachtrag (4. April 2016): NVIDIA empfiehlt, vor der Installation einer neuen Treiberversion zunächst den vorhandenen Treiber zu deinstallieren. Alternativ kann man während der Installation die Option „Perform Clean Install“ auswählen, die das automatisch erledigt. So hält sich der Ballast in Zukunft hoffentlich in Grenzen.

TFT-Bildschirm flimmert nach Schachbrett-Testmuster

Für meine Master-Arbeit muss ich mit einer Kamera einen (TFT-)Bildschirm abfilmen. Um zu bestimmen, wie lange es dauert, bis sich ein anzuzeigendes Bild auf dem Bildschirm „stabilisiert“ hat, habe ich ein kleines Testvideo erzeugt, das ein Schachbrettmuster darstellt. Die Felder des Schachbretts ändern in jedem Frame ihre Farbe von Weiß zu Schwarz bzw. umgekehrt, und das 60-mal pro Sekunde.

Ich dachte zuerst, dass meine Augen mich täuschen, als ich auch nach Beenden des Testvideos noch ein Flimmern auf dem Bildschirm sehen konnte. Tatsächlich oszillieren die Pixel, auf denen zuvor das Schachbrettmuster zu sehen war, jetzt bereits seit einer halben Stunde weiter! Besonders vor grauem Hintergrund kann man das Schachbrettmuster auch jetzt noch sehr gut erkennen. Ein- und Ausschalten des Bildschirms (auch am Netzschalter und durch Herausziehen des Stromkabels) hat nichts gebracht — die Pixel flimmern immer noch fröhlich weiter!

Es ist mir ein Rätsel, und ich hoffe, dass es irgendwann wieder aufhört zu flimmern …

Server-Backups im laufenden Betrieb mit LVM und ionice

LVM-Snapshots für konsistente Backups im laufenden Betrieb

Wie ich schon einmal erzählt habe, läuft mein Webserver als (bislang einzige) virtuelle Maschine auf meinem dedizierten Server. Die virtuelle Festplatte ist dabei in einem 200 GiB großen Logical Volume untergebracht. Logical Volumes werden mit dem Logical Volume Manager (LVM) erzeugt und sind sozusagen die moderne Version von Partitionen.

Ein Feature von LVM finde ich dabei besonders beeindruckend und extrem hilfreich, nämlich das Anfertigen von Snapshots von Logical Volumes. Ein Snapshot ist eine Momentaufnahme des kompletten Inhalts eines Logical Volumes. Einen Snapshot anzufertigen ist eine Angelegenheit von maximal ein paar Sekunden, es muss dabei nämlich nichts kopiert werden. Erst wenn im Original-Volume ein Datenblock geschrieben wird, muss dessen vorheriger Inhalt gesichert werden, damit er für den Snapshot noch verfügbar ist. Solch ein Verfahren nennt sich Copy-On-Write. Beim Erzeugen des Snapshots muss man bereits angeben, wie viele Daten sich höchstens ändern dürfen, während der Snapshot existiert.

Das Snapshot-Feature ist wie geschaffen für regelmäßige Backups eines Servers im laufenden Betrieb. Hierbei ist es nämlich wichtig, dass man den Inhalt sämtlicher Dateien quasi gleichzeitig sichert. Kopiert man einfach nur alle Dateien nacheinander, dann kommt es zwangsläufig zu Inkonsistenzen, wenn sich während des Backups etwas verändert (und das lässt sich kaum vermeiden, wenn der Server während des Backups benutzbar bleiben soll).

Also geht man wie folgt vor:

  1. Warten, bis alle Cronjobs abgeschlossen sind, denn wir möchten diese nicht unterbrechen. Danach am besten auch den Cron-Daemon anhalten.
  2. Apache und MySQL anhalten, um einen konsistenten Zustand der Datenbanken zu gewährleisten, ggf. noch weitere Dienste.
  3. Mittels lvcreate --snapshot einen Snapshot des Logical Volumes anfertigen, das man sichern möchte. Dabei muss man auch die Größe des Snapshots angeben, also wie viele Daten sich während seiner Existenz ändern dürfen. Ein oft empfohlener Wert ist 10% bis 20% der Größe des Logical Volumes, aber das hängt natürlich von der konkreten Situation ab.
  4. Jetzt, da der Snapshot erzeugt ist, können sämtliche Dienste wieder gestartet werden (Cron, MySQL, Apache, …). Die Downtime des Servers ist somit auf wenige Sekunden begrenzt.
  5. Nun kann der Snapshot „in Ruhe“ irgendwohin gesichert werden, z. B. via FTP. Ich bin dabei, meine eigene Backup-Lösung zu entwickeln, mit der die komplette virtuelle Festplatte blockweise gesichert wird (nicht auf der Ebene des Dateisystems, denn da gibt es immer Schwierigkeiten mit Besitzern, Rechten, Hardlinks, Softlinks usw.). Mehr dazu in einem späteren Beitrag.
  6. Sobald die Sicherung abgeschlossen ist, entfernt man den Snapshot wieder mit lvremove.

Mit nice und ionice die Reaktionszeit des Servers während des Backups verbessern

Das Sichern eines Snapshots beansprucht die Festplatte des Servers stark. Wenn man nicht aufpasst, reagieren Webseiten und andere Anwendungen, die auf dem Server laufen, während des Backups extrem langsam und träge.

Was viele nicht wissen: Unter Linux kann man nicht nur die CPU-Priorität von Prozessen ändern (mit nice), sondern auch ihre I/O-Priorität. Das funktioniert mit dem Befehl ionice, zu dem man diesen netten Artikel finden kann. nice und ionice lassen sich auch kombinieren. Somit kann man dafür sorgen, dass ein laufendes Backup die übrigen Prozesse weder in Sachen CPU noch in Sachen Festplatte zu sehr ausbremst.

Folgender Befehl startet das Skript backup.sh mit minimaler CPU- und I/O-Priorität:

nice -n 19 ionice -c 3 ./backup.sh

Nachtrag: Nach meinen ersten Erfahrungen kommt es auch bei der Verwendung der niedrigsten I/O-Priorität teilweise zu großen Beeinträchtigungen des Serverbetriebs. Abhilfe kann das Tool pv schaffen, mit dem man u. A. den Durchsatz einer UNIX-Pipe begrenzen kann. Somit kann man beispielsweise ein laufendes Backup auf eine Leserate von höchstens 60 MiB pro Sekunde drosseln.

Eure Besucher werden es euch danken!

Node.js-Modul „ffi“ zum Laufen bringen

Mit frisch installiertem node.js und Paketmanager npm hatte ich gerade einen seltsamen Fehler, als ich das Paket ffi installieren und benutzen wollte (mit diesem Paket kann man native Funktionen aus node.js heraus aufrufen):

> require("ffi")
Error: Could not locate the bindings file. Tried:
 → /home/david/node_modules/ffi/node_modules/ref/build/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/build/Debug/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/build/Release/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/out/Debug/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/Debug/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/out/Release/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/Release/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/build/default/binding.node
 → /home/david/node_modules/ffi/node_modules/ref/compiled/0.6.12/linux/x64/binding.node
    at bindings (/home/david/node_modules/ffi/node_modules/bindings/bindings.js:88:9)
    at Object. (/home/david/node_modules/ffi/node_modules/ref/lib/ref.js:5:47)
    at Module._compile (module.js:441:26)
    at Object..js (module.js:459:10)
    at Module.load (module.js:348:32)
    at Function._load (module.js:308:12)
    at Module.require (module.js:354:17)
    at require (module.js:370:17)
    at Object. (/home/david/node_modules/ffi/lib/ffi.js:6:11)
    at Module._compile (module.js:441:26)

Aha, es fehlt also irgendeine komische „Bindings-Datei“. Um den Fehler zu beheben, braucht man das Paket node-gyp, das einfach mit npm install -g node-gyp global installiert werden kann.

Nun muss man das Tool node-gyp an zwei verschiedenen Stellen aufrufen, damit diese Bindings-Datei erzeugt wird, nämlich einmal im Verzeichnis ffi selbst und einmal in ffi/node_modules/ref:

david@webserver:~# cd node_modules/ffi/
david@webserver:~/node_modules/ffi# node-gyp rebuild
[...]
david@webserver:~/node_modules/ffi# cd node_modules/ref/
david@webserver:~/node_modules/ffi/node_modules/ref# node-gyp rebuild
[...]

Anschließend sollte das ffi-Modul korrekt geladen werden können.