Hm, es ist glaube ich egal wo man hingeht. Es wird immer jemand sagen die sind gut, andere sagen die sind schlecht.
Das ist auch so.
Server4You ist soweit sehr gut und ich hatte mit dem Support keine negativen Erfahrungen gemacht. Bisher zumindest.
Wenn der Rechner komplett wegfliegt, sollte man auf einen Wechsel einen neuen Server bestehen. Das machen die dann meist auch kostenlos, bzw. kostengünstig, wenn der Server wirklich technische Probleme hat, die so nicht behoben werden können.
Bei mir war z. B. mal die Netzwerkkarte defekt und die haben die dann ohne Kosten für mich einfach getauscht. Danach war wieder alles i.O.
Kann jedem passieren, egal, wo er seinen Server hat.
Okay, über den Support bei S4U ist man geteilter Meinung, aber das ist wohl auch immer situationsbedingt getrieben, welchen Eindruck man erhält.
Auch viele andere Firmen sind da im Zwielicht der Kunden...
Man darf aber auch nicht vergessen, daß man bei einem dedizierten Root-Server alles selber machen muss.
Der Anbeiter des Servers ist dabei nur für die technische Seite verantwortlich, so daß selbst Fehler im OS auch selber zu beheben sind. Im schlimmsten Fall durch eine Neuinstallation, die man ja auch fast immer durch das Provider-Frontend anstossen kann.
Ebenfalls müssen Fehler beim Update am System auch selber behoben werden, sonst kostet das auch klar wieder Geld. Das Support-Ticket-System von S4U finde ich hierzu allerdings genial und hatte es anfänglich auch immer mal genutzt.
@Holger
Wenn es immer die selbe Uhrzeit ist, solltest Du zunächst mal in die Zugriffsstatistiken (z. B. Webalizer) schauen, ob dort z. B. vermehrt Zugriffe per HTTP auflaufen (also normale Web-Aufrufe).
Bots kann man dann ja zunächst auch aussperren. Gerade Google und Yahoo sind hier immer recht aktiv. Meist aber auch den gesamten Tag über.
Dazu auch prüfen, welche Emails in welcher Anzahl wann über den Tag verteilt aufschlagen.
Gerade Spammails kommen ab abends bis morgens, da durch die Zeitverschiebung z. B. zu Amerika nun einmal ein paar Stunden dazwischen liegen.
Das könnte u. a. die Ursache für die ca. 22.00 Uhr sein, ab dann wird es nämlich auch auf meinem Server hektischer. Zumimdest sehe ich das auf dem externen Postfach, wo ab dann vermehrt Spammails aufschlagen, die ja weitergeleitet werden.
Auch mal nachschauen, ob z. B. ein Backup zu dieser Zeit läuft (also durch Plesk angestossen). Das bremst auch gewaltig, wenn es falsch konfiguriert wurde.
Ping-Tools kenne ich keines, aber mit einem Ping auf Deine Domain kann jeder selber prüfen, ob der Server da ist und wie schnell er reagiert. Zeiten unter 20 ms sollten dabei normal sein.
Allerdings ist das auch keine verlässliche Aussage, denn den Server selber erreicht man hier meist noch vernünftig, während z. B. der Webserver dann schon brach liegen kann.
Sofern Du zur besagten Zeit nicht vernünftig auf die Shell kommst (z. B. mit Putty), hat der Server eine sehr hohe Last zu bewältigen.
Unter Linux kann man mit dem Befehl "top" auf der Shell anschauen, was der dann gerade tut.
Sollte dabei z. B. spamassassin sehr häufig auftauschen, sind es vermehrt Spammails zu dieser Zeit, die verarbeitet werden müssen.
Ist der Apache "oben", so sind vermutlich vermehrt Bots unterwegs.
Braucht der Apache jedesmal sehr lange, sollte man mal das Forum prüfen, wo umfangreiche Operationen durchgeführt werden, die man dann versucht zu optimieren
Bedenke dabei aber auch, daß neben den eingerichteten Weiterleitungen "unbekannter" Empfänger auch Spammails auf die eingerichteten Adressen laufen können, die ja allesamt geprüft werden.
Sind das zu viele, streikt der Rechner und wird lahm bis nicht erreichbar.
Dazu mal auf dieser Seite nachschauen, wie man den spamassassin vernünftig einstellen kann:
http://www.yrex.com/spam/spamconfig.php
Dazu sein anzumerken, daß man besser nur kleine Emails durch den Filter jagt. Das geht mit dem Eintrag
Code: Alles auswählen
# Mails durch den Assassin jagen
:0fw
* < 512000
| spamassassin
in der .procmailrc und muss (nach enthaltenen allgemeinen Definitionen) als erste Regel dort stehen, damit diese Emails eben nicht geprüft werden.
Die Angabe 512000 ist dabei in Byte zu sehen.
Achtung! Die .procmailrc
muss immer als ASCII, bzw. Text hochgeladen werden, sonst wird sie nicht verwendet, bzw. verursacht Fehler!
Die Übertragungsart "auto" ist hier auch falsch!
Die meisten Spammails sind dazu auch kleiner. Kommen öfter grössere Emails an, die kein Spam darstellen, kann das eben dann auch den Server selbst ausbremsen.
Auch bei häufigen gepackten Emailanhängen, die ja zum Prüfen entpackt werden müssen, kann das den Server arg bremsen.
Auch kann man den Email-Transport auf dem Rechner beschleunigen (also von der Annahme bis zur Ablage im betreffenden Postfach). Bei mir habe ich in der Datei /etc/exim4/conf.d/main/02_exim4-config_options Folgendes eintragen:
Das beschleunigte bei mir ungemein die Verarbeitung der Emails.
Sofern die eben nicht sofort weitergeleitet werden und auf meinem Server verbleiben.
Nach dieser Änderung ist dann der Email-Daemon (Email-Server) neu zu starten mit
Also ich tippe bislang bei Dir immer noch auf Spammails, da sie zunächst die erste grösssete Ursache für lahme Server sind. Auch lässt sich das nicht unbedingt an einer Uhrzeit festmachen, die Masse kann bereits auch schon vor 22 Uhr aufschlagen und erst ab der Uhrzeit wäre der Server dann restlos überfordert und hängt, bzw, lahmt.
Sofern immer recht "genau" um 22 Uhr der Server hängt, solltest Du das mal von S4U prüfen lassen. Kann ja sein, daß die selber noch Sicherungen fahren, was ich mir aber bei einem dedizierten Root Server nicht vorstellen kann, da S4U hier klar die Verantwortung auf den Kunden legt.
Aber die können helfen, die Ursache zu finden, wenn wir hier nicht zur Lösung kommen.
Schau mal, was Du zumindest mit den Emails erreichst und was weiter zu beobachten geht. Vielleicht kannst Du mit den Zugriffsstatisitken und "top" den Schuldigen bereits ausfindig machen.
Technische Mängel am Server selber kann ich nach Deinen Schilderungen jedenfalls zunächst ausschliessen, denn welches Gerät hängt mit stoischer Regelmässigkeit zur selben Uhrzeit, wenn es defekt ist