Geschwindigkeit - Speed Kills?

[Taffspeed]

so sieht so ne query aus. modifizierbar sind sie:

SELECT p.*,

m.id,m.name,m.mgroup,m.email,m.joined,m.avatar,m.avatar_size,m.posts,m.aim_name,m.icq_number,

m.signature, m.website,m.yahoo,m.integ_msg,m.title,m.hide_email,m.msnname, m.warn_level, m.warn_lastwarn,

g.g_id, g.g_title, g.g_icon, g.g_dohtml , pc.*

FROM posts p

LEFT JOIN members m ON (p.author_id=m.id)

LEFT JOIN groups g ON (g.g_id=m.mgroup)

LEFT JOIN pfields_content pc ON (pc.member_id=p.author_id)

WHERE p.topic_id=xxx and p.queued != 1

ORDER BY something LIMIT xxxx, 20

könnte man den markierten join vor den members-join setzen? ich weiß normalerweise dürfte sich nichts ändern, aber da es sich um einen blöden side-effect handelt, könnte man ja mit solchen irrsinnigkeiten glück haben

wenn man sich da z.B. den Arbeitszeitenthread ansieht, der im Sekundentakt geöffnet wird, woraufhin dauernd alle 16000 Antworten neu geladen werden müssen...

gibt es da nicht eine möglichkeit, dass nur die datensätze geladen werden die auch angezeigt werden? man weiß ja die seitennr welche geladen werden soll, da müsste man sich doch vorab schon "ausrechnen" können welche beiträge zur anzeige gebraucht werden?!

[axeman]

denn die werden sowieso nicht oft geöffnet

wer sind "die"?

[Dannyo]

wer sind "die"?

Threads aus dem Jahr 2003, die schon irgendwo in den Tiefen der Foren verschwunden sind.

[axeman]

aber gerade bei den grossen, stark frequentierten threads könnte es sein, dass einfach db-blocks zu oft von der platte gekratzt werden müssen, was natürlich die performance beeinflusst. ein ausreichend dimensionierter buffer cache würde dem abhilfe schaffen.

aber wie gesagt - es war nur eine idee und ich habe keinen dunst von den speicherstrukturen bei mysql.

[Vicious]

ich werde die die ideen mal aufgreifen, vielleicht sinds ja solche kleinigkeiten, am ehesten der Hinweis mit der buffer-size, bei mysql (myisam) gibt es versch. buffer, wobei einer verdächtig niedrig ist.

[axeman]

bei mysql (myisam) gibt es versch. buffer

welche wären das? würd mich interessieren.

[neuron]

Einfacher (vernünftiger) wär's wohl noch, ganz einfach auch in Zukunft die Länge von mehr oder weniger sinnvollen Monumental-Threads in der Art zu begrenzen, wie das nun eh gemacht wurde (also schließen & neuen aufmachen & die alten gegebenenfalls ent-pinnen). Soweit sollten Langeweile bzw. Ego-Trip bestimmter, jetzt nicht namentlich genannter Herrschaften nun auch wieder nicht reichen dürfen, dass dadurch die komplette Board-Performance dermaßen die Bäche runtergeht. Wenn ich mir z.B. die sagenhaften 17.000 Beiträge im Arbeitszeit-Chat-Thread anschaue, die dort innerhalb von knapp 5 Monaten er-spammt wurden (und lese, dass im Nachfolge-Thread schon die ersten "den hamma eh boid wieder genauso weit aufblos'n"-Wuchteln abgelassen wurden), wundert mich manches nicht mehr so....

Oder anders gesagt: auch die performanteste DB hält nicht ewig der Langeweile-Bewältigungstherapie mancher Leute bzw. deren Spam-Threads im fünfstelligen Beitragszahlen-Bereich stand.

[Vicious]

welche wären das? würd mich interessieren.

bulk insert buffer size

join buffer size

key buffer size

myisam sort buffer size

net buffer length

read buffer size

read rnd buffer size

sort buffer size

frag mich jetzt nicht für alle diese buffer, welche werte und bedeutungen ideal sind, bin grad mal am herausfinden. leider gibts zu diesem thema ganze bücher und keine crash-kurse

bearbeitet 19. April 2005 von Vicious

[axeman]

am verdächtigsten scheinen mir zu sein:

myisam sort buffer size

sort buffer size

wobei ich natürlich nicht weiss, inwiefern sich die beiden unterscheiden. aber gerade bei den grossen threads könnte ich mir vorstellen, dass vielleicht etwas zuviel auf der platte sortiert wird.

read buffer size

könnte in etwa dem vorhin erwähnten buffer cache entsprechen.

[Vicious]

am verdächtigsten scheinen mir zu sein:

myisam sort buffer size

sort buffer size

wobei ich natürlich nicht weiss, inwiefern sich die beiden unterscheiden. aber gerade bei den grossen threads könnte ich mir vorstellen, dass vielleicht etwas zuviel auf der platte sortiert wird.

könnte in etwa dem vorhin erwähnten buffer cache entsprechen.

fürs erste hat mal das ändern der Transaktion isolation auf read-uncomitted einiges bewirkt, denn unter mysql werden bei myisam defaultmässig alle selects mit select for update interpretiert und als folge dessen der ganze table gelockt (da lob ich mir oracle)

durch das ändern der trx-isolation sollten selbst wenn lang andauernde queries ausgeführt werden, zumindest die anderen nicht warten. damit dürfte ja schon der schwerpunkt der unzufriedenheit erschlagen sein.

bitte wieder um info, wenn dies nicht so ist.

ein punkt der trotzdem ewig dauert ist die freitextsuche über alle foren (aber da geht sogar oracle langsam in die knie )

lg vicious

PS: die buffer werde ich trotzdem noch weiter auf optimierung trimmen

[Dannyo]

@Vicious: Hauptsache kein optimize oder repair bei den ibf_sessions

[avvocato]

[ Script Execution time: 19.5092 ] [ 10 queries used ] [ GZIP aktiviert ]

jetzt

rubrik Sonstiges

[marek]

also grad vor kurzem war's bei mir wieder komplett aus.

ist es eigentlich sicher, dass es am asb oder am mysql liegt? vielleicht läuft ja irgendwas anderes am server, das ihn runterziehen könnte???

[Vicious]

also grad vor kurzem war's bei mir wieder komplett aus.

ist es eigentlich sicher, dass es am asb oder am mysql liegt? vielleicht läuft ja irgendwas anderes am server, das ihn runterziehen könnte???

Da reicht mein Linux wissen leider nicht um das zu beurteilen, aber es kann sein, dass ergendein prozess wichtige resourcen nimmt, bist du zufällig in diesem gebiet experte?

forza "alleteschnischgutenuser" machen eine expedition zum asb-server

bearbeitet 20. April 2005 von Vicious

[marek]

also grad vor kurzem war's bei mir wieder komplett aus.

ist es eigentlich sicher, dass es am asb oder am mysql liegt? vielleicht läuft ja irgendwas anderes am server, das ihn runterziehen könnte???

Da reicht mein Linux wissen leider nicht um das zu beurteilen, aber es kann sein, dass ergendein prozess wichtige resourcen nimmt, bist du zufällig in diesem gebiet experte?

forza "alleteschnischgutenuser" machen eine expedition zum asb-server

nein in diesem gebiet bin ich totalversager. bin mehr im windows bereich daheim. aber bei der expedition bin ich trotzdem dabei.

bearbeitet 20. April 2005 von m@x