Ist das Forum langsamer geworden?

[Zwerg]

Ihr Jungspunde!

Ich habe auf einem Commodore VC 20 angefangen und mich hochgearbeitet! (zur Zeit arbeite ich mit dem Abgelegten von Sohn Nr. 2 - The times they are a changing!)

Liebe Grüße
Zwerg

[Pscipio]

Mein erster war immerhin schon ein Pentium 75 MHz mit 8 MB Ram und 1 GB Festplatte. Das war 1995. Oh mein Gott, bin ich schon alt!!

[Wurzel]

Ich hatte nen XT mit einer 20 MB Festplatte, und 2! Diskettenlaufwerken einmal 3,5 Zoll und einmal 5 1/4 Zoll. Das ganze mit einem Monochrome Monitor in Bernstein.
Und in der Schule habe ich "Computern" auf einem Commodore C128 gelernt, später in der Berufsschule saßen wir vor einem der ersten Apple Homecomputer.

Die Rechenleistung haben in etwa heutige Taschenrechner.

Micha

[antoninus1]

Ha, das ist ja gar nichts!

Ich habe im ersten Semester an der Uni im Fach Informatik noch mit Lochkarten programmiert
An die Rechner mit Tastatur konnten wir erst im zweiten Semester ran.
Das war 1948, äh nein, 1984.

[petzlaff]

@antoninus1

Der erste Großrechner auf dem ich 1976 nach Abschluß meines Studiums beruflich tätig war, war ein Univac (gibt es heute nicht mehr) 494 mit 2 x 32MB Hauptspeicher und 2 mal 2GB Trommelspeicher (im Format einer Litfassäule), sowie Lochstreifenprogrammierung.

Die Trommeln wurden nach Einführung von Wechselplatten (Festplatten gab es damals noch nicht) dem hiesigen Fussballverein als Rasenwalzen gespendet. Es dauerte nach einem Stromausfall übrigens 3 Stunden Anlaufzeit, bis die Trommelspeicher wieder reibungslos rotierten und betriebsbereit waren.

Nahezu identisch wurde das gleiche Equipment von der NASA für die Unterstützung der bemannten Mondlandungen eingesetzt (das ist kein Witz, sondern Fakt). Der Unterschied: die NASA nutzte keine Univac 494, sondern eine Univac 490 mit 1 x 32MB Hauptspeicher. Die damalige Programmiersprache hieß SPURT (Sperry Univac Realtime) und war eine 8bit Assemblersprache. Von den 8 bit der Befehlsworte waren oft nur 5 signifikant belegt, so dass wir die restlichen 3 leeren bits als zusätzlichen Speicherplatz für temporäre Zwischeninformationen nutzen konnten.

Wie sich die Zeiten ändern! - Erstaunlicherweise gab es damals weitaus weniger Probleme.

[klosterschueler]

Hallo Petzlaff!

Genauso einen Trommelspeicher haben sie im Rechenzentrum der TU Graz verwendet. Damit das Ding vom 2.OG nicht bis in's Erdgeschoß durchgerasselt, wurde sogar der Boden verstärkt.

Und wie ich vor 10 Jahren in die Firma gekommen bin, hatten wir gerade einen Server mit einer 5er-Raid angeschafft, der es auf 1 GB gebracht hat. Haben ihn ehrfürchtig CRAY genannt....

Klosterschüler

[petzlaff]

@Klosterschüler

das ist mir wohl bekannt, dass solche Teile in Graz standen. Schließlich kamen unsere externen Berater damals aus Graz, um in Hameln ihr "Unwesen" zu treiben.

Nicht nur in Graz standen derzeit solche Geräte. Die wichtigsten Referenzkunden waren "die Grazer", "die Essener" - eine der grössten Kaufhausketten, "die NASA", das größte deutsche Luftfahrtunternehmen in Frankfurt, eine bekannte Krankenkasse in Norddeutschland und das weltweit größte zentrale Luftfahrt-Buchungsunternehmen in Erding. Ach ja, hätte ich beinahe vergessen - dann gab es auch noch das grösste schweizer Bankinstitut in Zürich, sowie die immer noch grösste französische Privatbank, die ihren Namen von einer Stadt an der Rhone ableitet.

[Münz-Goofy]

Erstaunlicherweise gab es damals weitaus weniger Probleme.

Probleme gab's damals sicherlich genug. Nur sind wir heute wohl viel anspruchsvoller an die Technik geworden.

Gruß
MG [ externes Bild ]

[Chippi]

Das Fatale an der "guten alten Zeit", man erinnert sich nur an die guten Dinge...

Gruß Chippi

[Zwerg]

Hat jetzt wieder 5 Minuten gedauert, bis ich diese Antwort schreiben konnte. Normalerweise gibt es diese Verzögerungen erst viel später.
Frage: kennt jemand den Grund - und wenn man hier durch finanzielle Zuwendungen helfen könnte, wäre dies sicherlich möglich.

Liebe Grüße
Zwerg

[Locnar]

Hallo Zwerg, wir kennen den Grund auch nicht, die Vermutung lag bei den Suchmaschinenbots!

[klosterschueler]

Hallo Locnar!

Hmmmmm, das müsstet man aber sehen, wenn zu einer bestimmten Zeit von einer bestimmten Adresse sehr viele Zugriffe sind, oder? Wir machen sowas in der Firma beruflich und wenn der Admin order die Netzwerker nich sagen können, wo die Requests herkommen kann ich ganz schön vorwurfsvoll schauen

Klosterschüler

[petzlaff]

was steckt denn eigentlich für eine hardware dahinter?

Server und Betriebssystem?
Platten und Dateisystem?
Anschlussart der Platten an den Server?

[Locnar]

Moin.

der Server liegt bei domaindiscount24

Server: Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16 mod_ssl/2.0.54 OpenSSL/0.9.7e

Was mich wundert das die Pingraten eigentlich Klasse sind.

5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 2.295/2.511/2.672/0.154 ms

[petzlaff]

@Locnar

ich vermute, dass die Platten hintendran als Netzwerk-Appliance mit iSCSI über IP angeschlossen sind und vermutlich über ein CIFS-Filesystem verfügen.

CIFS ist nicht wie viele anderen Filesysteme zu einer Selbstreorganisation fähig - bedeutet: gelöschte Blöcke auf der Platte werden nicht wieder benutzt indem sie mit neuen Daten beschrieben werden. Hier kann nur eine vollständige Plattenreorg helfen, die extrem zeit- und ressourcenaufwendig ist, und soweit ich weiss, nicht autark von der Platte selbst, sondern über die entsprechenden CIFS-Treiber auf dem Server bewerkstelligt werden muss.

iSCSI und CIFS wird sehr häufig wegen der preisgünstigen Implementierung unter Nutzung eines vorhandenen LANs eingesetzt, ist aber für grosse Realtime- (Online-) Anwendungen mit hohem Schreib- oder Änderungsaufkommen (wie z.B. bei PHP-Applikationen) nicht zu empfehlen. Normalerweise ist diese Nutzung nur sinnvoll, falls auf die gespeicherten Daten zu mehr als 90 Prozent Read-Only zugegriffen wird.

Weiterhin kennt Linux keine Lastverteilung auf eventuell vorhandenen mehrfachen Verbindungen zwischen Server und Plattenspeicher. Diese Funktionalität bietet nur ein einziger Hersteller im Markt vermittels spezieller Treiber, den ich aber aus deinen Angaben nicht herauslesen kann.

Ergo - Das ganze Szenario könnte so aussehen (ohne Gewähr): die nächtlichen Hänger sind durch die erforderlichen Platten-Reorganisationen bedingt (wie bereits vermutet). Der komplette Ausfall aufgrund einer Überlastung mit Timeouts der Verbindung zwischen Server und Platten während einer offenbar ungeplanten Reorg nach einem internen Ausfall oder einer Erneuerung der Plattenlandschaft. Ich habe mit verschiedenen Browsern herumprobiert - zwei haben mir ganz klar gesagt, dass der Server zwar erreichbar wäre, aber die Datenübertragung wegen Timeouts nicht zustande käme.

Eine Überlastung durch Suchmaschinen-bots kann ich mir eigentlich nicht vorstellen, die normalerweise nur auf den Server-Cache und nicht auf die Platten selbst gehen.