Hi Markus,
vielen herzlichen dank für die antworten! ich hätte
ja gar nicht gedacht, dass sich doch so zahlreiche
mit sowas auskennen :)
Deine Thematik ist interessant und fordert die Antwortenden - das macht Spaß. :-)
mysql scheint nun deutlich an die grenzen gestossen
zu sein. in stosszeiten sind evtl. auch selects von
255/s möglich. jedenfalls knapp.
Hm. Sind das 255 client-Requests pro Sekunde (das würde mich von den Socken hauen), oder macht ein Client ganz viele SELECTs?
Ich würde mal hinterfragen, ob Du die Zahl der SELECTs nicht dramatisch reduzieren kannst. Leider müßtest Du dafür ins Detail gehen - aber es riecht mir danach, Deinen Entwurf daraufhin zu überprüfen, ob Du nicht eine oder mehrere Größenordnungen von SELECTs durch eine geänderte Architektur ersetzen kannst.
Beispiel: Wenn Du einen JOIN durch eine Schleife mit SELECTs über die zweite Tabelle simulierst, arbeitest Du massiv am Konzept der Datenbank vorbei, die genau das viel besser könnte. Einen so krassen Patzer möchte ich Dir natürlich nicht unterstellen - aber prüfe mal, ob Deine Aufgabenstellung wirklich nicht mit deutlich weniger SELECTs zu lösen ist. Denn ein SELECT _ist_ teuer, weil die Datenbank erst mal die 4GL in 3GL-Code übersetzen muß, und das womöglich immer wieder.
Wie steht es mit Host-Variablen? mySQL kann das m. E. noch nicht, aber vielleicht ist genau das Dein Problem?
Performance-Tuning bzw. Schwachstellenanalyse ist ein Job, der _sehr_ ins Detail geht, also _alle_ verfügbaren Informationen nutzen muß, um zu wirklich guten Ergebnissen zu führen. Gerade bei SQL lohnt sich diese Mühe aber viel mehr als irgendwo sonst - Du kannst hier durchaus mal zwei, drei, vier Zehnerpotenten (!) an Geschwindigkeit herausholen, wenn Du den richtigen Ansatz machst.
Ich habe auch nicht exakt verstanden, was das Problem Deiner Implementierung ist. Du schreibst, es sei die Zahl der SELECTs; Sven ist eher auf die Performance jedes einzelnen SELECTs eingegangen, was natürlich auch wichtig ist, aber an einer anderen Stelle des möglichen Problems ansetzt.
Erst nachdem hier alles ausgereizt ist, solltest Du die Idee, mySQL oder etwas Vergleichbares zu verwenden, verwerfen und etwas Eigenes implementieren.
Denn um damit dieselbe Performance und Stabilität zu erreichen, kannst Du eventuell Mannjahre (!) an Implementierungsaufwand verbraten. Das will sehr gut überlegt sein.
mittlerweile scheint apache nicht mehr mit mysql
kommunizieren zu können.
Der Apache kommuniziert doch überhaupt nicht mit der Datenbank ... nur die vom Apache gestarteten Anwendungsprogramme tun das ... oder was habe ich mißverstanden?
mittlerweile bekomme ich leider nur noch "die seite
kann nicht angezeigt werden."
Von wem? Was der Browser auswürfelt, ist egal.
Lies die Logfiles Deiner Server-Anwendunge - sowohl Apache als auch mySQL (oder was immer Du im Einsatz hast - ein vernünftiges Logging-Feature muß nämlich auch Deine memory-pool-Lösung besitzen, sonst kriegst Du sie nicht fehlerfrei).
wie gesagt: jede datenbank scheint mit der unmenge
an selects probleme zu bekommen.
Wie gesagt: Überprüfe Deinen Entwurf. Mußt Du wirklich so viele SQL-Statements ausführen?
alternativ - da auch mittlerweile einfacher zu
realisieren - zog ich ein filesystem in betracht;
files mit den entsprechenden einträgen werden dann
eben includiert - falls vorhanden - und - falls
nicht vorhanden - aus der DB ausgelesen, dann das
file geschrieben.
Das ist natürlich eine Alternative - wenn Deine Aufgabenstellung es zuläßt.
Du hast bisher nur über Deinen Realisierungsversuch geschrieben, bist aber sehr wenig darauf eingegangen, was Deine SELECT-Statements überhaupt _tun_.
Liest Du immer wieder dieselben Daten? Dann ist ein Caching-System natürlich durchaus eine Möglichkeit.
Darfst Du überhaupt cachen, oder mußt Du zeitaktuelle Werte aus der Datenbank entnehmen, weil parallel zu Deinen SELECTs jemand in diese Datenbank schreibt?
Das alles will überlegt sein, bevor Du Dich auf einen Implementierungspfad festlegst. Es ist ein Riesenunterschied, ob Du eine Datenbank als Transaktionssysten oder als Cache benutzt - und im letzteren Falle gibt es zweifellos performante Alternativen, und das _kann_ eventuell sogar etwas ganz Triviales in Dateiform sein.
- welche werte müsste ich nun definitiv im apache-
kernel erhöhen, die sich auf die anzahl der
reinzulegenden werte (arrays) von derzeit 2 Mio
beziehen? gibts hier irgendwo verständliche
informationen wie das zu handeln ist
Analog zu einem anderen Posting möchte ich Dir ans Herz legen, Deine Aufgabenstellung zu hinterfragen.
Es riechst alles danach, als ob Du mit einer anderen Vorgehensweise viel glücklicher wirst, als wenn Du an den Symptomen herumdokterst (genau das wäre nämlich das Einstellen irgendwelcher Speicher-Größenwerte).
- ist in meinem fall von dem SHM evtl. komplett
abzuraten und vielleicht doch ein "file-cache-
system" zu verwenden?
Vielleicht. Das kommt auf Deine Aufgabenstellung an.
Es ist auf jeden Fall das erste, was Du prüfen solltest.
Viele Grüße
Michael