Schemata und Web-Applikationen

Wegen aktueller Erfahrungen bei einem Kunden möchte ich ein Thema ansprechen, das man nicht oft genug betonen kann :

Wenn man eigene Web-Services wie z.B. Formulardienste oder Pflegeapplikationen mit PHP und dabei auch noch objektorientiert entwickelt, dann lohnt es sich unbedingt, hierbei so vorzugehen, dass die

  • grundlegenden Datenbank-Strukturen (Tabellen, Felddefinitionen, Master-Detail-Relationen),
  • essentielle Elemente der Datenprüfung/-Validierung,
  • Objekte für die Repräsentation von Webformularen,
  • Objekte der Datenbankinteraktions-Schicht und
  • die darüber liegenden Pflegeapplikationen

auf der Basis von sog. zentralen “Datenschemata” quasi generiert werden. Dabei kann man sogar Vorgaben für die Repräsentation von Master-Detail-Relationen integrieren.

Natürlich ist der Aufbau entsprechender eigener Frameworks mühsam – aber es lohnt sich nach unserer Erfahrung schon ab dem zweiten Projekt.

Die zentrale Idee ist die, dass man sich ein “Framework” so aufbaut, dass durch die programmtechnische Auswertung von vorgegebenen “Datenfeld-” und “Validierungs-” Beschreibungen (“Schema”)

  • sowohl die benötigten Datenbank-Tabellen generiert
  • als auch zugehörige Pflegeapplikationen in einem “Rutsch” (durch reines Kopieren von Dateien) bereitgestellt werden können.

Die entsprechenden Objekte müssen so “intelligent” sein, dass sie aus der vorgegebenen Datenstruktur-Information des “Schemas” die richtigen Schlüsse ziehen : D.h., dass sie die benötigten SQL-Statements und Validierungsstatements innerhalb der Pflege- und Applikationslogik und die zugehörigen Web-Formulare dynamisch aufbauen, wobei Sie immer gleiche Klassendefinitionen heranziehen.

Salopp ausgedrückt folgt man dabei der Devise: “Gib mir deine Datenstruktur und ich gebe dir eine erste komplette Pflegeapplikation auf der Basis eines universellen Model-View-Controllers und einer universellen Datenbank-Interaktionsschicht an die Hand.” PHP ist für den Aufbau solcher Frameworks aus unserer Sicht seit PHP5.2 geradezu ideal geeignet.

Baut man die Pflegefunktionalität selbst modular in Funktionalklassen auf, so verschafft man sich gleichzeitig die Basis für komplexere und spezialiserte Business-Applikationen, denen man dann Schema-Objekte übergibt. Aus der Schema-Information werden dann nach Bedarf automatisch Objekte für die Repräsentation einzelner Datensätze oder ganzer Listen von Datensätzen generiert. Die Interaktion mit der Datenbank tritt dann für die Business-Logik in der Regel fast völlig in den Hintergrund.

Bei Erweiterungen um Felder ändert man primär das entsprechende “Schema” und schon läuft die erweiterte Applikation – vorbehaltlich inhaltlicher Erweiterungen der Business-Logik. Es liegt auf der Hand, dass sich die anfängliche Mühe bei der Erstellung “schemabasierter” Frameworks schnell lohnt.

Opensuse 11, sensors und IT8720

Wer sich – wie ich – ein neueres Board beschafft hat, wird u.U. feststellen, dass die HW-Sensoren ein Kernelmodul zur Unterstützung der  ITE 8720 Super IO Sensors benötigen. Opensuse 11.1 liefert für den 2.6.27-Kernel allerdings nur ein älteres IT87-Modul, das für die neueren Chipsätze nicht ausreichend ist.

Netterweise gibt es ein paar Kollegen, die sich die Mühe gemacht haben, die für den Kernel 2.6.29 bereits erstellten Module auf den älteren Kernel zurückzuportieren und entsprechende RPM-Pakete für den aktuellen Stand des SuSE-Kernels bereitzustellen.
Hier wird man im Internet fündig :

http://forums.opensuse.org/hardware/410081-sensors-ite-it8720-not-working.html

http://download.opensuse.org/repositories/home:/Akoellh/

Das erweiterte IT87-Kernelmodul funktioniert prächtig und kann nach “sensors-detect” in der Datei “/etc/sysconfig/lm_sensors” eingetragen werden – in meinem Fall lauten die Einträge:

MODULE_0=”coretemp”
MODULE_1=”it87″

Natürlich kann man unter Yast2 auch den sysconfig-Editor verwenden. Das entsprechende Startup-Skript “lm_sensors”, das diese Einträge nutzt, findet man natürlich unter “/ect/init.d”.

Vielen Dank an Akoellh !

Swap – ein paar Bytes zuviel?

Änderung des Beitrags am 07.06.2009:

Der nachfolgende Beitrag hat sich inzwischen in wesentlichen Punkten als haltlos entpuppt:

Ursache der Abstürze ist eindeutig ein fehlerhafter Speicherbaustein – also ein Hardware-Fehler in der betroffenen Maschine. Die unten beschriebene Verringerung des Swap-Bereiches hatte evtl. trotzdem positive Wirkung, als die Wahrscheinlichkeit, den defekten Speicherbereich zu treffen möglicherweise verringert wurde.

Es bleibt als Befund lediglich der fühlbare Geschwindigkeitsunterschied bei der Verringerung des SWAP-Bereiches und die Erkenntnis, das man bei statistisch auftretenden Fehlern der Klasse “General Protection Fault” zunächst mal den RAM auf Funktionstüchtigkeit prüfen sollte, bevor man sich in Spekulationen verliert.

********************************************

Alter Beitrag

Am letzten Wochenende musste ich mit einem Problem auseinandersetzen, dessen Ursache letztlich wohl im SWAP-Bereich lag. Das Ganze ist aber irgendwie komisch und deshalb aus meiner Sicht einen Blog-Beitrag wert. Zumal ich im Internet gefunden habe, das auch andere Leute mit verschiedenen Kernelversionen unter Opensuse 11.1 unregelmäßige Abstürze erlebt haben.

Ich hatte ein neues System mit 8GB DDR3-RAM und einem Intel Quadcore Q9550 Prozessor aufgesetzt (Opensuse 11.1 – x86_64). Das ist gleichzeitig die RAM-Grenze des Mainboards. Das System hat vier 1TB Platten in 2 Raid-1-Arrays. Da auf diesem System i.d.R. 2 VMware-Maschinen mit je 2GB Hauptspeicher und ein Samba-Server sowie Datenbank-Server laufen sollen, ist die Kalkulation des SWAP-Speichers nicht ganz einfach – zumal man hierzu im Internet durchaus unterschiedliche Philosophien finden kann.

Ich hatte auf der einen Partition eine SWAP-Partition von 4GB eingerichtet, auf der anderen einen Bereich von 8GB – letzteres nur testweise. Mein Motiv war, einfach mal auszuprobieren, ob im Alltag überhaupt Unterschiede feststellbar wären. (Generell glaube ich, dass bei 8GB Hauptspeicher selbst 4GB Swap völlig überdimensioniert sind, da ausgelagerte Bereiche komprimiert werden. In der Praxis zeigte sich, dass der Swap-Bereich lediglich beim parallelen Handtieren mit mehreren großen Dateioperationen eine Rolle spielte).

Egal:Zuletzt hatte ich den 8GB Swap Bereich mit “swapon” aktiv auf swap eingehängt. Im Zuge diverser anderer Ereignisse hatte ich dies aber vergessen und danach die Maschine mit dieser Einstellung produktiv benutzt.

Dann kam es zu unregelmäßigen, nicht nachvollziehbaren Abstürzen oder einem Einfrieren des ganzen Systems. Dies war für mich insofern erschütternd, als mir alle wesentlichen Einstellungen identisch mit einer fast gleich konfigurierten Maschine erschienen, die sich seit Wochen fehlerfrei im Dauerbetrieb befindet. Die Abstürze geschahen vor allem dann, wenn ich viele Dateien kopierte – ob unter VMware oder unter Linux.

Nach einer Beobachtung und Auswertung von /var/log/messages kam ich dann dahinter, dass die meisten der Abstürze an einen “General Protection Fault” gebunden waren. Dies versetzte mich bereits in gehörige Unruhe.

Als nächstes tauchten bei der Installation eines Programmpaktes plötzlich Meldungen auf, dass das System auf illegale Speicherbereiche jenseits der Parttionsgrenzen zugreifen wolle. Nun dachte ich an Speicherfehler – und ließ memcheck mal über mehrere Stunden laufen – ohne Fehlermeldungen.
Noch schlimmer wurde es, als ich danach einen systematischen Test der mehr als 10 Partitionen des Systems mit fsck durchführte – Fehler über Fehler trotz Recovery Journal des Ext3-Systems. Hier rächte sich übrigens die Aktivierung des Write-Cachings auf dem Raid Controller bitter. Der hat mehrere hundert MByte Caching Speicher. Bei den festgestellten Abstürzen findet hier kein sync des Writecaches mehr auf die Platten statt – das Filesystem kann deshalb nach dem Hochfahren auch über das Journaling Fehler ggf. nicht mehr ausbügeln – und man
merkt es nicht einmal !

Merke: Nach Abstürzen und aktiviertem Write-Caching trotzdem fsck-Prüfungen fahren !

Nun erklärt das aber nicht die Ursache der Abstürze – es macht höchstens ein systematisches Anwachsen der Filesystem-Probleme plausibel, wenn fsck nicht angewendet wird. Ich bereinigte also die Filesysteme über “fsck -f” . Danach prüfte ich alles Mögliche und verglich die Konfiguration meiner Maschinen – ergebnislos.Ich installierte einen älteren Kernel, deinstallierte überflüssige Pakete – alles vergebliche Mühe.

Durch Kopieren großer Dateimengen konnte ich den Fehler inzwischen systematisch provozieren. Und irgendwannmal gelang es mir nach einem Protection fault die Maschine noch weitgehend geordnet herunterzufahren. Dabei fiel mir auf, dass die Swap-Partiton nicht mehr freigegeben werden konnte. Nun erinnerte ich mich wieder an meine eigentlich “testweisen” SWAP-Einstellungen und aktivierte die kleinere SWAP-Partition statt der großen. 4GB SWAP waren übrigens auch auf dem Vergleichsystem eingestellt !

Und siehe da, das System lief danach

1. fehlerfrei

2. deutlich schneller als zuvor.

Kann Opensuse 11.1 mit dem aktuellen Kerne 2.6.27 nun einfach nicht mit 8GB SWAP arbeiten ? Ich weiss es nicht – komisch ist die Sache schon.

Interessant ist auch, dass der “testweise” Swap-Bereich minimal gößer als 8GB war. Zusammen mit den 8GB Ram wurde also evtl. ein irgendwo existierendes 16GB-Limit überschritten.

Der Kernel ist übrigens der aktuell für Opensuse 11.1 im Update Repository angebotene 2.6.27.21-0.1-default #1 SMP x86_64 .

Wenn einer eine Idee dazu hat, was hier los war, möge er mich informieren !