Beiträge von mhagge

Vielen Dank! Ist nicht dramatisch, aber doch lästig..

Viele Grüße
Markus Hagge

Gute Idee. Ich hab mal "mytop" während einer solchen Aktualiserung mitlaufen lassen.

Einer Query bin ich zwar nicht habhaft geworden, aber ich aber die Dauer zwischen den einzelnen Abfragen scheint recht lange zu sein. Es sind ständig 3 offene Verbindungen mit dem User "liveconfig" zur DB "LIVECONFIG" vorhanden - die befinden sich aber teilweise sehr lange im "Sleep"-Status, bevor sich der "Time" Wert wieder zurücksetzt (ich habe kein einziges mal unter 10 Sekunden beobachtet, meistens so im Bereich um die 15 Sekunden. Den Status "Query" für eine dieser Verbindungen habe ich dabei kein einziges mal gesehen, der einzige Anhaltspunkt dass sich auf der DB doch ewas tun muss ist, dass sich eben dieser "Time"-Wert verändert und auch wieder zurücksetzt)

Leider nicht sehr ergiebig - MySQLtuner beschwert sich zwar weiterhin über

[!!] Joins performed without indexes: 3981

und

"Adjust your join queries to always utilize indexes"

(der Server ist wegen eines Kernel-Updates gestern Morgen mal neu gestartet worden, das sind also Zahlen für etwa 24 Stunden Laufzeit)

aber in den Logfiles schlägt sich das nicht nieder

Ich hab mal das Slow-Query-Log und "Log queries not using indexes" aktiviert, vielleicht hilft das bei der Suche nach der Ursache

Zitat von kk

Auf den ersten Blick vermute ich, dass irgendeine SQL-Abfrage, die zum Aufbau der vHost-Konfiguration verwendet wird, langsam ist. Eine "durchschnittliche" vHost-Konfiguration hat ja nur eine überschaubare Zahl an VirtualHosts, daher fällt es meistens nicht auf wenn vielleicht ein Datenbankindex fehlt.

Das könnte hinkommen - mysqltuner beschwert sich über eine hohe Zahl von "Joins performed without indexes" und schlägt vor, das zu optimieren

Zitat von mhagge

Hallo Herr Kepler,
Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf

Als Ergänzung: 4 Kerne Intel CPU (also 8 virtuelle Kerne) und 36 GB Speicher. Das System rennt ansonsten wie eine 1, keinerlei Probleme mit Geschwindigkeit oder Auslastung (die Domains gehören zu einem Webbaukasten-System, welches ich hoste. Dessen Datenbanken sind allerdings auf einem anderen Server, nicht auf dem gleichen, dort ist nur "Web") - nur eben halt an dieser einen Stelle hakelt es.

Hallo Herr Kepler,

Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf

Die SSD hatte ich neulich ja schon mal getestet, zwar nicht überragend, aber auch nicht Mega-schlecht (und auf jeden Fall deutlich schneller als eine HDD) - an der sollte es also nicht liegen. Woran könnte es noch liegen?

Mir fällt ansonsten gerade noch auf, dass im /conf/acme-Verzeichnis fast 13000 Dateien sind - muss das so sein?

Ich denke, ich weiß inzwischen wie das Problem entsteht. Und zwar passiert es immer dann, wenn Liveconfig viele Zertifikate auf einmal erneuern will - dann kommt es zu Timing-Problemen.

Das "Problem" ist, dass Liveconfig für jede einzelne Änderung die webx.conf neu schreibt. Pro SSL-Zertifikat sind das 2 Änderungen (einmal für die Domain mit www und einmal für die ohne). Werden jetzt z.B. 10 Zertifikate auf einmal erneuert dauert es bei einer "Schreibezeit" von 2-3 Minute pro webx.conf also minimum 20 Minuten, eher mehr, bis der Apache sämtliche für die Veränderung erforderlichen Config-Änderungen überhaupt erst zur Verfügung hat. Selbst mit meinem deutlich verlängerten RELOAD.min bzw. RELOAD.max fallen dann welche hintenrüber, weil bei den Domains die Konfiguration für das ACME-Challenge halt noch nicht geschrieben ist.

Ich könnte nun also entweder die Zeit nochmal deutlich verlängern (das würde theoretisch gehen, an der Config ändert sich ansonsten so häufig auch nichts, nur halt gerade dann ist es nervig so lang warten zu müssen), ich könnte einstellen, dass nie mehr als 2-3 Zertifikate auf einmal verlängert werden (das geht aber IMHO derzeit nicht) oder aber Liveconfig müsste dazu gebracht werden, die Config nicht für jede Änderung neu schreiben zu müssen (bei manuellen Änderungen kann ich das ja nachvollziehen, dass das erforderlich ist, aber bei solch Dingen wie Zertifikatsverlängerungen weiß LE doch dem Grunde nach, dass da jetzt x Änderungen aufeinmal kommen - warum werden diese Änderungen dann nicht auch auf einmal in die Config geschrieben?)

Daneben suche ich noch einen Weg, die Apache-Config zu verschlanken - ich nutze Liveconfig nur als Verwaltungs-Tool für mich selber, aus der Config könnte also allerhand entfernt werden, weil ich es gar nicht nutze (die Einträge für mod_php z.B. oder mod_compat und was da sonst noch so standardmäßig drin ist). Ich vermute mal damit liesse sich das Problem auch deutlich entschärfen. Vermutlich muss ich dafür irgendeine .lua-Funktion überschreiben, nur geht das ohne Nebenwirkungen?

Die "Überbrückung" der Weiterleitung macht ja Liveconfig, wenn ich das richtig sehe - insofern kann das mit der Basic-Version wohl so auch nicht klappen (evtl. wenn man manuell eine "Dauerausnahme" für die ACME-Konfigurations-URL in die Apache-Config schreibt, das müsste eigentlich gehen).

Das ist aber hier auch nicht das Problem, ich kann mir die ACME-Bestätigungs-URLs wenn ich sie mir aus dem Protokoll rauskopiere sogar manuell aufrufen. Nur im Moment der Verifizierung klappt das anscheinend manchmal nicht. Ich habe jetzt die RELOAD-Zeiten enorm hochgestellt ("min" auf 500), da sich da ausser den SSL-Zertifikatsverlängerungen nicht groß was ändert ist die Verzögerung akzeptabel, seit dem ist das Problem nicht mehr aufgetreten - obwohl ich mir das nach der Erklärung von Herrn Keppler so recht nicht erklären kann. Schaun wir mal.

Zitat von kk

Bitte? Da stimmt dann aber was mit der Hardware nicht...
Wir fahren mit LiveConfig auch regelmäßig mal Lasttests mit >10.000 Domains in einem Vertrag, auch da dauert die Erstellung der .conf-Dateien keine Sekunde.
Steht der Server vielleicht recht "unter Dampf"? Ein hoher I/O auf dem Server insgesamt wäre die enizige Erklärung, warum das so lange dauert.

Naja gut, er ist im laufenden Betrieb, aber hat eigentlich reichlich Reserven und mit den restlichen Systemdiensten gibt es auch keine Probleme - die .conf mit dem Web hat 12 MB Größe.

Ein Apache-Reload dauert etwa 10 Sekunden. Ich hab mal ein Tempfile mit DD geschrieben:

# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 3,88818 s, 276 MB/s

Nicht überragend, aber auch nicht grottig schlecht würde ich sagen.

Warum hier 1 GiB keine 4 Sekunden dauert, die web.conf von Liveconfig mit 12 MB Größe aber solange braucht wüsste ich allerdings auch gerne Wie könnte man das genauer eruieren bzw. wo könnte da ein Ansatz für eine Bremse sein?

Zitat von aziegler

DNS-Einträge verändert worden? Domain umgezogen?

Nene, die habe ich unter eigener Kontrolle Die Homepage lässt sich ja auch normal aufrufen

Es gibt aber einen korrespondierenden Eintrag im Apache-Error-Log - das HTML-Fragment dürfte von einem 404er stammen. Die ACME-Challenge wird nicht gefunden, dann geht es an der Stelle natürlich nicht weiter.

Das wiederrum könnte damit zusammenhängen, dass in dem Web beinahe 3000 Domains sind - es dauert eine Weile die .conf-Datei zu schreiben (runde 3 Minuten, trotz SSD). Deswegen ist meine Vermutung ein Timing-Problem, vermutlich wird die Verifizierung versucht wenn die Konfiguration noch nicht verfügbar ist. Ich hab schon die Apache.MINLOAD und MAXLOAD-Werte angepasst bzw. deutlich höher gesetzt, der Dokumentation nach sollte das die LE-Verifizerung auch berücksichtigen, aber entweder das passiert nicht oder da ist noch ein anderer Faktor, auf den ich noch nicht gekommen bin

Zitat von aziegler

was ist denn die konkrete Fehlermeldung?
es gibt Fehler da hilft einfach erneut versuchen nichts

Naja, bei vielen (den meisten, würde ich sagen) hat es ja geklappt, manuell funktioniert es auch. Nur bei einigen wenigen ist da ein

Invalid response from http://domain.de/.well-known/acme-challenge/VKqmkl70BSwL40Rz63Wl3vwUdHFPqGsuRMsNsA8Xqac: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html "

(domain.de ersetzt die eche Domain)

Deswegen fürchte ich eine temporäre Überlastung (wobei es da kein anderes Anzeichen für gäbe, die Munin-Graphen z.B. sind in Ordnung und es gibt auch keine Einträge im Error-Log oder sowas) oder ein Timing-Problem oder sowas

Wobei mir gerade auffällt, dass der HTML-Code, der sich da in der Fehlermeldung andeuet nicht von der fraglichen Domain stammt, da geht es anders los.

Wenn die automatische Erneuerung der LE-Zertifikate aus welchen Gründen auch immer fehlgeschlagen ist - versucht Liveconfig das dann später nochmal oder muss ich mich manuell drum kümmern?

Hintergrund der Frage ist, dass ich hier eine Handvoll Zertifikate habe, die aus mir noch unbekannten Gründen nicht verlängert wurden - im ACME-Tab steht auch eine Fehlermeldung drin bzw. im liveconfig.log ebenfalls (das ist der Schwung von der DSGVO-"Panik" - ich hoffe nicht, dass das zuviele auf einmal waren, dann habe ich das Problem ansonsten alle 3 Monate.....

Nun sind die Zertifikate noch fast 30 Tage gültig, es ist also noch genügend Zeit. Versucht Liveconfig die Erneuerung später nochmal, oder kann / sollte ich schon manuell tätig werden (ich habe eins mal getestet, einfach nochmal auf "speichern" klicken reicht)

Hat wunderbar geklappt, vielen Dank!

@ManDal:nicht über die GUI, aber direkt über MySQL (oder ein kleines Script, was man dann wiederrum in die GUI einbauen kann) lässt sich das mit den Hinweisen relativ schnell erstellen

Ich verwende Liveconfig in einem Projekt nur für mich als "Verwaltungserleicherungstool", Kunden haben da keinen Zugriff drauf.

Nun will ich bei diesem Projekt die PHP-Version ändern und stehe vor einem Problem: wie mache ich das massenhaft und nicht nur bei einzelnen Domains. Alle Domains (es sind mehrere 100) durchzuklicken und von Hand zu ändern kann doch eigentlich nicht die Lösung sein? In der API gibt es aber, wenn ich nichts übersehen habe, auch nichts passendes.

Wie macht man das also am besten? Gibt es einen Weg über die Datenbank evtl. (Liveconfig läuft auf MySQL). Ich weiß soll man nicht (kann ich auch nachvollziehen), aber vielleicht gibt es ja einen "Hack"

Zitat von kk

[*]ca. 90 Sekunden nach dieser Änderung triggert LiveConfig bei Let's Encrypt die Prüfung dieses Tokens an (90 Sekunden deshalb, weil es bis zu 60 Sekunden dauern kann bis die neue Apache-Konfiguration aktiv ist).

Ist dieser Wert irgendwo konfigurierbar? Ich habe eine recht umfangreiche Config mit sehr vielen Domains, seit der Umstellung des webs auf FastCGI (das hat es nochmal weiter aufgebläht) scheint da der Apache länger als die 90 Sekunden zu brauchen, bis die Apache-Config aktiv wird.

Ich erhalte jedenfalls ebenfalls immer wieder die Meldung "Invalid Response" und im access.log ist auch ein Error 404 für die Abfrage zu sehen. Wenn ich "/.well-known/acme-challenge/usw" versuche manuell parallel aufzurufen lässt es sich auch im Browser nachvollziehen. Warte ich etwas, kann ich es im Browser problemlos aufrufen, aber die LE-Überprüfung ist dann bereits fehlgeschlagen - daraus schließe ich, dass es bei mir aufgrund des Umfangs der Apache-Config einfach zu lange dauert, bis diese aktiv ist.

Ich hab mir jetzt beholfen, in dem ich in der .httpd.conf im Web ein

Zitat

AliasMatch "^/.well-known/acme-challenge/(.*)$" "/var/www/web1/conf/acme/$1"

aufgenommen habe - das scheint auch zu funktionieren, damit gibt es bis jetzt jedenfalls keine solchen Probleme mehr. Allerdings bin ich mir nicht ganz sicher, ob das nicht ggf. andere Nachteile mit sich bringt, wenn ich irgendwo einstellen kann dass LE einfach etwas länger mit der Überprüfung des tokens wartet fände ich das eleganter.

Sieht gut aus - der Speicherverbrauchsgraph bleibt seit dem Update gerade

Viele Dank!

Zitat von bash

Ja... super das noch jemand den Fehler hatte.. Ich hab zum Glück vor dem eigentlichem Update auf v2 ein Image des alten Systems komplett gemacht.. Nach 1 Tag war mein Server wegen zu wenig RAM nicht mehr erreichbar bis ich einen Neustart gemacht hatte.. Problem hab ich das selbige... Darauf hin hab ich dann erstmal mein v1.9 Image eingespielt, weil hab ja nicht Lust alle paar min/stunden das ding neuzustarten..

Naja, den ganzen Server muss man nicht neu starten, um das Problem (vorläufig) zu beheben - das habe ich oben nur gemacht, um irgendwelche möglichen Quereffekte des Updates auszuschließen.

Ein

/etc/init.d/liveconfig restart

(notfalls per Cron alle x Stunden aufgerufen) tut es auch und alle anderen Dienste laufen ungestört weiter (und auch der "Ausfall" von Liveconfig ist sehr kurz). Der Weisheit letzter Schluß ist das natürlich aber auch nicht, besser wäre es wenn es ohne solche Maßnahmen ginge.

Zitat von kk

Wir haben da tatsächlich was im Bereich des ACME-Clients gefunden - es handelt sich aber "nur" um virtuellen Speicher (VSZ, nicht RSS). Fehler ist behoben, Update gerade in Arbeit.

Scheint leider nicht alles gewesen zu sein - ich hab das Update heute Mittag gleich eingespielt und so vor 30 Minuten etwa den Server einmal komplett neu gestartet, um irgendwelche Quereffekte oder Reste alter Prozesse auszuschließen.

Zitat

ps aux | grep liveconfig

root       504  0.0  0.0   4492  1524 ?        Ss   20:22   0:00 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
root      1639  0.0  0.0   4216   672 ?        S    20:22   0:00 /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats
root      2233  0.0  0.0  44928  2628 ?        Ss   20:22   0:00 /usr/sbin/liveconfig
livecon+  2237  0.0  0.2 631088  8668 ?        Sl   20:22   0:00 liveconfig [server]
root      2238  0.0  0.2 267596 10560 ?        Sl   20:22   0:00 liveconfig [client]
root      4375  0.0  0.0  14192  2324 pts/0    S+   20:30   0:00 grep liveconfig

5 Minuten später

root       504  0.0  0.0   4492  1588 ?        Ss   20:22   0:00 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
root      1639  0.0  0.0   4216   672 ?        S    20:22   0:00 /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats
root      2233  0.0  0.0  44928  2628 ?        Ss   20:22   0:00 /usr/sbin/liveconfig
livecon+  2237  0.0  0.2 672068  8988 ?        Sl   20:22   0:00 liveconfig [server]
root      2238  0.0  0.2 267596 10960 ?        Sl   20:22   0:00 liveconfig [client]
root      5429  0.0  0.0  14192  2156 pts/0    S+   20:36   0:00 grep liveconfig

Der VSZ-Wert für liveconfig [server] steigt zwar langsam, aber kontinuierlich weiter an. das ist insofern mißlich, als dass dann irgendwann auch andere Prozesse Probleme mit dem virtuellen Memory bekommen.

Dann hätte das Serverlein ziemlich viel RAM, wenn das im Peak RSS wäre Vielen Dank!