Optimale Konfiguration mySQL bei vielen Parallelen Threats
Torsten
- datenbank
0 webmonk0 Jan Lehnardt
Hallo,
ich hab da mal ein Problem, zu dem ich Ressourcen (Bücher, Webseiten oder Expertenmeinungen) suche:
Ich betreibe ein php mySQL basiertes Chatsystem, für jeden User
wird eine neue Datenbankinstanz der zentralen chat sql Klasse
aufgemacht. Nun ist in diesem chat zeitweise ziemlich viel los
und da leigt das Problem (zumindest wird es bald da liegen)
Die vielen Parallelen Threats schreiben und lesen meist munter auf
nur einer Datenbanktabelle rum (weil sich die meisten leute im Chat halt immer in der Lounge aufhalten) Bei parallenen Zugriffen kommt daher hin und wieder ein duplicate entry fehler vor, wenn zufällig zwei mit derselben id (auto increment) was schreiben wollen, bei viel
verkehr (70 Leute im Chat) im Moment so alle viertelstunde.
Wie läst sich das (wenn überhaupt) verhindern oder entschärfen. Ich weiß daß es für andere Datenbankserver sog. tranaktionserver gibt, die sowas regeln (ohne jedoch bisher genau zu wissen, wie das funktioniert) gibt es sowas für die mySQL?
Zweitens: Jeder Datenbankprozeß verbraucht im Moment 21 Megabyte
Arbeitsspeicher (bei 512 MB Systemspeicher bin ich hier bisweilen
schon am limit) Kenn sich jemand mit der optimalen Konfiguration
der mySql für viele parallele Verbindungen aus? Hinzu kommen ja noch die Httpd Threats und auch die verbrauchen meiner Meinung nach zuviel
Arbeitsspeicher, weiß jemand hierüber bescheid (muß wirklich jeder Webuser seinen eigenen httpd Prozeß belegen?)
danke euch für jeden Hinweis
gruß
Torsten
Hi!
Die vielen Parallelen Threats schreiben und lesen meist munter auf
nur einer Datenbanktabelle rum (weil sich die meisten leute im Chat halt immer in der Lounge aufhalten) Bei parallenen Zugriffen kommt daher hin und wieder ein duplicate entry fehler vor, wenn zufällig zwei mit derselben id (auto increment) was schreiben wollen, bei viel
verkehr (70 Leute im Chat) im Moment so alle viertelstunde.
mySQL unterstützt derzeit sogenannte "Transaktionen", wie sie bei größeren DB System wie ORacle, DB2, usw usus sind noch nicht. Meiner Meinung nach ist das auch nicht ganz so wichtig, ausgenommen du möchest ein Programm für Banken, Versicherungen usw. mit sensiblen Daten etwickeln.
Hab zwar selber ncoh kein Chat System geschrieben, würde das ganze aber etwas anders angehen:
Ein Tabelle raum_lounge erstellen, welche nur die Chatter-ID beinhaltet, die sich gerade im Raum befinden, und für jeden User eine eigene Tabelle anlegen ala chatter_IDXXXX mit deinen gewünschten Informationen und einer Spalte (Chat_room) Dadurch kann es nie zu parallelen Schreibzugriffen kommen (--> kein Fehler)
Eine Abfrage über das was gerade im Chat passiert mußt du aus der room table alle anwesenden User auslesen und dann deren Tabelle anzeigen (geordnet nach Zeit, denn ansonsten gibts ein Chaos) weiters sollten dann die chatter_IDXXXX Tabellen nach einem Logout gelöscht werden. (Damit die DB nicht irgendwann explodiert ;-) )
mfg webmonk
Hi,
Du benutzt Komponenten fuer ein System fuer das sie nicht geschaffen sind. Du willst <www.titanchat.de> o.ae. einsetzen. Konkurierende zugriffe koenntest du mit shared memory segmenten und semaphoren serialisieren, aber wie gesagt, eine DB ist nix fuer einen Chat.
Jan
--