leere Bretter. Wird aber jetzt mal Zeit, daß Nickles die Manpower bereitstellt, um das dauerhaft abzustellen.
Wenn Computer-Bretter dauernd Computer-Schwierigkeiten haben, ist das nicht ohne Ironie.
Man könnte aber auch sarkastische Gedaken über die Kompetenz haben...
cu hp.
B@p
hiddenpeak
„Schon wieder.......“
Hallo hp,
ich denke(nein ich weiß) tw nervt das noch mehr als uns. Das Problem wird bald aus der Welt sein. Da bin ich mir sicher.
cu Schorsch
hiddenpeak
B@p
„Hallo hp, ich denke nein ich weiß tw nervt das noch mehr als uns. Das Problem...“
Anonym
hiddenpeak
„ Hallo B@p, glaub ich sofort - nur, die Probleme gehen nun schon seit Monaten....“
Das Problem ist technischer Natur. Wahrscheinlich kann TW fast garnix dagegen machen. Ein Wahnsinnssystem schafft 7.061.000 Steps/h. Das sind 117683 Anfragen die Minute und 1961 in der Sekunde. Ich galube allerdings nicht, dass TW folgende Hardwareausstattungen hat:
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/data/ps-06.07.00-000/default.shtml&words=Datenbank%20Benchmark
http://www.ideasinternational.com/benchmark/sap/sap3sdR4.html
Ausserdem arbeitet er mit MySQL, welches nischt kostet und auch etwas langsamer ist.
Jetzt sieht das ganze so aus: Wenn einer auf einen Datensatz zugreift, wird dieser gesperrt. Je nach Transaktions-Protokoll werden alle dranhängenden gesperrt und nach und nach freigegeben, sobald es unwahrscheinlich wird, dass diese durch den Nutzer beeinflusst werden.
Wer also jetzt Zugriff auf einen Datensatz haben will, muss sich "hinten anstellen". Um das ganze möglichst fix machen zu können, gibt es einen sog. Schedule. Hier werden die einzelnen Logs (vereinfacht: Anfragen) so zusammengestellt, dass sie sich nicht in die Quere kommen.
Warum dieser Aufwand?
Szenario: Zwei Logs. Jedes will denselben Datensatz lesen und Schreiben.
(r=read, w=write)
Zeit->
Log1: r1,,,w1
Log2: ,,r1,,,w1
Wie zu erkennen, schreibt Log2 "veraltete" Daten zurück. Das darf nicht passieren. Also muss log2 warten, bis Log1 fertig ist.
Dabei besteht die Gefahr von Deadlocks. Ein Log wird in der Abarbeitung "vergessen" und der Nutzer wartet sich einen Wolf. Deshalb gibt es TimeOuts. Wird der TimeOut erreicht, gibt der Client eine Fehlermeldung aus, oder zeigt die Daten halt schlicht nicht an.
Um die Anzahl dieser TimeOuts zu minimieren, wird halt ein Transaktionsverfahren eingeführt, wie oben beschrieben.
Je nachdem, wie gut oder wie schlecht das ein DBMS (Datenbankmanagement-System) das hinkriegt, so schnell ist dann die Datenbank. Herr Wölfers Datenbank wird sicher nicht ansatzweise oben genannte Benchmarks erreichen.
Hinzu kommt, so denk ich mir mal, dass er die Sache mit den Deadlocks noch nicht im Griff hat.
DoS-Attacken (und die kann jeder Depp mitlerweile machen) und weitere Hack-Versuche sind natürlich auch eine Bremse. Ich bin mir sicher, dass Nickles sehr häufig angegriffen wird. Manchmal merkt man das erst, wenn der Rechner brüllend am Ende der Belastungsgrenze steht. Wenn es einer schafft den Schedule vollzusauen, dann ist bei Nickles.de Ruhe. Dann kanst Du warten bis Du schwarz wirst.
Hab ich das ungefär richtig gesagt, Herr Wölfer?
PCO
thomas woelfer
Anonym
„Das Problem ist technischer Natur. Wahrscheinlich kann TW fast garnix dagegen...“
das kommt recht genau hin. erschwerend kommt hinzu das der bzw. die betroffenen rechner in den usa stehen - das macht die fehlersuche noch ein bisschen schwieriger.
die sache mit der ueberlast versuchen wir dadurch zu loesen, das wir mehr rechenleistung zur verfuegung stellen - mitlerweilse laueft nickles.de auf 3 rechner (ab naechster woche auf 4) : das sollte zumindes die normale ueberlast beseitigen. natuerlich nicht auf dauer - dazu steigen die abrufzahlen einfach zu stark, aber doch wieder fuer einige monate. (davon unabhaengig sind die dos angriffe und sonstige angriffe denen nickles.de praktisch dauernd unterliegt.)
was die sache mit den brettern angeht (bretter leer, archisuche geht nicht): dieses problem besteht keineswegs seit monaten wie der ursprüngliche poster angemerkt hat, sondern ziemlich genau seit 6 tagen.
es ist noch nicht klar ob das problem aus einem hardware problem resultiert (unwahrscheinlich, da zwei rechner gelcihzeitig betroffen, ob es schlicht daraus resultiert das mysql mit der grosse der datenbank nicht klarkommt (das werden wir aber vermutlich uebers wochenende herausfinden) oder obs einfach an der aktuellen mysql version liegt, auf die wir am tage der verfuegbarkeit der 'stable' version upgedated haben.
das ganze ist halt auch ein wenig problematisch anzugehen: zum einen versuchen wir den betrieb aufrechtzuerhalten waerend wir das problem suchen - zum anderen sollen natuerlich auch waehrend dieses aufrechterhaltens moeglichst keine postings verlorengehen.
wir man (vielleicht einige leute auch nicht) sich leicht vorstellen kann, ist das per ssh fernwartung von einem rechner der nur ueber ip erreichbar ist, und auf dem jede sekunde einige tausend requests behandelt werden nicht ganz einfach - und dementsprechend gehts auch nicht ganz schnell.
bin allerdings gerne bereit von jedermann der helfen kann oder will ratschlaege anzunehmen: bitte per mail.
WM_THX
thomas woelfer
B@p
hiddenpeak
„ Hallo B@p, glaub ich sofort - nur, die Probleme gehen nun schon seit Monaten....“
Hallo hp,
aus Fehlern sollte man eigentlich lernen. TW wird schon seine Schlüsse daraus ziehen. Ist vielleicht auch eine finanzielle Frage, bzw. nur mit erheblichen Zeitaufwand zu bewerkstelligen.
cu Schorsch
(Anonym)
hiddenpeak
„Schon wieder.......“
diese nickelstrottel haben doch keine ahnung
