Skip to content
{ 2008 06 10 }

--with-debug=full

Falls Ihr mal Ursachenforschung betreiben müsst, warum auf einem Produktivsystem mit nur wenigen hundert Besuchern am Tag die MySQL-Performance absolut unterirdisch ist:

Bevor Ihr nach nicht optmierten Queries Ausschau haltet, einfach mal checken, ob MySQL mit

--with-debug(=full)

kompiliert wurde.

Ein halber Tag ging dabei drauf, diese dämliche Ursache für die fast durchgängige 100%-CPU-Usage des mysqld und dessen grottige Performance zu lokalisieren...

Posted by Marcel on Dienstag, Juni 10, 2008, at 09:46. Tagged Arbeit, Code-Snippets. Follow any responses to this post with its comments RSS feed. Both comments and trackbacks are currently closed.

{ 3 } Comments

  1. Igor | 11. Juni 2008 at 10:01 | Permalink

    war das jetzt gentoo oder opensuse?
    *duck*

  2. -ron- | 14. Juni 2008 at 10:26 | Permalink

    Ih, das ja mal eklig. Solche Fehler sind echt hassenswürdig :) Aber guter Tipp!

  3. ths | 16. Juni 2008 at 08:35 | Permalink

    ich finde das weltfremd. wenn man selbst ein dickes Paket wie Mysql kompiliert, weiß man eigentlich, was man tut. Und Debugmodus ist für Testumgebung, nicht Produktion.
    Wenn man das Problem gelöst hat, muss auf jeden Fall ncohmal frisch ohne Debugmodus kompiliert derselbe Test laufen, bevor man
    auch nur daran denken kann, das ganze produktiv zu machen.

    Ich hatte mal einen Denkfehler mit Semaphoren gemacht, dadurch kam es zu Race conditions. Im Debugmodus hatte das Binary gänzlich anderes Laufzeitverhalten und alles hat korrekt funktioniert.

    Die Test-Binaries direkt nach Produktion überspielen finde ich grenzwertig.