Nvidia und Linux/Ubuntu

In den letzten Tagen bin ich ja beinahe verzweifelt.

Eigentlich eine ganz banale Aufgabenstellung. Ich wollte, statt des nouveau-Treibers, die von Nvidia selbst herausgegebenen Treiber für Linux installieren.

Voll einfach

Also klicke-di-klack im Ubuntu Softwaretool den „proprietären“ Treiber ausgewählt, installiert und neu gestartet.

Lief.

Nach einem Reboot aber nicht mehr. Bildschirme schwarz.

Also per ssh in den Rechner eingewählt und geguckt, was abgeht. In den Logs nichts, was irgendwie ungewöhnlich ist (in den Linuxlogs sind Fehler ja völlig normal *würg*). Aber der Xorg-Prozess lutscht einen ganzen Kern mit 100% Auslastung.

Ungewöhnlich, sag ich mal.

Also andere Versionen des Treiber ausprobiert…

Ich mach es kurz

Diesmal die knappe Zusammenfassung – und bitte wegsehen, wenn man etwas empfindlich ist.

Es ist die allergrößte Scheiße, die je irgendein Mensch verbrochen hat. Nach drei Tagen/Nächten herumprobieren bekomme ich den Sondermüll einfach nicht ans Laufen. Ich weiß jetzt mehr als ich je wollte über meine Grafikkarte, ich verzichte in der VirtualBox (brauche Photoshop) auf die 3D-Beschleunigung. Klar bekomme ich das für 5 Minuten ans Rennen (unter Verzicht auf einen geordneten shutdown, weil – ist ein bekanntes Problem – was mit dem Kernel-modeset nicht funktioniert) oder mal für eine Session (sogar mit beiden Bildschirmen, auch in ca. 10% schneller als mit dem nouveau-Treiber)…

Einfach unfassbar, was man sich da freiwillig antut, nur, weil man ein ansonsten schönes und stabiles Betriebssystem haben möchte. Der Rest läuft auch (ok, Gnome-Shell-Extensions habe ich jetzt fast alle gelöscht, weil DIE auch WIEDER Probleme machen – ich hasse die Arroganz der Gnome-Entwicklung und ihre „ist mir alles scheißegal, was die Leute nutzen, wir wollen fancy shit haben“-Einstellung, liest sich aber total nett und sympathisch…).

Was mir wieder mal aufgefallen ist: Die OpenSource-Szene ist voll mit echten A-Geigen, die sich einen Dreck um die Nutzer kümmern. Da werden Bugs runterdiskutiert im Sinne von „eih Alta, is doch 3 Monate her dieser Stand, mussu halt anpassen“ und allgemein interessiert es nun wirklich keine Sau, dass man ein stabiles System bevorzugt.

Klar, ich könnte ein Debian Stable einsetzen. Aber mit Software aus dem letzten Jahrzehnt will ich auch wiederum nicht abhängen – und die Arroganz der Debianer ist ja noch um eine ganze Hausnummer größer.

Fazit

System ist geil, aber man muss damit leben lernen, dass man ein laufendes System einfach komplett in Ruhe lässt. Und sich stundenlang VOR einem Update informiert, was alles („vorhersehbar“) kaputtgehen wird. Denn das ist ein Haufen Zeugs – im Fehlerfall zieht ein kaputtes X oder Gnome oder sonstwas gerne mal einfach alles mit, was gerade läuft. „Autosicherungen“, „Fehlerbehandlung mit backout inklusive Datensicherung“ – dass ich nicht lache. Das interessiert die allermeisten OSS-Entwicklung einen feuchten Pups.

Lieber Features einbauen oder bestehende Schnittstellen über den Haufen werfen.

Wie man überhaupt auf die Idee kommen kann, per JavaScript Extensions in eine Shell einzulöten… und wenn man dieses Verbrechen schon begebt, wieso man die nicht wenigstens sandboxed oder irgendwie sonst gegenüber dem Rest des Systems absichert… hach ja.

I’m getting to old for this sh*t.

P.S. Nouveau

Ich muss den nouveau-Leuten aber mal ein Lob aussprechen: Der Treiber funktioniert mit älterer Nvidia-Hardware (750M, Mac Edition, GK107, NVE0 Kepler Family… ich sag ich, ich weiß jetzt zu viel über meine Karte…) eigentlich richtig gut – und vor allem störungsfrei.

Vor allem haben die auch mal Bock auf Doku.

Ajax Backendanfragen cachen – unmöglich…?

Auf unserer Webseite benutzen wir viele Elemente, die dynamisch mit Content aus dem Backend versorgt werden.

Beispielsweise die Liste unserer Informationsartikel:

ya info
ya info

Die Elemente dieser Liste werden per Ajax aus dem Backend gelutscht – einzeln.

Requests ohne Ende

Also hustet so eine „Grid“-Übersicht mal eben ein paar Dutzend Backendanfragen in Richtung Webserver – und dann passiert das hier:

  • Webserver findet, dass admin-ajax.php eine PHP-Script ist und fährt erst mal eine Instanz des PHP-Interpreters hoch
  • Das Script wiederum möchte gerne das WordPress-Imperium im Zugriff haben, also wird die Maschinerie in Gang gesetzt und das WordPress-Backend macht sich breit (ein paar hundert PHP-Scripte werden geladen und Dutzende Datenbankabfragen losgeschickt – bevor irgendetwas tatsächlich passiert).
  • Dann verarbeitet admin-ajax.php netterweise auch mal den Ajax-Request bzw. leitet den an die zuständige Stelle weiter.
  • Diese fragt dann ihrerseits diverse Tabellen ab – über WordPressroutinen üblicherweise. Also wp_query und Konsorten, die allesamt nicht gerade den Ruf genießen hochperformant optimierten SQL anzuwenden – kann jeder bewundern, wenn er sein MySQL-Slowlog anschmeißt und sich dann mal per explain die dicksten Statements erklären lässt…
  • Wenn dann alle Beteiligten glauben, dass der Content so weit generiert ist, beendet sich das PHP-Konglomerat und stellt eine Antwort für den Ajax-Request bereit.
  • Der wiederum wird dann vom rufenden Javascript in die Seite gelötet.

Das stellen wir uns jetzt mal ein paar Dutzend vor und wir wissen, wie schön es ist, ein sich langsam inkarnierendes Postgrid zu bewundern – Ladezeiten im mehrstelligen Sekundenbereich sind die Folge.

Da möchte man doch mal – Cache?

Klassischer Anwendungsfall eines Caches ist, dass Daten, die sowieso gleich sind, nicht aus der langsamst möglichen Ecke geholt werden sondern von dort, wo es sonnig und warm ist; idealerweise aus dem Arbeitsspeicher, wenn es nicht anders geht, so zumindest aus der Tiefkühltruhe und nur noch schnell in die Micowelle (also servierfertig und nur dezent zu bearbeiten).

Angeblich geht das mit WordPress-Ajax nicht.

Selten so gekichert… natürlich geht das. Man muss nur die schulterlangen Gummihandschuhe anziehen, Nasenklammern drauf und dann in der Suppe wühlen, bis man die richtigen Stellen gefunden hat, an denen man was anflanschen muss.

Jetzt passiert das hier:

  • Ajax-Request schlägt im Backend auf.
  • admin-ajax.php wird immer noch durch eine neue PHP-Interpretinstanz interpre… ausgeführt.
  • ohne WordPress hochzufahren wird erkannt, dass die gewünschte Action mit dem passenden Schlüsselzeugs schon in der „Datenbank“ herumlungert und die Antwort umgehend an den Anfrager zurückgeworfen.

Dabei heißt „Datenbank“ hier ein Key im Redis-Inmemory-Store.

redis cache
redis cache

Aber einmal muss ich durch den Cache…

Die allererste Anfrage muss natürlich durch den gesamten Dschungel, sonst weiß der Redis ja nicht, wie die Abkürzung aussieht.

Das muss aber nicht zwingend mit dem ersten Besucher passieren, der sich auf die Webseite traut.

node.js precache
node.js precache

Das kann ein nächtliches Script machen, was bei der routinemäßigen Wartung mitläuft und die relevanten Ajax-Requests simuliert, die tagsüber so auf das Backend einschlagen. Dieses Script wiederum nutzt node.js und jsdom und diverse andere ähm „Hilfsmittel“ – darüber schreibe ich ein anderes Mal, mir ist schon schlecht 😉