THEMA: Fehlermeldungen bei vielen Zugriffen

Hallo,

wir haben in Thüringen seit dem 2. Spieltag (21.10.) massive Probleme mit unserem Ergebnisdienst der Erwachsenen (ed.thsb.de). Es scheint sich um eine Art Überlastung durch zu viele Zugriffe zu handeln. Wenn viele Nutzer auf die Seite zugreifen, also an Spieltagen und kurz danach, erscheinen sowohl im Front- als auch im Backend die Meldungen:

"Error: Failed to start application: Could not connect to MySQL server."

"User dbo612594188 already has more than 'max_user_connections' active connections", im Frontend teils mit dem Zusatz:

"Fatal error: Uncaught Error: Call to a member function write() on null in /homepages/43/d17749029/htdocs/ed/components/com_clm/clm/core.php:65 Stack trace: #0 [internal function]: clm_core->_destruct() #1 {main} thrown in /homepages/43/d17749029/htdocs/ed/components/com_clm/clm/core.php on line 65"

Folgendes versuchten wir bereits:

• Leeren/Freigeben des Cache in Joomla
• Änderung der Methode der Session-Speicherung unter „System – Konfiguration“: Vorher war „Datenbank“ eingestellt. Siehe:
• joomla.stackexchange.com/questions/334/s...ler-database-or-none (wobei None und PHP identisch sind)

Wir haben zwischen dem 1. und 2. Spieltag außer Updates von Komponenten keine wissentliche Veränderung am System vorgenommen. Momentan laufen Joomla 3.9.1 und CLM 3.6, wobei sich die Joomla-Version seit dem 2. Spieltag änderte. Es gibt den Verdacht, dass es mit den Einstellungen unseres Hosters 1&1 zusammenhängen könnte.

Kommen die Probleme einem von euch bekannt vor? Habt ihr Ideen, woher sie rühren und wie man sie beheben könnte?

Einmal mehr ein großes Danke an deie Entwickler und euch allen schon mal einen guten Rutsch ins neue Jahr.

Von einem solchen Problem höre ich das erste Mal.
Wie sind die Parameter im Moment durch den Provider/Tarif gesetzt?
Hier was zum Vergleich:
Produktive Umgebung:
-max_connections 500
-max_user_connections 25
Test-Umgebung:
-max_connections 80
-max_user_connections 20
Die Session-Speicherung erfolgt in beiden Fällen über Datenbank und die Session-Gültigkeit ist auf 15 min festgelegt.

Ggf. solltet ihr auch beim Provider anfragen.

Vielen Dank auch für die guten Wünsche.

hätte da auch die Frage welches webhostingpaket bei 1&1 das ist, das ihr da habt.
kommt mir alles etwas suspekt vor.
Liebt auch vielleicht ein SPAM-bot? oder seid ihr bei einem in Ungnade gefallen?
hilfreich wäre auch zu wissen....
- welche php-version ist eingestellt?
- welche mysql-cersion?
können wir Zugriff auf eure site bekommen?
wir wollen nichts ändern.
aber ein akeeba-backup von der site wäre bei der Analyse sehr hilfreich
und ein Blick in das logging. wie häufig da wirklich Zugriffe erfolgten-
sensible Daten gerne via PN (private notes) in diesem Forum.

php hatten wir direkt vor dem 4. Spieltag aktualisiert. Derzeit ist die Seite down. Am Telefon sagte uns 1&1, dass maximal drei Verbindungen gleichzeitig erlaubt sind. Uns wundert dann aber, dass es vorher funktionierte. Außerdem schrieben sie uns den angehängten Text. Hätte ihn gern direkt eingefügt, aber es wurden zu viele Links im Beitrag bemängelt.



Obwohl offline funktioniert die Datenbank derzeit nicht fehlerfrei. Vielleicht ist doch irgendwo Schadcode? Vermutlich werden wir die Seite daher neu aufsetzen. Es wäre allerdings schön, solche Fehler für die Zukunft zu vermeiden. Lassen sich Hinweise dazu aus dem Zitat ableiten?

Von Interesse wäre, welches webhosting-paket sie bei 1&1 haben. Ist das ein sehr schmalspuriges paket? wie heisst es?

interessant wäre zu wissen von welcher php-version auf welche php-version sie kürzlich umgestellt haben.

und an welchem Datum war der 4-te Spieltag?

welche CLM-version ist im Einsatz?

welche mysql-version?

und was versteht 1&1 unter 3 Verbindungen? Was ist für 1&1 "1" Verbindung?
Verbindungen zw. Webserver und DB-Server?
Oder wenn 1 Besucher auf die webseite schaut? oder?

btw: 1&1 sagt auch dass die meisten Zugriffe von bots kommen, und nennt auch gleich die mögliche Abhilfe... in robots.txt so konfigurieren, dass den bots die Suche auf der Website verboten wird.

Haben Sie die Datei robots.txt schon so konfiguriert?
das wäre das erste was ich in so einem fall tun würde...

dazu einfach dieses in die robots.txt eintragen:
User-agent: *
Disallow: /

die robots.txt muss im obersten Verzeichnis der domain stehen.#
wenn deine website auf einer subdomain liegt, ist die robots.txt von der domain massgeblich. Bei abc.def.com ist die robots.txt auf def.com:/ bestimmend.

und wenn dann noch....
Alle Meta-Robots auf „noindex,nofollow“ gesetzt sind,
ist schnell Ruhe im Karton zumindest was die meisten Bots betrifft.

wenn man noch mehr ausschliessen will, ist .htaccess die richtige Datei um das zu konfigurieren...

für mehr Details siehe auch: de.wikipedia.org/wiki/Robots_Exclusion_Standard


btw: das sind alles Dateien und Konfigurationsmöglichkeiten die jeder selbst für seine website ja nach Bedarf einsetzen kann.
Diese Dateien liegen ausserhalb des Einflussbereiches vom CLM. oder anders gesagt... wir können an diesen Dateien nichts tun. ... Das muss jeder selbst tun, wie bei jeder anderen website auch.


Für die weitere Analyse wäre es sehr hilfreich einen Zugang zu bekommen, oder einen Dump von ihrer website + DB.
das kann man sich am einfachsten mit akeeba-backup erstellen

ps:
Wie stellen sie fest dass ihre DB nicht richtig arbeitet wenn die website offline ist?

als addon.... wenn es "interne" Problem bei der DB gibt - vielleicht weil man mal selbst etwas mit sql-commands eingegriffen hat, oder wenn eine DB sehr sehr lange in Betrieb ist und viele Änderungen erlebte - , war es oftmals schon hilfreich die DB einfach komplett zu dumpen und zu restoren (mit drop table...). Dabei werden alle Beziehungen und indizes neu aufgebaut, und auch andere Ungereimtheiten bereinigt. Zuvor auf jeden Fall ein akeeba-backup machen.... und auch prüfen ob es alles beinhaltet....

Wir sind gerade dabei, die Seite (bis auf die Daten selbst) neu aufzusetzen.

pierre schrieb: Von 5.6 auf 7.2.13
16.12.2018
3.6.0
5.5.60

Wir nehmen an, dass es sich bei den Verbindungen um schreibende Zugriffe auf die Datenbank handelt.
Vielen Dank für die Hinweise. Einige hatten wir schon umgesetzt, anderes haben wir nun hinzugefügt.
Das war vielleicht falsch ausgedrückt. Die Adresse ed.thsb.de war deaktiviert und es war lediglich noch das Backend erreichbar und dennoch kam es zu den Problemen. Daraus schließen wir, dass doch irgendetwas an der Datenbank nicht stimmt.Guter Hinweis, das werden wir mal probieren.