Kürzlich herausgefunden, dass mein MySQL-Server 90% hohe CPU-Auslastung bei der Simulation über gleichzeitige 100-500 Thread-Anfrage
trifftmit den Standardeinstellungen plus folgen in my.cnf
%Vor%Ich bemerke, dass max_connection bis zu 500 erreichen kann, threads_created kann auch hoch bis 200-500 gehen und ich denke, das hat tatsächlich eine ungewöhnlich hohe CPU
verursachtAnstatt also die Standardeinstellungen zu verwenden, habe ich
angepasst %Vor%Mit dem gleichen Belastungstest ist die CPU auf 10% und darunter abgesunken ... Allerdings merke ich, dass die max_connection nie mehr 500 erreicht. Es ist jetzt weniger als 50 ...
Wird dies von thread_cache_size verursacht, die ich angepasst habe? Standardmäßig ist es 0. Oder ist irgendwo etwas nicht in Ordnung ... Ich frage mich in diesem Fall, ob der MySQL-Server korrekt mit der Max-Verbindung getestet wurde. Ich möchte testen, wie wenn gleichzeitige Threads die max_connections treffen können, aber irgendwie trifft es nie mit der gleichen Menge, die ich zuvor getestet habe. Seit der Änderung trifft es nie mehr als 50.
Irgendeine Idee?
Das Erstellen neuer Threads (da ich davon ausgehe, dass Ihre Anwendung kein Verbindungspooling verwendet) benötigt eine ordentliche Menge an Overhead. Wenn MySQL Threads auf diese Weise wiederverwendet (bis zu 16), verwendet es nicht mehr die zusätzliche CPU, um Threads so oft zu erstellen, und es ist auch wahrscheinlich, dass die Operationen zeitnah beendet werden, wodurch die Verbindung schneller geschlossen und daher gehalten wird weniger Verbindungen gleichzeitig geöffnet.
Nur eine Vermutung: -)
Ihre Verwendung von
%Vor%spielt eine wichtige Rolle bei der Begrenzung der Aktivität. Siehe
für detaillierte Erklärungen und Testempfehlungen.
Der Standardwert war 0 = unbegrenzt für gleichzeitige innodb_threads - aber die Gefahr besteht darin, dass der Systemkontextwechsel für so viele aktive innodb_threads, die gleichzeitig ausgeführt werden, übersteuert wird.
Tags und Links mysql