max_connections erhöhen

[matzewe01]

Hmm... da werfe ich mal wieder meine Bedenken ein.
Wenn der Zugriff auf die Seite eh schon verboten ist... dann ist ja auch kein Zugriff auf ein Script erfolgt, die eine DB Verbindung herstellen hätte können.

Sprich = dürfte ich in der SQL-Statistik garnicht sehen.

Genau deshalb wäre ich der Sache mal etwas hinterher, warum es zu diesen ausetzer kommt.

 

[Lord_Icon]

    query_cache_size (>= 8M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    thread_cache_size (start at 4)
    table_cache (> 64)

Das sind ja Vorschläge, die sich ja alle auf das Aktivieren von Cache beziehen.

Aber wie arbeitet denn der SQL-Cache ?

Ohne Cache:
"SELECT * FROM 'Tabelle' " => würde z.B. 100 Zeilen ausgeben.

Danach erfolgt ein INSERT, sodas bei gleicher Abfrage 101 Zeilen ausgegeben werden.

Wenn ich nun Cache aktiviere = dann merkt dieser doch, das der Output sich schon im Cache befindet und gibt die (alten) 100 Zeilen aus. Statts die (neuen) 101 Zeilen.


Oder arbeitet der Cache hier anders?

Irgendwie so, das wenn ein INSERT oder UPDATE (bzw. generell eine Änderung erfolgt ist) das der Cache dann geleert wird... bzw. die gecachten Output-Werte der jeweiligen geänderten Tabelle.

 

[matzewe01]

Vergiss das mal mit dem query Cache, dieser ist offen gestanden schon spezielle genug, als dass man den explizit betrachten muss.

Der Querycache merkt übrigens wenn sich etwas an Tabellen geändert hat. das gecachte Objekt wird invalidiert, sobald sich etwas an den Betroffenen Tabellen ändert. Selbst dann, wenn das Objekt von der Änderung (Dessen Ergebnismenge) nicht betroffen ist.

Also quasi

select * from tabelle Limit 10;

Tabelle hat schon mehr als 10 Einträge und es kommen nun noch welche hinzu.

Trotzdem wird das gecachte Objekt invalidiert, obwohl das Ergebnis hintehrer immer noch das gleiche ist.

Das macht die Anwendung des Querycache etwas "kritisch".
Genauer gesagt, der Anwendungsfall, an dem der Query Cache wirklich etwas bringt will genau analysiert sein.


Der normale DB Cache, hält einfach seine auf Platte geschriebene und häufig angeforderten Daten zusätzlich im RAM.
Damit wird eine Suche etc. deutlich schneller, da die Daten schneller greifbar sind.
Allerdings hält der normale Cache eben nur die Rohdaten im RAM und nicht wie der query Cache ganze Ergebnisse einer Abfrage.

Ausserdem müssen die Abfragen identisch sein.

select * from tabelle; != SELECT * FROM tabelle;

Hier muss man also explizit aufpassen.

Auch eine Reihenfolgeänderung in der where Bedinungen, ist nicht mehr das identische Statement.
Hier geht mysql so vor, dass es eine Quersume / hash über das Statment bildet und anhand dieses hash die Eindeutigkeit fest stellt.
Also intern besteht dann eine Verweis:
"Sinngemäss"

abcDf34fgH548459843342 -> <Ergebnismenge>

 

[Huschi]

Wenn nun ein access Denied kommt, wer klemmt dann die Verbindung ab?
Richtig der Server, nachdem er dem Client die Begründung geliefert hat.

...und wird als aborted_connection gezählt. Wir reden aber über aborted_clients.

Die Anleitung im Rootforum ist zwar durchaus alt, die dort gefundene Konfiguration für den typischen Rootserver absolut ausreichend.

Wie gesagt, es sind sogar Fehler drin und damit totaler Quatsch!
Jeder Druchlauf MySQLTuner / tuning-primer liefert ein besseres Ergebnis als diese Anleitung.
Und hier werden die einzelnen Einstellungen sogar noch diskutiert und erläutert.
Das ist ein "verhältnismäßig guten Thread".

Das macht die Anwendung des Querycache etwas "kritisch".
Genauer gesagt, der Anwendungsfall, an dem der Query Cache wirklich etwas bringt will genau analysiert sein.

Nicht wirklich. Sicherlich ist der Query-Cache für eine Session-Table nicht besonders effizient. Aber in einem kleinen Shop-System ändern sich die Einstellungstabelle fast nie, die Kategorien recht selten und die Produkte evtl. alle paar Tage.
Oder ein Blog: Ein neuer Blog-Eintrag ändert die Content- und Tag-Tabelle. alles andere bleibt gleicht und wird dank des Query-Caches durchgängig zügig geliefert.
Und meistens werden die Queries von einer Script-Sprache abgesetzt die meist den selben SQL-String generiert. Inkl. Groß-/Kleinschreibung.

Der Query-Cache ist also nicht zu vernachlässigen.
Im Gegenteil: es ist der wahre Turbo-Boost unter MySQL.

Der normale DB Cache, hält einfach seine auf Platte geschriebene und häufig angeforderten Daten zusätzlich im RAM.

Du beschreibst einen Festplatten-Cache.
MySQL bringt also zum normalen Linux-eigenen HD-Cache zusätzlich Einen mit?
Das ist mir ehrlich gesagt ganz neu. Ich finde auch nichts in der MySQL-Doku dazu. Kannst Du bitte Belege dafür bringen?

huschi.

 

[Huschi]

Back to Topic:

Also bis dato WAREN ein paar DB auch extern geschalten.

Hatte ich vermutet...

Fraglich ist jetzt, ob ich jetzt auch alles richtig konfiguriert habe, sodass MYSQL tatsächlich nicht öffentlich ist.... aber dazu gibt es ja nmap.

Das Programm netstat ist etwas umgänglicher:

# netstat -tulpen |grep 3306
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      110        6351        1309/mysqld

MySQL lauscht hier nur auf dem localhostort.

Timeouts Connection: 300 - Keep-Alive: 15

Beide Timeouts sind für die Praxis zu hoch. Ein DoS ist relativ leicht möglich indem man Deine Apache-Threads mit offenen Verbindungen aus lastet.
Für Connection reichen 30 Sekunden und für KeepAlive 1-4 Sekunden.

Bild von PHPINFO bzgl. MYSQL/MYSQLI

Bitte nicht mehr extern lagern. Die Foren-Software bietet Dir die Möglichkeit Bilder anzuhängen.

MaxClients habe ich glaube ich nicht aktiviert.

Bitte Suchen: grep -R MaxClients /etc/apache2/
Du hast den MPM-Prefork.

huschi.

 

[matzewe01]

Du beschreibst einen Festplatten-Cache.
MySQL bringt also zum normalen Linux-eigenen HD-Cache zusätzlich Einen mit?
Das ist mir ehrlich gesagt ganz neu. Ich finde auch nichts in der MySQL-Doku dazu. Kannst Du bitte Belege dafür bringen?

huschi.

http://dev.mysql.com/doc/refman/5.1/en/buffering-caching.html

Lies das mal durch.
Sinn macht es mit dem eigenen DB Cache nur im Zusammenhang mit InnoDB.
Der Rest ist lediglich ein Keycache.
Ich sprach dabei klar vom Cachen von Datenbankobjekten. Nicht von Datendatein oder FS Objekten.

Zum Query-Cache:

Ja, der mag unter umständen wirklich etwas bringen. Aber wie grenzt Du diesen ein, dass er sich nur auf bestimmte Tabellen auswirkt?
Richtig, das geht nicht. Und daher ist der Querycache mit "vorsicht" zu geniesen bezw. dessen Vorteile schnell zu nichte, wenn andere häufig ändernde Datensätze, jene aus dem RAM verdrängen, die davon profitiert hätten.

Abortet_Connections und Abortet_Clients sind bislang noch keine sauber getrennten Statistikdaten. Daher ist der Wert aus abortet_clients leider auch nicht 100% aussagekräftig.

Magst Du im Gegensatz begründen, wo die Fehler in der Diksussion sind?

 

[Lord_Icon]

Das Programm netstat ist etwas umgänglicher:

Da bekomme ich folgendes zurück:

tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      60         90705868   20181/mysqld

Beide Timeouts sind für die Praxis zu hoch. Ein DoS ist relativ leicht möglich indem man Deine Apache-Threads mit offenen Verbindungen aus lastet.
Für Connection reichen 30 Sekunden und für KeepAlive 1-4 Sekunden.

Also bisher bin ich anscheind von DDoS-Angriffen verschont geblieben.
Wobei eh fraglich ist, was der Apache macht. Bedingt durch die Serverleistung denke ich mal nicht, das der DDos-Angriff den Indianier in die "ewigen Jagdgründen" schickt.

Bei einen Raid10 [4x1TB Enterprise Platten] und bis zu 16GB DDRII Ram (Xen Management [insofern frei]) + 12Ghz hoffe ich doch, das da reichlich LEistung da sein sollte, die die 10.000 Request beantworten sollten. (i hope so)

Würde ich also erstmal so lassen. Ist ja schließlich default... und die "macher" werden sich dabei schon was gedacht haben.

Bitte Suchen: grep -R MaxClients /etc/apache2/
Du hast den MPM-Prefork.

Tatsache... da isses:

Hauptsystem:~ # grep -R MaxClients /etc/apache2/
/etc/apache2/server-tuning.conf:        # highest possible MaxClients setting for the lifetime of the Apache process.
/etc/apache2/server-tuning.conf:        MaxClients         150
/etc/apache2/server-tuning.conf:        MaxClients         150

 

[matzewe01]

Da bekomme ich folgendes zurück:

tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      60         90705868   20181/mysqld

Wenn der externe Zugriff nicht mehr benötigt wird, solltest Du Netzwerkverbindungen (skip-netowrking) des Mysql abschalten.

Das verleutet ggf. Angreifer nur zu brute Force Attacken zumal das mysql Protokoll auch nicht den besten Ruf in Punkto Sicherheit hat.

 

[Huschi]

@matzewe01
Ich hab eigentlich kein Bock auf ein Know-How-Duell.
Aber das was Du hier ablieferst ist mehr schlecht als recht.

Dein "allgemeiner DB Cache" ist plötzlich nur für die InnoDB und letztendlich von den Parametern nichts anderes als ein read_buffer_size und key_buffer_size für MyIsam-Tabellen.
Und der Query-Cache muss nicht auf spezielle Tabellen reduziert werden. Der füllt und leert sich automatisch. Daran ist nichts mit "vorsicht" zu genießen. Den muss man nur richtig verstehen. Dann braucht man den auch nicht mehr schlecht reden.

Zu Deiner Aussage über die Statistikdaten:
Bitte erstmal testen und dann Bemerkungen dazu schreiben.

Magst Du im Gegensatz begründen, wo die Fehler in der Diksussion sind?

Bitte spezifiziere diese Frage noch mal. Welche Diskussion, welche Fehler?

huschi.

 

[Huschi]

Bedingt durch die Serverleistung denke ich mal nicht, das der DDos-Angriff den Indianier in die "ewigen Jagdgründen" schickt.

Soll ich?
Ganz einfach: Ich öffne 150 Telnet-Sitzungen auf den http-Port.
Laut Deinem Timeout habe ich dazu 5 Minuten Zeit. (Sogar per Hand machbar.)
Und jedesmal wenn eine von Server dann "zwangs getrennt" wird, öffne ich eine Neue.
Dein Apache bleibt für alle Anderen unerreichbar. Das ist ein einfache DoS!
Da ist es sch*** egal wieviel Festplatte, Ram oder sonst was vorhanden ist.
Es sind ganz allein Deine Parameter dafür verantwortlich.
Aber wenn Du mir nicht glaubst.....

Würde ich also erstmal so lassen. Ist ja schließlich default... und die "macher" werden sich dabei schon was gedacht haben.

Ufff!

huschi.

 

[matzewe01]

MOD: Full-Quote entfernt!

Das Caching unter InnoDB ist doch etwas mehr als nur ein Read_Buffer_Cache....
Das Caching und die Möglichkeiten des Cachens hängen bei Mysql stark von der eingesetzten Engine ab.
Weshalb ich das auch von Anfang an gesagt habe, dass die Möglichkeiten / das Cachen unter Innodb besser abläuft.

Aber lassen wir es dabei.

-> Den Query Cache redet keiner schlecht.
Der Anwendungsfall für eine optimale Nutzung eines query-caches ist allerdings etwas "Speziell".

http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

Redundante Daten im RAM bei nicht 100% identischen Abfragen, Low Memory Prunses sind ggf. die Folge und letztendlich ist der Vorteil des Query Cache damit verloren. Und ob man den Cache so gross gestalten möchte, dass alle Varianten von Abfragen und deren Ergebnisse in den RAM passen, will ich mal in Frage stellen.
Man muss sich also schon überlegen, ob und in welchem Umfang dieser Sinn macht, will man es ideal nutzen.

Damit endet meine Diskussion hier.
Mir scheint die Diskussion nicht mehr "sachlich" und "neutral" zu sein.

 

[Lord_Icon]

Ganz einfach: Ich öffne 150 Telnet-Sitzungen auf den http-Port.
Laut Deinem Timeout habe ich dazu 5 Minuten Zeit. (Sogar per Hand machbar.)
Und jedesmal wenn eine von Server dann "zwangs getrennt" wird, öffne ich eine Neue.
Dein Apache bleibt für alle Anderen unerreichbar. Das ist ein einfache DoS!
Da ist es sch*** egal wieviel Festplatte, Ram oder sonst was vorhanden ist.
Es sind ganz allein Deine Parameter dafür verantwortlich.

Klingt überzeugend. Aber meines Wissens nach, würde das nur bedingt was bringen.

Ändere ich die 300 auf 30 würde sich nur bedingt was ändern.
Ok. Deine 150 Sitzungen würden bereits nach 30sek. geschlossen werden... aber was bringt das.
Wenn einer einen DoS-Angriff durchführt, wird das wohl nicht per Hand machen. Ein Script würde somit sofort wieder eine neue Verbindung etablieren wollen.... wo dann die 150 Sitzungen wieder erreicht sind => und die anderen stehen wieder leer da.

ggf. schafft es der eine oder andere schneller zu sein als das DoS-Script.

Auf der Gegenseite würde ich mal behaupten wollen, das dann das ganze System um das doppelte belastet ist. Denn der Server muß ja 300 Sitzungen je Minute bedienen. Da könnten sogar die anderen Dienste in mitleidenschaft gezogen werden... oder langsamer antworten.

<= nur mal so als Grundgedanke. Soll jetzt kein Widerspruch zu deinen Hinweis sein.

Aber wenn Du mir nicht glaubst.....

Als Servermaskottchen steht das hier garnicht zur Diskussion.
Evtl. poste ich mal meine Grundgedanken zum Problem bzw. zum gegebenen Hinweis.

 

[matzewe01]

Ändere ich die 300 auf 30 würde sich nur bedingt was ändern.
Ok. Deine 150 Sitzungen würden bereits nach 30sek. geschlossen werden... aber was bringt das.
Wenn einer einen DoS-Angriff durchführt, wird das wohl nicht per Hand machen. Ein Script würde somit sofort wieder eine neue Verbindung etablieren wollen.... wo dann die 150 Sitzungen wieder erreicht sind => und die anderen stehen wieder leer da.

Slowloris Attacken könntest Du damit ggf. besser parieren.

 

[Huschi]

Damit endet meine Diskussion hier.
Mir scheint die Diskussion nicht mehr "sachlich" und "neutral" zu sein.

Dito!
Dennoch:

Man muss sich also schon überlegen, ob und in welchem Umfang dieser Sinn macht, will man es ideal nutzen.

Bei 4 GB Ram braucht man nicht viel überlegen. Und wie schon mehrfach gesagt: MySQLtuner gibt einem ja meist die passenden Werte vor.
Es ist heute alles viel einfacher als noch 2005 oder 2006. (Denn aus diesen Jahren stammen Deine Links.)
Willkommen in der Zukunft!

huschi.

 

[matzewe01]

MOD: Full-Quote entfernt!

Die Dikussion ging auch noch weiter und endete nicht mit dem ersten Post.
Eine gute Alternative zum query-cache ist der Einsatz von memcachd.
Dieser lässt sich sowohl auf Mysql als auch Applikationsebene PHP etc. einbinden und nutzen.

Sicherlich spielt bei mehr als 4 GB RAM 200 300 MB für den query-cache keine nenenswerte Rolle mehr. Aber mit der Zunahme an Daten und unterschiedlichen Webanwendungen ist der QueryCache einfach nicht mehr effizient genug. Zumindest gibt es bessere Alternativen dazu zählen neben memcache auch der Cache von Inndb.

 

[Huschi]

Ändere ich die 300 auf 30 würde sich nur bedingt was ändern.

Doch. 150 Sitzungen über 300 Sekunden sind alle 2 Sekunden eine Connection.
Bei 30 Sekunden hast Du 5 Connection die Sekunde.
Damit hast Du mit Zusatz-Tools bessere Chancen Angriffe zu erkennen und dagegen zu wirken.
Z.B. kann mod_evasive einen solchen Script-Kiddie schneller bannen ohne dass vorher der Server in die Knie geht.

Auf der Gegenseite würde ich mal behaupten wollen, das dann das ganze System um das doppelte belastet ist.

Nicht wirklich. Das Ziel ist ja letztendlich Seiten auszuliefern. Und dafür brauchst Du Ressourcen. Erst wenn es jemand schafft alle Ressourcen auf sich zu binden, ist es ein DoS.

Aber es war ja nur ein gut gemeinter Rat.

huschi.

 

[Huschi]

Mal eine andere Frage: Ist das bei Euch im Rootforum nicht auch schon "Trollen" wenn jemand unbedingt recht haben will und immer abstruser wird?
Jetzt kommst Du plötzlich mit memcached.
Und ja, ist eine sinnvolle Ergänzung. Ich nutze sie meist für Session-Daten, damit die eben nicht ständig aus der DB geholt werden müssen.
Aber willst Du als 'Webhoster' einem Kunden der sich über eine zu langsame DB beschwert sagen: "Dann Programmier Dein xt:Commerce|Wordpress|Drupal|... doch auf memcached um!"

Also bitte bleib auf dem Boden. Die Diskussion ging die ganze Zeit um MySQL und nicht um die Application-Ebene.

PS: Wir mögen hier keine Fullquotes. Bitte halte Dich dran. Mag Dich nur ungern verwarnen.

huschi.

 

[matzewe01]

Mal eine andere Frage: Ist das bei Euch im Rootforum nicht auch schon "Trollen" wenn jemand unbedingt recht haben will und immer abstruser wird?
Jetzt kommst Du plötzlich mit memcached.
Und ja, ist eine sinnvolle Ergänzung. Ich nutze sie meist für Session-Daten, damit die eben nicht ständig aus der DB geholt werden müssen.
Aber willst Du als 'Webhoster' einem Kunden der sich über eine zu langsame DB beschwert sagen: "Dann Programmier Dein xt:Commerce|Wordpress|Drupal|... doch auf memcached um!"

memcached wird auch auf mysql Db Seite genutzt.
http://dev.mysql.com/doc/refman/5.1/en/ha-memcached-using.html
Die Implementierung in die Anwendung erfolgt an zentraler Stelle.
Aber alternativ mit weniger Aufwand propagiere ich schon die ganze Zeit die Verwendung von InnDB.

Ich habe auch nicht verleugnet, dass mit dem Einsatz von memcached Aufwände entstehen.

Ergänzend dazu zum alten leidigen Thema und owohl es auf performanceblog gut beschrieben ist.

Der query-cache wurde für einen "ganz besonderen" Fall konzipiert.
Hohe Reads, ggf. komplexe Abfragen mit Joins etc. und sehr geringer Änderung der Datenbasis.
Und hier trumpft der query-cache 1a.

Alles was deutlich davon abweicht macht den Vorteil zunichte.
Wenn man dieses nicht ernsthaft berücksichtigt, kannn es sogar dazu führen, dass plötzlich der IO des RAMs zum Engpass wird.
Auch das habe ich schon mehrfach erlebt, weil Entwickler den query-cache als die Lösung für alle Designfehler gesehen haben.
Die Ursache hierbei liegt meistens darin, dass man nachfolgenden Fakt unterschätzt:

Der Querycache erfordert min. 2 fachen IO auf dem RAM.
1. Lesen der Daten , was u.U. auch schon im RAM liegt,
2. Schreiben des Ergebnis in den RAM
3. Lesen der Ergebnis für die auslieferung.

Ist obige "Anforderung" gegeben. Keine Änderung auf der Datenbasis, holt sich der Query-Cache die Daten direkt aus dem RAM.
Ein lesender Zugriff auf die schon richtige Ergebnismenge.
Limitierende Faktoren sind nun die Grösse des definierten Query-Caches, denn kommen mehr Objekte hinzu als dieser Fassen kann, plumpsen andere wieder raus und müssen wieder explizit geladen werden.

Ungünstige Joins und Abfragen können den Cache vollständig in Beschlag nehmen. Die max. Objektgrösse kann man jedoch limitieren. Auch ist es möglich, bestimmte Tabellen und Abfragen quasi zu blacklisten.
Auf einer "Webhosting" Umgebung wessen Änderungen der anwendungen der Webanwendungen etc. nicht im eigenen Verantwortungsbereich liegt (quasi Kunden einspielen können was sie wollen, ohne dass man es selbt mit bekommt) ist der Wartungsaufwand um solche Ausschlusslisten zu pflegen, sehr hoch bis gar nicht mehr machbar.

 

[Huschi]

Thorstens Schrei nach endgültiger Klärung ist nochmal hoch gekommen.
Also schauen wir uns doch mal die Ausgangsstellung genauer an:

Da ich mittlerweile recht viele HP's auf dem Server habe,

Wir reden also eher von einem Server für "Massenwebhosting".
Kein spezieller Kundenserver, der nur eine Website, einen Shop oder sonst etwas hostet und den man genau darauf optimieren bzw. gar die Software darauf anpassen kann.
Fazit: Alle Ratschläge die in Richtung "spezieller Fall" gehen (also so ziemlich alles was Du hier vorbringst) sind für den Thread-Ersteller für den Kuckuck.
Denn für Massenwebhosting gilt es eine optimale Mitte zu finden. Und keine Spezialfälle aus zu graben, wo etwas nicht so gut funktioniert.

Und noch Deine recht hilflose Argumentation:

Der Querycache erfordert min. 2 fachen IO auf dem RAM.

Und memcached bringt also keine 2fache IO auf dem RAM mit sich?
Alles was im RAM zwischen gelagert wird, egal ob HD-Cache, Buffers oder sonstige Dinge bringen IO-Zugriffe mit sich.

Dann hast Du noch eine Aussage in einer PM an Thorsten zum Thema "aborted_connections oder aborted_clients" geschrieben:

Steigt einer der beiden Werte deutlich an, ist das durchaus aussagekräftig. Zumindest für die Fehlersuche eindeutig genug.

Das man auf Fehlersuche gehen kann/sollte/muss ist klar. Aber es macht wenig Sinn am Server nach Fehler zu suchen, wenn der Client die Fehler verursacht. Das ist nämlich der wesentliche Unterschied.

PS: Für Deine Unterstellung bei Thorsten, ich hätte die "emotionale Diskussion" hier eingeleitet und nachträglich raus gelöscht:
Schau mal nach wo "geändert von huschi" drunter steht. Dann wird Dir auffallen, dass dies nur in Deiner Phantasie statt gefunden hat.

huschi.

 

[matzewe01]

PS: Für Deine Unterstellung bei Thorsten, ich hätte die "emotionale Diskussion" hier eingeleitet und nachträglich raus gelöscht:
Schau mal nach wo "geändert von huschi" drunter steht. Dann wird Dir auffallen, dass dies nur in Deiner Phantasie statt gefunden hat.

huschi.

Mein Fullquote wurde entfernt, warum?
-> Als Moderator mit entsprechenden Recht kann man im vBB seine Beiträge ändern ohne, dass hier ein editiert erscheint.
Öffentlich wollte ich die Diskussion eigentlich nicht führen.

Aber das ist jetzt schon ein starkes Stück.
Vieleicht kannn es ja einer der vielen Leser bestätigen, dass unmittelbar vor meinem Post, "Dass die Diskussion nicht mehr sachlich genug ist "von Dir noch die aussage im Raum stand, Sinngemäss" Es wäre eine starkes Stück was ich hier vom Stapel lasse".

Wenigstens Ehrlichkeit hätte ich von Dir erwartet.