MySQL Select mit LOW_PRIORITY

[Memo]

Guten Abend,

ich suche einer Möglichkeit bestimmten Abfragen eine geringere Priorität zu geben.

Hintergund: Eine kleine Select-Abfrage die für sich alleine wenige Millisekunden dauert, hat sich im Multiuserbetrieb als Bremse herausgestellt. Wird die Abfrage ausgeführt und andere Rechner sind lesend/schreibend auf der selben DB unterwegs, steht alles bis diese eine Abfrage ausgeführt ist.

Für Insert, Update und Delete gibt es LOW_PRIORITY und HIGH_PRIORITY, aber für Select nur HIGH_PRIORITY.

Kennt jemand einen Weg, ein Select in der Warteschlange des Servers nach hinten zu befördern?

Danke für Ideen.

[alcaeus]

Hallo,

das wird nicht geben. Wenn dann musst du alle INSERT- und UPDATE-Statements mit LOW_PRIORITY oder sogar DELAYED starten, damit die SELECT-Statements eher drankommen.

Allerdings kann auch die Storage Engine schon weiterhelfen. MyISAM sperrt bei Schreiboperationen immer die ganze Tabelle, waehrend InnoDB nur die betroffenen Zeilen sperrt. So ist nicht alles blockiert, wenn mal ein INSERT laenger dauert. Was da allerdings noch anfaellt sind Index-Updates, welche natuerlich zeitaufwaendig sind. Da solltest du mal ueberpruefen, welche Kardinalitaet die Indizes haben.

Greetz
alcaeus

[Memo]

Zitat von alcaeus:

das wird nicht geben. Wenn dann musst du alle INSERT- und UPDATE-Statements mit LOW_PRIORITY oder sogar DELAYED starten, damit die SELECT-Statements eher drankommen.

Würde ich ja, nur bräuchte ich es genau anders herum.

Zitat:

Allerdings kann auch die Storage Engine schon weiterhelfen. MyISAM sperrt bei Schreiboperationen immer die ganze Tabelle

InnoDB hat andere Geschwingigkeits- und Speichernachteile. Die Nachteile dieser Konstellation überwiegen leider.

Zitat:

Was da allerdings noch anfaellt sind Index-Updates, welche natuerlich zeitaufwaendig sind. Da solltest du mal ueberpruefen, welche Kardinalitaet die Indizes haben.

Wie gesagt, das fragliche Select-Statement ist sehr schnell, wird natürlich durch viele lesende Zugriffe angemessen verlangsamt, nur blockiert es seinerseids alle anderen Zugriffe(lesend/schreibend).
Die Indizes sind (imho) so ausgereizt, damit die Select's performant ablaufen. Laut Explain gibt es nichts zu verbessern.
Aber eines stimmt, die hauptsächlich beteiligte Tabelle hat mehrer Millionen Einträge. Verkleinern hilft natürlich massiv, nur ist es keine Lösung.

[Bernhard Geyer]

Wieviel RAM-Speicher genehmigt sich den MySQL (und wieviel ist den vorhanden). Je nach Installation und Konfiguration ist MySQL sehr konvervativ und verschenkt sehr viel Performance aufgrund der Konfiguration.

[Memo]

Kann ich aus dem Hut nicht sagen. Ich schaue morgen mal nach der Konfiguration.

[Memo]

Ich habe mal einige Versuche angestellt:

Engine: myisam

System: Intel 4 Kern 2,67 GHz mit 2GB Ram
Prozessorauslastung bis auf 100% (ein Kern genutzt)
Speicher gerade mal 30%
key_buffer-size=129M

jetz mal key_buffer-size=1G
gleiches Ergebnis

Im Kofler(MySQL-Buch) steht auch nur, dass Tuning ein ganzes Buch füllen würde und reisst das Thema dann nur kurz an.

Welche Schraube könnte man noch anziehen?

[gsh]

Zitat von Memo:

System: Intel 4 Kern 2,67 GHz mit 2GB Ram
Prozessorauslastung bis auf 100% (ein Kern genutzt)

also wenn nur ein Prozzesorkern benutzt wird dann hast du wahrscheinlich nur einen Arbeiterthread eingestellt. Leider kann ich dir gerade nicht genau sagen wie die Option heißt aber du solltest bei 4 Porzzesor kernen 8 Arbeiterthreads haben um den Prozzesor optimal ausnutzen zu können.

[Memo]

Zitat von gsh:

also wenn nur ein Prozzesorkern benutzt wird dann hast du wahrscheinlich nur einen Arbeiterthread eingestellt. .

Eine solche Einstellung kenne ich nicht. In der Referenz und mit Google lässt sich auch nichts passendes finden.
Meinst Du eventuell Cluster-Server?

[alcaeus]

Theoretisch sollte MySQL im threaded-mode arbeiten, und somit mehrere Kerne benutzen. Mit was fuer einer DB-Groesse haben wir es hier zu tun?

Zitat von Memo:

InnoDB hat andere Geschwingigkeits- und Speichernachteile. Die Nachteile dieser Konstellation überwiegen leider.

Das kann ich so nicht stehn lassen. Es kommt ganz drauf an wie du InnoDB konfigurierst. Das Ding kann teilweise viel performanter laufen als MyISAM - natuerlich abhaengig von der Datenbank. Eventuell waers mal geschickt wenn du ein paar Infos ueber die Tabelle posten koenntest (Aufbau, Index-Kardinalitaeten, Anzahl Datensaetze), dann koennte man eher was machen. Ohne Blick auf die Datenbank laesst sich da nichtmal ein Hauch von Optimierung betreiben.

Um es kurz zu sagen: ein LOW_PRIORITY bei SELECT gibt es nicht - du musst wenn schon die INSERTs und UPDATEs mit LOW_PRIORITY ausfuehren, wenn die Abfrage schneller laufen soll. Andere Alternative waere die Ergebnisse zu cachen, aber wenn da wiederum einige INSERT- und UPDATE-Statements laufen dann bringts das nicht unbedingt.

Greetz
alcaeus

[Memo]

Zitat von alcaeus:

Theoretisch sollte MySQL im threaded-mode arbeiten, und somit mehrere Kerne benutzen. Mit was fuer einer DB-Groesse haben wir es hier zu tun?

Im Gigabyte-Bereich, mit mehreren Millionen(3 stellig) Tupeln.

Zitat von Memo:

Das kann ich so nicht stehn lassen. Es kommt ganz drauf an wie du InnoDB konfigurierst.

Mal ein simples Beispiel:

Tabelle InnoDB ; ca. 2.000.000 Datensätze; 220000 KB
select ID,Feld1 from tabelle where Feld1 like '%1234567%' ca. 1 Minute

Explain
select_type = simple
type=all
possible_keys=NULL
Key=Null
ref=Null
Rows=2125855
Extra=Using Where


Gleiche Konstellation. Einzige Änderung, Engine=MyIsam
< 2 Sekunden
Explain gleich.

Wie sollte man InnoDB konfigurieren damit es den Wert einer MyIsam erreicht?