[Allegro] avanti unter xinetd [Lang]

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

um etwas aelteres sprichwoertlich aufzuwaermen (es ging um die
Art und Weise, wie avanti seine Wartezeit verbringt):

Am 02.02.2011 12:38, schrieb Bernhard Eversberg:


> Was Sie alles wissen. Ja, das könnt wohl was bringen und geht auch
> unter Solaris: Mit 1000 braucht avanti dann 0.05% der CPU (mit sleep(1)
> deutlich weniger), das wär ja schon noch hinnehmbar und ändert die
> Leistung an der Oberfläche nicht merklich.

Ich "konsolidiere" (im EDV-Jargon anscheinend ein transitives Verb)
gerade auf einen ziemlich gruenen Server unter VMWare ESXi, darauf
diverse virtuelle Linux-VMs (typischerweise mit fettem Apache-
Webserver, mySQL, SSH, Samba, DNS und Mail-Server, sowie den ueblichen
anderen Services, also etwa 130 schlafende Prozesse).

Das Verwaltungstool vSphere Client gibt wunderbare Graphiken aus,
etwa zu zugeteilten CPU-Zyklen oder zum Energieverbrauch: Eine
solche virtuelle Linux-Maschine mit allen geschilderten Diensten
im Leerlauf benoetigt demnach ca. 10-40MHz an staendiger CPU-
Zuteilung (d.h. <2% eines physischen Kerns) und verbraucht
zwischen 1 und 3 "Watt" (vermutlich Anteile der gesamten Leistungs-
aufnahme auf CPU- und andere Ressourcenanteile umgeschlagen, da
alles extrem leerlaeuft, aendert auch Abschalten der virtuellen
Maschine nichts am Gesamtenergieverbrauch.)

Nun mit (einem) Avanti-Server:

Bei modernen Kerneln faellt bereits auf, dass "top" zwar in der
Zusammenfassungszeile mehr als 99% "idle" anzeigt, der avanti-
Prozess aber 8-10% Verbrauch einer virtuellen CPU hat (und nicht 0.05%).
Evtl. sind das natuerlich 10% der extrem heruntergeregelten CPU,
alle anderen Dienste ausser Avanti bleiben aber unterhalb der
Wahrnehmungsschwelle.

Und hier wie auch bei aelteren Kerneln zeigt der vSphere-Client einen
Anstieg der CPU-Zuteilung um ca. 130 MHz pro leerlaufendem Avanti,
(gleich 3-4 "Watt") und da ich auf mehreren VMs jeweils mehrere
unterschiedliche avanti-Versionen vorhalte, laeppert sich das ziemlich.

Festzuhalten bleibt also erst einmal, dass die sleep- oder usleep-Loesungen
eine ueblere Kruecke sind, als sowieso schon klar war.

---

Ich wollte daher die aelteren Avanti (die ich eigentlich nie benoetige,
nur installiert vorhalte) ueber xinetd aufstarten, d.h. sie sind
gar nicht aktiv, weil xinetd das listen() auf dem Socket leistet und
die Prozesse nur bei Bedarf startet.

Leider ist es da so, dass sich avanti dann ueber die nicht auffindbare
Konfigurationsdatei beschwert: Arbeitsverzeichnis ist durch xinetd
auf "/" gestellt (avanti macht dann "//" draus, aber egal), vor
allem aber kann man sich nicht darauf verlassen, dass argv[0] den
Pfad zum Executable enthaelt, das ist eine Verabredung der Shell
mit dem Rest der Welt, xinetd startet avanti aber ohne Zuhilfenahme
einer Shell (gut). Anscheinend gibt es ueberhaupt keinen portablen
Weg, ~den~ Pfad des aktuell laufenden Executables zu bestimmen,
es scheint auch nicht unbedingt eine wohldefinierte Fragestellung...

Vermutlich ist das auch der Grund fuer gewisse Schwierigkeiten,
avanti ueber init-Skripte, die den jeweiligen Unix-Distributionen
nachempfunden sind, glatter in Systeme einzupassen: Je elaborierter
die Mechanismen, umso wahrscheinlicher, dass avanti *nicht*
von einer Shell aufgestartet wird und daher argv[0] nicht so wie
erwartet ist und er die Konfigurationsdatei *nur* in /etc findet
(und acon ueberhaupt nicht). Fuer den Windows-Avanti kann man
einen Platzhalter-Parameter -run angeben und einen zweiten,
positionalen Parameter fuer das Arbeitsverzeichnis, das waere auch
fuer Linux nicht verkehrt (bzw. noch besser ein Schalter -f
fuer den Pfad zur .ini-Datei und dort eine Konfigurationsoption
fuer das Arbeitsverzeichnis...)

---

So funktioniert es jedenfalls (allerdings nicht ausfuehrlich
getestet), naemlich mithilfe eines zwischengeschobenen Wrapper-
Skripts, das Avanti aus der Orientierungslosigkeit hilft:

[ avanti ist in /usr/local/avanti/avanti4955/bin installiert,
dort liegt auch folgendes Wrapper-Skript  launch-slave.sh:


#!/bin/bash
cd ${1:-/usr/local/avanti/avanti4955/bin/}
./avanti -slave 2>> /var/log/avanti/avanti4955.log


und der Mechanismus ist in /etc/xinetd.d/avanti4955_in
(abweichender Name zu /etc.init.d/avanti4955, damit ich
mittels chkconfig zwischen beiden Varianten schalten kann)
konfiguriert:


# default: on
# description: seldomly used avanti database server
service avanti
{
        id              = avanti4955
        type            = UNLISTED
        flags           = NOLIBWRAP
        socket_type     = stream
        port            = 4955
        protocol        = tcp
        wait            = no
        user            = avanti
        server          = /usr/local/avanti/avanti4955/bin/launch-slave.sh
        server_args     = /usr/local/avanti/avanti4955/bin/
#       log_type        = syslog
        log_on_success  = PID HOST EXIT DURATION
        log_on_failure  = HOST USERID
        disable         = no
}


So wie ich das bislang getestet habe, liefert diese Kombination
xinetd + avanti-slave   den Clients dieselbe Funktionalitaet
wie ein "normaler" Avanti (insbesondere koennen mehrere Jobs ueber
eine Verbindung abgewickelt werden, der Start der dafuer notwendigen
individuellen acon-Prozesse erfolgt auf einer tieferen Ebene, die
wieder gemeinsam ist). Da die Serverkomponente "avanti -daemon"
allerdings durch den Superserver xinetd ausgetauscht ist, erfolgt
das Logging teilweise mit den xinetd-Mechanismen

11/7/6 at 10:02:13: START: avanti4955 pid=7558 from=192.168.168.198
11/7/6 at 10:02:17: EXIT: avanti4955 status=0 pid=7558 duration=4(sec)

teilweise durch die in launch-slave.sh eingerichtete Umleitung von
stderr in eine avanti-spezifische Logdatei:

-------------------------------
setting cpu time rlimit to 120
slave 2 starting '././acon'
WorkDir=././
Directory for DB=avdemo is ../share/avanti/avdemo
Database : cat ; User : opac ; Access : 0

JOB done
slave 2 starting '././acon'
WorkDir=././
Directory for DB=avdemo is ../share/avanti/avdemo
Database : cat ; User : opac ; Access : 0

JOB done
slave finished ok
-------------------------------

und groesstenteils ueberhaupt nicht (da normalerweise von avanti -daemon
uebernommen).


Fuer den Produktivbetrieb der Datenbanken ist die Ansteuerung ueber
xinetd gewiss nicht optimal (ausser man benoetigt die ausgefeilten
Zugangssteuerungen, die xinetd bietet und avanti nur eingeschraenkt,
und auch nur, wenn selbst kompiliert), insbesondere wo nun auf die
konzeptbedingte Performance-Einbusse nun ueber die zwischengeschaltete
Shell noch eine weitere draufgesetzt wird, aber fuer einen
* testweisen
* Alternativzugang
* ohne Umkonfiguration
* auf einem anderen Port
eignet es sich m.E. ganz gut.

viele Gruesse
Thomas Berger