Antworten auf deine Fragen:
Neues Thema erstellen

Antworten zum Thema „1,4 Mio Datensätze, 2 Tables, First in - First out, hohe Las“

P

poky

Guest

Servus!

Da ich irgendwie nicht mehr wirklich weiter weiß bzw. mir keine schöne Lösung einfällt, frag ich nun mal hier.


Also ich hab 2 Tabellen [MySQL]:

- gb_cache : 345.000 Datensätze [62 MB]
- gb : 1,08 Mio. Datensätze [190 MB]

Beide Tabellen identisch, d.h. selben Index, selbe Spalten etc.


In jeder Tabelle stehen Gästebucheinträge von Community-Usern, d.h. in

- gb_cache : max. 60 Einträge pro Benutzer
- gb: der Rest, aber max. 340 (wird jede Nacht aufgeräumt)


Bei jeden Eintrag in gb_cache wird überprüft ob mehr als 60 Einträge drin sind, wenn ja dann nach gb verschoben und in gb_cache gelöscht (First in ? First out). Und genau hier vermute ich das Problem.

Greifen 250 User gleichzeitig zu kein Problem. Aber werden es dann 300 und mehr fängt die Kiste an zu swappen = alles wird langsam. Meine Vermutung für das RAM zu müllen ist das updaten der Indexe der Tabellen.


-> Also meine Variante ist nicht grade performant und mir fehlt einfach die Idee das ganze anders umzusetzen.

Irgendwelche Vorschläge, Anregungen und Ideen? Mir fällt wie gesagt nichts Gescheites ein.



Noch was zum Server:
- Opteron 146 - 2 GHz
- 1 GB RAM

Zwar auch nicht grade der schnellste, aber ich denke der sollte normal die 300-350 Zugriffe ohne Probleme schaffen. Wäre da nicht das oben beschrieben Problem.


Gruß
 

saila

Moderatorle

Also am Server liegt nichts. 300 Zugriffe ist nichts.

Vielmehr denke ich, das deine Tabelle etwas umständlich und nicht auf performancegerechte Verarbeitung aufgebaut ist.

Ein weiterer Knackpunkt ist deine Tabelle und die Auslagerung in eine andere Tabelle. Wenn nun gerade die neuen 200 User online sind und genau jetzt 60 MB erreicht werden, fängt dein Script an zu arbeiten und lagert 60 MB aus. Das ist ganz sicher eine deutliche Verschlechterung.

Deine Hilfe wäre
a) Crone-Job erweitern.
b) Deine DB-Tabelle-Struktur überarbeiten und auf Performance ausrichten.
c) Überlege, wie du bei einem Ausfall dein Backup installieren willst bei einer Größe von 200 MB?! Manuel ist das eine unmenge an Arbeit.
d) ein Gästebucharchiv anlegen. Einträge älter als.... in das Archiv schieben.
e) das Archiv aufteilen in mehrere Tabellen oder alternativ zip einsetzen.

Was mich stutzig macht ist bei einem Gästebuch, dass User bis zu 60 Einträge absetzen können. Das wäre ja eher für ein Forum gedacht als für ein Gästebuch.

Kannst du die Struktur der Tabelle zeigen?
 
P

poky

Guest

Flotte Antwort, also evtl. sollt ich noch mal bisschen mehr beschreiben:

Dreht sich hier um ne Communityseite mit Forum, Benutzerprofilen und eben den Gästebüchern für jedes Profil.


Verteilt auf 2 Tabellen ist das ganze weil es eben durch das nette LIMIT einfach Lahm wird bei 1 Mio. Datensätzen.

Das Gästebucharchiv ist ja quasi die "gb" Tabelle, da kommt alles rein was älter als die neusten 60 Einträge ist. Das heißt jeder Nutzer hat in seinem Profil 3 Seiten (60 Einträge) aus der gb_cache und 17 Seiten (340 Einträge) aus der gb Tabelle. Letztere wird mehr selten aufgerufen aber dennoch benutzt.

DB-Struktur:


Index:
nach
gbid


Abfrage eben: SELECT ... FROM usergb_cache WHERE nach=USERID ORDER BY gbid LIMIT


QueryCache ist an (wie groß weiß ich nicht - Server administration übernimmt ein anderer aus unserem Team; PHP-Beschleuniger läuft auch)

Warum macht dich das stutzig? In jedem Gästebuch sind eben für den jeweiligen User Einträge von anderen drin.




Zur Zeit sind 256 Leute online und alles ist normal schnell. Bei 310 oder so gehts dann in die Knie.


Was mir grade noch in den Sinn kommt:
Die Funktion lässt sich explizit aktivieren. ALTER TABLE ... DISABLE KEYS weist MySQL an, die Aktualisierung nichteindeutiger Indizes für eine MyISAM-Tabelle zu beenden. Danach sollte ALTER TABLE ... ENABLE KEYS verwendet werden, um die fehlenden Indizes neu zu erstellen. MySQL tut dies mit einem speziellen Algorithmus, der wesentlich schneller ist als das aufeinander folgende Einfügen von Schlüsseln. Insofern sollte die Deaktivierung von Schlüsseln vor umfangreichen Einfügeoperationen diese erheblich beschleunigen. Die Verwendung von ALTER TABLE ... DISABLE KEYS erfordert neben den bereits genannten Berechtigungen auch die Berechtigung INDEX.

D.h. wenn ich VOR dem First in First Out für beide Tables "ALTER TABLE ... DISABLE KEYS" mach und danach "ALTER TABLE ... ENABLE KEYS" sollte das performanter sein, oder bin ich doof? =)
 

saila

Moderatorle

Schon mal ohne PHP-Beschleuniger versucht bzw. schon mal versucht, den Beschleuniger dann einzusetzen, wenn xxx User online sind?

Test's durchgeführt, wenn weniger als 310 User online sind und mehr als 310 bzgl. PHP?
Sprich - der Beschleuniger kann auch manchmal dazu führen, das alles zusammen fällt.
Evtl. mal völlig raus lassen.

Die Tabelle ist fast ok. Man könnte den Namen noch auf int umstellen. Aber hier ist das Problem nicht vorhanden bzw. zu finden.


Ist es eine fertige Forensoftware oder eine eigen erstellte?


Bzgl. Benutzerbeiträge - ich ging davon aus, dass es sich um ein normales GB handelt. Nicht um ein GB für jeden User innerhalb eines Forum.
 
P

poky

Guest

Also ohne Beschleuniger geht die last auch ziemlich schnell hoch bei vielen Zugriffen. Der hat schon ziemlich die Last gesenkt sei der aktiv ist. Scripte haben im Schnitt ne Laufzeit von 0,04 - 0,10 Sekunden, also für mich ziemlich im Rahmen.

Was ich evtl. noch erwähnen sollte: Ich schick die Seiten komprimiert zum User, das zieht natürlich auch ein wenig Last, daran ist aber nichts zu ändern da viele ISDN User dabei sind (= Nutzer aus ländlicher Gegend).



Die Scripte / Datenbankstrutkur ist alles selbst geschrieben, also keine fertigen Scripte außer der Adserver (phpAdsNew).


Ich vermute allerdings immer noch dass es mit den Tabellen und dem Index zu tun hat. Gestern hab ich der ip-log Table (2 Mio Einträge, 1 Eintrag bei jedem Login) nämlich den Index genommen und die Performance gewaltig gesteigert. Statt 220 konnte der Server aufeinmal 300 User mehr oder weniger ohne Probleme verkraften. Sind diese aber dann alle recht aktiv wirds eben langsam.


Und ich vermute da eben das Problem beim Index der GB Tabelle beim "frist in First out".


Wenn dann nämlich 100 Leute gleichzeitig n Eintrag irgendwo machen dann Updatet MySQL ja den Index der Tabelle = Gau bei 1 Mio. Datensätzen.

Denk ich mir zumindest so, vllt liegt ich ja auch grade falsch? =)
 

saila

Moderatorle

Auf welche DB-Tabellen-Spalten hast du einen Index gesetzt?

Verlangsamen kann das ganze auch der Scipt-Code. Im speziellen die Query's. Du arbeitest sicher mit Joins.

Zeit mal ein Query, welcher auf zwei oder drei Tabellen zugreift. Entweder hier oder per PM. Kannst auch mit der DB-Sturktur und Indizierung so handeln.

Normalerweise darf bei 300 User kein Problem entstehen. Bei 1 Mio aufwärts ok. Aber nicht bei dieser geringen Anzahl.

Ist die DB auf dem gleichen Server?
 
P

poky

Guest

Jupp DB und Webserver laufen beides auf der gleichen Kiste, da ist uns schon bewusst dass der irgendwann an die Grenzen stößt...

Joins nutz ich keine, hab ich extra drauf verzichtet indem ich in der spalte "nickname" den Nickname des Eintragerstellersspeicher.


Query ist nichs wildes, ganz normales SELECT eben:

SELECT gbid,von,nickname,zeit,eintrag,auth FROM gb_cache WHERE nach=USERID ORDER BY zeit DESC LIMIT X,20;

Wär ja kein Ding die ganzen Daten alle in eine Tabelle zu packen aber da wirds eben durch das LIMIT langsam...


Index:



Ich vermute mal mit ein wenig mehr RAM würd die Kiste deutlich mehr aushalten aber Upgrades gibts bei Strato leider nicht...
 

saila

Moderatorle

Ach du bist bei Strato............... Ok dann weis ich jetzt auch, warum das alles so langsam ist :lol:

Strato hat grundsätzlich Geschwindigkeitsprobleme - warum auch immer. Aber ich kenne Andere die ebenfalls bei Strato sind und selbst bei DSL 18000 läuft es langsamer als üblich.

Unabhängig davon.....
Dein Code würd mich interessieren ohne Joins bei Forensoftware. Das ist unüblich, da Joins wesentlich beschleunigen. Zur DB und Indexe - setze diese immer bei int's, dann wird das gaze auch schneller. Auf keinen Fall Indexe vorenthalten bei dieser Größenordnung.

Zudem solltest du die Pufferung für Indexe nach oben setzen. 30% des verfügbaren MB sollten es immer mind. sein. "key_buffer_size" ist das Stichwort.
 
P

poky

Guest

Indexe sind beide auf spalten deren Typ int ist.

Und wie schon gesagt, bei der Query:
SELECT gbid,von,nickname,zeit,eintrag,auth FROM gb_cache WHERE nach=USERID ORDER BY zeit DESC LIMIT X,20;

Brauch ich keinen JOIN da ich alle Daten die ich brauch in der selben Tabelle hab...


Soweit es geht hab ich einfach auf JOINs verzichtet.. Würde ich die Nickname Spalte kicken und den Nickname via JOIN aus der User Table holen könnt ich mir evlt. paar MB Daten in der Datenbank sparen aber ich kann mir nicht vorstellen dass es für die Serverlast von Vorteil ist..


GRad mal grob überschlagen:

Am Tag allein die Gästebucheinträge sind 25.000 Inserts die die User verursachen...
 

saila

Moderatorle

Hast du das mit der Pufferung gelesen?! Sehr wichtig!

Die Joins beziehen sich auf die Gesamtnutzung. Sprich zum auslesen in allen Anwendungen. Aber versuch mal das Thema der Pufferung zu klären und check mal, wieviel Speicher dafür aktuell eingestellt ist. Das könnte alleine schon helfen.
 
P

poky

Guest

Keybuffer_size is aktuell in der Config laut unserem Server Admin auf 128 MB eingestellt, ist aber finde ich ein wenig hoch.


Key_blocks_unused 102918
Key_blocks_used 62550
Key_read_requests 119864761
Key_reads 556805
Key_write_requests 8893939
Key_writes 773869


Alle Indexe der Tabellen zusammen sind etwa 85 MB groß (überall aufgerundet..).


Achso der Server stellt auch noch ziemlich viele Eventsfotos und Usergalerien zur verfügung.. Beides etwa jeweils 5 GB die auch unterschiedlich oft n den User gehn, aber sollte sich in Grenzen halten.


In irgendnem Weblog hab ich gelesen durch nen Reserve-Proxy auf dem selben Server könnte man die Last enorm drücken, Erfahrungen damit? =)
 

saila

Moderatorle

Wie groß ist der Gesamtspeicher und davon 30% ist der Puffer-MB-Speicher.
Bei einem GB also 1000 MB ergo 300 MB Puffer. Das ist aktuell wohl eher zu wenig.

Ansonsten - wenn das auch nicht hilft, würde ich auf jedenfall die DB extern lagern. Ist immer besser - meiner Meinung nach - und steigert auch die Performance, da die Scriptverarbeitung und die Zugriffe nur auf den Server laufen und von da aus wiederum die DB-Angesprochen wird.

Größere Unternehmen machen das standardmässig. Bei der Zugriffszahl würd ich das dirket umsetzen, da davon auszusgehen ist, das sich die Zugriffszahl wohl eher erhöht als verringert.

Reserve-Proxy setzt Strato schon ein, da es vor dem Webserver steht.

Aber Server-Einstellungen und Verwaltung von DB's grundsätzlich ist eh schon ein Kapitale für sich.
 
P

poky

Guest

Datenbank ingesamt is 1,2 GB Groß. Kommt noch Mailsystemarchiv dabei was 600 MB hat, was auch demnächst wohl noch beschränkt. dann mal sehn..


Zur Zeit 271 eingeloggte User und es rennt richtig.. Ebene warns weniger und da isser wieder rumgekrochen.


Mal weiter beobachten. Sicherlich könnt ich die Gästebücher noch weiter beschränken, auf zum Beispiel 200 Einträge oder sowas, aber dann geht das geschrei wieder los. Andererseits steht da eh nur Müll drin :)



Naja irgendwann muss sowieso dann n zweiter Server her, einer für die Datenbank, einer für den Indianer.. Anders gehts irgendwann halt nicht mehr... Mal mit der "Finanzabteilung" reden :D
 

saila

Moderatorle

Irgendwann ist gut.
1.2 GB davon
600 MB für Mail und
300 MB für DB und
50 MB Daten / Dateien
Auslagerungsdatei ?
1.2 GB und dann knickt er eben ein, wenn ein Haufen Daten gezogen werden. Sprich - euer Server reicht in der Gesamtkapazität nicht mehr aus. :D
 
P

poky

Guest

Mails laufen ja auch über die Datenbank, is der gleiche aufbau mit normalem posteingang und archiv...

Private Nachrichten: 989.057
Gästebucheinträge: 1.382.403



Von den Nachrichten wird wohl alles gekickt was älter als 1.3.2006 ist, das sind dann auch schon mal wieder 540.000 Datensätze weniger, dh die Table dürfte halb so groß sein. Un dide Gästebücher werden auch noch weiter beschränkt... Anders seh ich da keinen Sinn.


Hab mal mit vergleichbar großen bzw. größeren Party-Communities verglichen. Die haben bei den Profilgästebüchern im Schnitt 400.000 und bei den Mails vllt. 300.000 .. Also bei uns sind die Leute aufjedenfall zu aktiv..
 
P

poky

Guest

saila schrieb:
Naja, oder ihr seit technisch nicht ausreichend ausgerüstet.

Naja... "Nachbarcommunity" ausm WW ham nen "Dumping Hosting" bei NGZ Server..Dual Opteron mit 4 GB RAM oder so... Aber da ist dann letztens bei dem großen Stromausfall die Kiste abgeschmiert, Backups kaputt.. Keine USV und sowas eben...


Der neue Server läuft erst seit 14.08...Geld fürn zweiten is da aber warum Geld ausgeben wenns auch noch ne Zeitlang anders laufen könnte =) Naja mal sehn.
 

saila

Moderatorle

Wohl dem/der, welche/r sich mit Crone-Jobs auskennt und entsprechende Backups einrichtet.

Ist das Thema für dich geklärt, dann kann der Thread geschlossen werden.
 
Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Antworten auf deine Fragen:
Neues Thema erstellen

Willkommen auf PSD-Tutorials.de

In unseren Foren vernetzt du dich mit anderen Personen, um dich rund um die Themen Fotografie, Grafik, Gestaltung, Bildbearbeitung und 3D auszutauschen. Außerdem schalten wir für dich regelmäßig kostenlose Inhalte frei. Liebe Grüße senden dir die PSD-Gründer Stefan und Matthias Petri aus Waren an der Müritz. Hier erfährst du mehr über uns.

Stefan und Matthias Petri von PSD-Tutorials.de

Nächster neuer Gratisinhalt

03
Stunden
:
:
25
Minuten
:
:
19
Sekunden

Flatrate für Tutorials, Assets, Vorlagen

Zurzeit aktive Besucher

Statistik des Forums

Themen
175.156
Beiträge
2.581.859
Mitglieder
67.222
Neuestes Mitglied
Gregor
Oben