Kurz und gut - Episode #04 In der Gruppe bleiben: MySQL Ressource Gruppen

Ich werde in Seminaren, Workshops oder in Kundenprojekten in Sachen MySQL immer mal wieder mit Dingen konfrontiert, auf die ich ad hoc keine Antwort habe, bzw. mit denen ich noch keine Erfahrung gesammelt habe. 

Das Problem

In dieser Folge geht um eine dieser vielen „vergleichenden Fragen“, die gerne in Schulungen gestellt werden. So auch dieses Mal. „Oracle Datenbanken (Okay, MySQL ist auch eine Oracle DB 😉; gemeint ist aber diesmal die andere.) haben einen Ressourcen-Manager. Gibt es so etwas bei MySQL auch?“

Auf bestimmten Datenbankservern möchte man die zur Verfügung stehenden Ressourcen gerne etwas kontrollierter verteilen. Ein User oder eine bestimmte Gruppe von Anwendern sollen mit Ihren Anfragen nicht die gesamte Performance des Systems an sich reißen und damit eine andere Gruppe von Nutzern oder Jobs ausbremsen. Gerade Oracle hat hier, seit mehreren Versionen, ein recht komplexes „Regelwerk“, mit dem man in verschiedenen Bereichen fein granular steuern kann. Gibt es das auch für MySQL?

Jein. Für MySQL ist das Thema recht jung. Ab der Version 8.0 kann zumindest die Verwendung von CPUs gesteuert werden.

Die Lösung

Aktuell kann über Gruppen festgelegt werden, welche/-r Session/User auf welche CPUs Zugriff hat und mit welcher Priorität sie/er Zugriff auf ebendiese bekommt. Die Gruppen werden in die Kategorien „USER“ und „SYSTEM“ gegliedert. Per Default werden Gruppen für beide Kategorien bereitgestellt, die nicht verändert werden können. Natürlich können aber weitere Gruppen hinzugefügt und frei gestaltet werden. Wir konzentrieren uns in diesem Beispiel rein auf den Zugriff auf die CPUs an sich und nicht auf die Priorisierung der Zugriffe (Thread_Priority). In der Praxis wird dieses Feature unter Linux ohnehin nur dann nutzbar sein, wenn die „Capability CAP_SYS_NICE“ aktiviert wird. Mehr dazu unter [1].

Auf unserem Testsystem stehen uns zwei virtuelle CPUs zur Verfügung:

bash-4.4# cat /proc/cpuinfo | grep processor
processor	: 0
processor	: 1
 

Wir legen nun zwei Ressource Gruppen an:

• HIGH: nutzt beide CPUs
• LOW: nutzt nur CPU 1
  

mysql> create resource group high type user vcpu = 0-1;
Query OK, 0 rows affected (0.01 sec)

mysql> create resource group low type user vcpu = 1;
Query OK, 0 rows affected (0.00 sec)
 

Um zu testen, ob die Gruppen überhaupt einen Einfluss auf die Performance haben, nutzten wir ein kleines Apache JMeter Testszenario, welches wir auf die berühmte MySQL-Testdatenbank „sakila“ loslassen. Wir gehen auf JMeter hier nicht näher im Detail ein. Wichtig ist an dieser Stelle nur, dass mit diesem Werkzeug parallel mehrere Verbindungen und unterschiedliche „Queries“ gegen ein System „gerichtet“ werden können (Benchmark).

Während der Ausführung misst JMeter die Performance anhand unterschiedlicher Kenngrößen. Wir werden uns zum Vergleich der beiden Tests jedoch einfach auf einen einzigen, aussagekräftigen Wert konzentrieren: „Durchsatz an Transaktionen pro Sekunde“.

Der einzige Unterschied bei der Durchführung unserer beiden Messreihen liegt in dem folgenden Statement, welches nach dem Verbindungsaufbau (und vor dem eigentlichen Test) die „Ressource Group“ aktiviert.

mysql> set resource group high;
Query OK, 0 rows affected (0.00 sec)
 

Beim ersten Durchlauf arbeiten wir mit der Gruppe „low“, bei zweiten mit der Gruppe „high“. 

Wie unschwer zu erkennen ist, gibt es ein fast mathematisch vorbildliches Resultat. Der Durchsatz an Transaktionen pro Sekunde ist mit „halber CPU-Power“ (obere Teil der Abbildung) auch fast halb so hoch (über alle vier Testszenarien; übrigens, alle Szenarien lesen Daten per „SELECT“).

Noch mehr Informationen zu diesem Thema finden Sie in der Doku [1] oder bekommen Sie bei uns.

Sie haben eine Frage und/oder ein Problem mit MySQL? Sprechen Sie mit uns! Nutzen Sie gerne die Kommentarfunktion dieses Blogs.

Seminarempfehlung