Zeige Artikel 11 bis 19
« Zurück 10 Neuere Artikel
Displaying posts with tag: Performance (reset)
Hotspots in MySQL finden

Ich ringe gerade mit einer Datenbank, die sehr viel Load hat. Wann immer ich versuche dort ein Monitoring zu installieren fällt mir der Server um, weil die Load vom Monitoring und die Load vom normalen Betrieb einfach zu viel für die Maschine sind. Zum Glück hat mir ein Kollege einen SPAN-Port auf einer anderen Maschine eingerichtet, auf dem ich eine Kopie des Traffics bekommen kann, der meinen Server so beschäftigt hält.

Mein SPAN-Interface ist eth1, und so kann ich mit

CODE:tcpdump -s 1536 -i eth1 host master and port 3306 -c 10000 -w keks etwa ein Sample des Traffics bekommen, der zum Host master auf dem MySQL-Port geht. Nach 10000 mitgeschnittenen Paketen wird das Sample abgebrochen, und mein Dump wird in die Datei keks geschrieben.

In …

[Mehr]
MySQL Proxy / Erkennung von SQL Injections

Über einen Blogpost von Björn bin ich gerade übr etwas sehr interessantes gestolpert: Den MySQL Proxy.

In dem o.g. Posting geht es insbesondere darum, unter Nutzung des zwischengeschalteten Proxy Servers die SQL Befehle manipulieren und analysieren zu können – u.a., um hiermit SQL Injections erkennen zu können – spannende Sache. Anschauen will ich mir das aber insbesondere, um einen Einsatz als Loadbalancer auszuprobieren. Dazu dann später nochmal mehr…

Related Posts:

[Mehr]
Zehn Zentimeter

Kristian, wenn Du über Performance redest, dann redest Du immer von verteilten, asynchronen Systemen. Verteilte, asynchrone Systeme sind doof, schwer zu programmieren und laufen der Theorie zuwider, die ich an der Uni gelernt habe. Ich warte glaube ich lieber auf schnellere Prozessoren. Viel Spaß beim Warten. Godot wird Dir Deine neue CPU bestimmt bald bringen.

Ein Gigahertz ist ein Takt pro Nanosekunde. Bei Lichtgeschwindigkeit kommt das Signal in einer Nanosekunde in etwa 30cm weit. In der Cray, die jetzt als Bar in der Lobby vom RZ der Uni Stuttgart Dienst tut, sind alle Kabel Vielfache von 30cm lang. Dadurch ist jedes Kabel auch eine Delay von 1, 2, 3 oder 4ns.

Heutige Rechner haben einen Takt von so um die 3 GHz. Der Teil der Maschine, der mit 3 GHz gepowert ist hat wenig überraschend einen …

[Mehr]
InnoDB zwischen 5.0.26 und 5.0.36

Zwischen 5.0.26 und 5.0.36 ändert sich die Struktur der Locks auf dem InnoDB Buffer Pool. Installationen mit einem sehr großen Buffer Pool (16G oder mehr) und einer hohen Zahl von gleichzeitigen Connections (4+ CPUs) können in Lock Contention auf dem globalen InnoDB Buffer Pool sterben. In Cacti sieht das dann zum Beispiel so aus:

5.0.26, hohe InnoDB-Last, speichergesättigte Umgebung (RAM > Datenbankgröße), viele Clients und CPUs.

CPU-Verbraucht > 100% wird nicht richtig gezeichnet, daher die Lücken im Graph. Man beachte die System-Time (Das Rote ist gefährlicher Lock-Belag!).

Eine zweite Maschine mit einem vergleichbaren Graph sieht nach dem Upgrade auf 5.0.36 wie folgt aus:

5.0.36 in derselben Situation. Blau (Usertime) vergleichbar, fast kein Rot (Systemtime, Lock Waits) mehr.

Slides zum Performance Tuning Vortrag

Slides zum Performance-Tuning Vortrag. Und hier sind die Slides zum Performance-Tuning-Vortrag, den ich auf der European MySQL Customer Conference in München gehalten habe.

Die MySQL-Artikel in diesem Blog sind in der Kategorie MySQL zu finden. Der von mir im Vortrag angesprochene Beitrag Leben mit Fehlern - der Schlüssel zum Scaleout ist nun ebenfalls verlinkt.

Performance Tuning Vortrag in München

In dieser Meldung verweist Heise auf die MySQL Anwenderkonferenz in München. Ich bin laut Programm für den Performance Tuning Vortrag vorgesehen und muß ggf. auch noch für einen Kollegen einspringen, der gerade von der Grippe niedergestreckt wurde.

Ein anderes Thema wird wohl die Reorganisation des Servers in Community und Enterprise Edition und das Release von "Merlin" als MySQL Network Monitor- und Advisor sein.

Herzlichen Glückwunsch zur 1.0, …

[Mehr]
MySQL Performanceprobleme mit einem Profiler analysieren

Oprofile ist ein Profiler. Und zwar einer, der die Performance Measurement Instrumentation verwendet, die in moderne CPUs eingebaut ist, wenn diese vorhanden ist. Der Profiler braucht also keine speziell für Profiling compilierten Binaries, sondern zieht sich statische Samples des Programmzählers aus dem laufenden System und analysiert diese: Es findet heraus, welcher Prozeß gerade aktiv ist, welche Bibliothek in diesem Prozeß gerade verwendet wird und wenn Symboltabellen vorhanden sind (Kein "strip" auf die Bibliothek oder das Programm angewendet), dann weiß Oprofile sogar, welche Funktion oder Methode gerade aktiv ist.

Das kann man auch auf ein laufendes MySQL anwenden. Dies hier zum Beispiel ist ein mysqld, der mit einem Haufen MyISAM Tabellen arbeitet und nicht zu busy ist. Man kann sehen, daß aus irgendeinem Grund sehr viel Zeit …

[Mehr]
Leben mit Fehlern - der Schlüssel zum Scaleout

Scaling Patterns

In 2004 habe ich auf dem Linuxtag einen kleinen Vortrag zum Thema Skalierbarkeit gehalten. Schon damals war die Message an verschiedenen Stellen im Vortrag "Jedes Readproblem ist ein Caching-Problem, jedes Schreibproblem ist ein Verteilungs- und Batchproblem":

Zum Skalieren muß man seine Anwendung in Teilanwendungen unterteilen und die Daten replizieren. Die Replikation muß asynchron erfolgen, ohne Two Phase Commit (2PC), sonst gewinnt man wenig bis nichts. Schreibzugriffe müssen verzögert und gebatched werden, damit sie effizienter abgewickelt werden können. Um weitere Flaschenhälse zu vermeiden, muß man die Datenhaltung in die …

[Mehr]
MySQL-Leistungsdaten erfassen

In http://vvv.koehntopp.de/rrd überwache ich die Leistungsfähigkeit meines Dedicated Servers. Gestern abend habe ich mein kleines Erfassungsscript einmal um einige Funktionen erweitert, um auch die internen Leistungsdaten von MySQL mit auszulesen und abzuspeichern - jedenfalls in Auszügen.

Das Resultat sind die Grafiken in mysql-traffic und darunter in meiner Grafiktapete.
"MySQL-Leistungsdaten erfassen" vollständig lesen

Zeige Artikel 11 bis 19
« Zurück 10 Neuere Artikel