RootForum Community

Posted: **2007-03-30 00:27**

Hallo, ich habe ein Problem und bin weder über Google noch über die Suchfunktion hier so wirklich fündig geworden und weiss momentan nicht wo ich ansetzen soll.

Auf unserem Rootserver (kein VServer) haben wir seit ein paar Tagen ein Problem. Sobald eine Webseite SQL Abfragen benutzt baut diese ganz langsam auf und komischerweise ist auch der ssh Login superlangsam geworden (logge mit key ein). Seiten ohne SQL sind sehr schnell. Das Problem gab es vorher nie und der Server läuft jetzt schon ca 1 Jahr ohne Probleme. Es ist auch schon länger weder am Server noch an den Domains was geändert worden. Es sind lediglich Domains hinzugekommen, wie immer, aber momentan nichts großes was irgendwas haette bewirken können.

Kurze Daten:

1 user, load average: 0.17, 0.06, 0.01
Tasks: 152 total, 1 running, 151 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.2% sy, 0.0% ni, 99.5% id, 0.1% wa, 0.0% hi, 0.0% si
Mem: 1035848k total, 553120k used, 482728k free, 62040k buffers
Swap: 1951888k total, 0k used, 1951888k free, 328824k cached

Ich habe sämtliche cronjobs, Dienste etc die nicht benötigt werden probeweise deaktiviert. Die Problematik zeigt sich dann aber sogar wenn ich reboote direkt nach dem Hochfahren.

Für Apache, php , sql usw benutze ich eine Lampp Version zusammen mit Confixx.

Apache 2.0.54, SQL 4.1.14

# Servertraffic: In diesen Tabellen wird der Netzwerktraffic dieses MySQL-Servers seit dessen Start aufgeführt.
Traffic Ã¸ pro Stunde
Empfangen 221.781 Bytes 4.237 KB
Gesendet 1.723 KB 33.705 KB
Insgesamt 1.939 KB 37.942 KB

Verbindungen Ã¸ pro Stunde %
Fehlgeschlagen 0 0,00 0,00 %
Abgebrochen 2 39,13 6,25 %
Insgesamt 32 626,09 100,00 %
# Abfragestatistik: Seit seinem Start wurden 1.341 Abfragen an diesen MySQL-Server gesandt.
Insgesamt Ã¸ pro Stunde Ã¸ pro Minute Ã¸ pro Sekunde
1.341 26.236,96 437,28 7,29

Ich habe im Errorlog auch einige komische Einträge, die ich allerdings wie ich ebend gesehen habe schon weit zurück im Log habe.

[Datum] [error] [client x.x.x.x] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Es ist extrem Auffällig mit dem Aufbau. Lasse ich eine einfache Tabelle aufbauen die auf die SQL zurückgreift dann war das früher "zack" da, jetzt stoppt er und nach 3-4 Sekunden baut er auf. Einige Sachen da konnte man getrost einen Kaffee kochen gehen bevor der fertig war.

Die CPU Last ist die ganze Zeit bei 0,x - 3% und trotzdem tritt der Effekt auf.

Ich erwarte keine Komplettlösungen , aber vielleicht hat einer eine Ahnung wodran es liegen könnte! und kann mir einen Schubser in die richtige Richtung geben wonach ich mal gucken sollte. Wäre echt super nett.

Gruß

Posted: **2007-03-30 01:21**

Deine Software ist veraltet/ungepatched und weist einige bekannte Sicherheitslücken und Fehlfunktionen auf. Desweiteren scheint die Konfiguration Deiner Dienste und die Programmierung Deiner Scripte suboptimal zu sein...

Posted: **2007-03-30 06:14**

Wie voll ist die Partition, auf der die MySQL-Datenbanken abgelegt werden?
Wie groß sind die Logfiles (bzw. wurden die mal rotiert)?
Wie verhält sich MySQL, wenn auf der Maschine nichts anderes gestartet ist und Du per CLI auf die Datenbank zugreifst?
Was sagt der Server-Status (SHOW STATUS)?

Wie Joe User schon angemerkt hat, wurde der Support für MySQL 4.1 eingestellt (siehe http://dev.mysql.com/doc/refman/4.1/en/index.html und http://www.mysql.com/company/legal/lifecycle/#calendar) - Bug- und Securityfixes werden aber weiter zur Verfügung gestellt (Security and Severity Level 1).

Posted: **2007-03-30 17:34**

Erstmal danke für eure beiden Antworten.

Wie voll ist die Partition, auf der die MySQL-Datenbanken abgelegt werden?

75%, war teilweise schon mehr aber dann wurde auf hd2 umgelagert

Wie groß sind die Logfiles (bzw. wurden die mal rotiert)?

hab ich in letzter zeit alle manuell geleert

Wie verhält sich MySQL, wenn auf der Maschine nichts anderes gestartet ist und Du per CLI auf die Datenbank zugreifst?

ich habe ein kleines tool was eine tabelle ausliest mit meinen tagesverdiensten ... mehrere selects für den monat die da ausgeführt werden... im web stockt es und bleibt fuer 10 sek stehen bevor alles angezeigt wird , gehe ich direkt ueber die ssh und mache ein select auf die tabelle, dann erhalte ich: 771 rows in set (0.00 sec)

ich habe auch schon über den mysqlcheck alle datenbanken optimieren lassen ...

Was sagt der Server-Status (SHOW STATUS)?

die meisten befehle sind selects, da zumeist nur der datenbestand aus der sql zum anzeigen gebraucht wird .... 36,8k pro Stunde ... die restlichen 30% verteilen sich auf die anderen sql befehle ... was mir in den prozessen beim beobachten aufgefallen ist, dass der prozess immer ca 10 sek gehalten wird dann steht da auch sleep und dann nach 10 sek kommt das ergebnis ;

Deine Software ist veraltet/ungepatched und weist einige bekannte Sicherheitslücken und Fehlfunktionen auf.

Jup leider weiss ich. Ich habe mich nur an den Grundsatz gehalten: never touch a running system ... ich war damals so froh dass alles funktioniert hat und einigermaßen eingestellt war ... dann haben ein paar kurpfuscher dran rumgebastelt , allerdings lief er danach monatelang trotzdem noch ohne probleme ; es lief jetzt ja insgesamt auch sehr lange ohne Probleme ... ich habe heute mal versucht alles auf die neuste xampp version umzustellen, allerdings ist das alles nicht so einfach ,... zumal da ne menge domains, webs, zugänge, datenbanken etc alles dranhängen ... ein überkopieren von einigen daten funktioniert da leider nicht so einfach ...

Desweiteren scheint die Konfiguration Deiner Dienste und die Programmierung Deiner Scripte suboptimal zu sein...[/quote]

programmierung meiner skripte ist gut, da bin ich fest von überzeugt zumal ich in den letzten jahren an der mitarbeit an großen firmenprojekten im netz auch viel erfahrungen sammeln durfte ... angst machen mir da eher die skripte von meinem partner mit dem ich mir den server teile, der irgendwie alles installiert was er unter die finger kriegt ...

die dienste ,... gute frage ... nach bestem wissen und gewissen damals gemacht ...

Aber warum läuft ein System sagen wir 2 Jahre optimal und plötzlich von heute auf morgen so ein Fehlverhalten ohne dass irgendwas an einer Konfiguration geändert wurde ?

Ich habe ebend auch nochmal mit der my.cnf mit den Einstellungen rumexperimentiert und mir über google diverse infos eingeholt aber es hat alles keinen erfolg gebracht.

Ich werde es auf die neuste Version irgendwie uminstalliert kriegen, aber ich bin mir nicht so sicher dass dies wirklich das Problem löst.

Gruß
Ein verzweifelnder ...

Posted: **2007-03-30 17:58**

WiZARD76 wrote:Ich habe mich nur an den Grundsatz gehalten: never touch a running system ...

Dieser Grundsatz gilt nur für nicht an öffentlichen Netzen betriebene Systeme, beispielsweise in einem privaten LAN. Verfügbare Security-Updates nicht zeitnah durchzuführen, ist quasi Selbstmord auf Raten...

Wie sehen denn Dein Tabellenshema und die entsprechenden SELECTs aus?

Posted: **2007-03-30 18:14**

Joa, das mit den Sicherheitsupdates muss ich mir auf die Fahne schreiben. Da hast du Recht, das habe ich bisher immer "wissend in kauf" genommen. Das würde aber im Umkehrschluss bedeuten, dass jemand die Maschine gehackt hat :-?

Die Frage ist welches von den vielen tausend skripten / hundert datenbanken wovon die haelfte nichtmal mir gehört ; (ich darf nur hinhalten wenn der server nicht läuft *grml*) ; ich habe sämtliche tabellen die viel inhalt produzieren nach einem backup alle geleert .... die datenbanken bewegen sich jetzt alle in einem kleinen megabytebereich, teils auch drunter ... die eine Datenbank mit der Tabelle die stockt bewegt sich mit 799 Datensätzen im Kilobytebereich.

Was mich angeht versuch ich soviel es geht in eine einzelne SQL Abfrage zu packen (mit joins etc) um so zuviel einzelne Abfragen in einer Schleife zu vermeiden und die wirklich benötigten Daten innerhalb des schleifenlaufs parat zu haben. Wie das die vielen anderen Skripte von "ihm" machen weiss ich so aus dem Stehgreif nicht ohne die alle nachzusehen.

Aber ich stelle mal eine These auf: egal wie die Selects, Inserts, Updates bisher gearbeitet haben ; sie haben bis vor wenigen tagen alle ohne lags funktioniert. Es hat sich am System nichts geändert. Die Datenbanken wurden gecheckt, größtenteils gelöscht, die Logfiles wurden geleert. Logische Schlussfolgerung wäre eigentlich, dass der Server hätte nun schneller/besser rennen müssen stattdessen läuft er schlechter, obwohl er keine großen DBs mehr hat, keine riesigen Logfiles. Irgendwie komisch. Und wenn es irgendwie auf zu große / schlecht optimierte DBs / schlechten Code zurückzuführen wäre, warum stocken die Abfragen für 10-15 Sekunden selbst bei Abfragen wo die Tabelle/Datenbank nur wenige Kilobyte groß ist. Ich denke spätestens bei einer 10 kb großen Tabelle dürften gar keine Probleme auftauchen.

Posted: **2007-03-30 18:34**

Führe mal folgendes aus, evenuell hilft es ja etwas:

Code: Select all

nice -n -10 mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p

JOINs sind nicht immer von Vorteil, daher wäre das DB-Shema und die SELECTs für die betroffene Datenbank durchaus interessant...

Posted: **2007-03-30 18:45**

Danke für deine Antworten Joe ...

bei 99% der Tabellen kriege ich "Table is already up to date", beim Rest "OK" und bei ein paar Ausnahmen:

Repairing tables
usr_web3_5.bb1_sessions
note : The storage engine for the table doesn't support repair
usr_web3_6.bb1_sessions
note : The storage engine for the table doesn't support repair
usr_web4_3.bb1_sessions
note : The storage engine for the table doesn't support repair
usr_web4_9.4images_sessions
note : The storage engine for the table doesn't support repair

Sind die hinüber ? Dann kick ich die einfach, mir doch egal :twisted: :lol:

Auftreten tut dies bei jeder Tabelle , egal wie groß / angeordnet o.ä. - hier mal ein ganz einfaches Beispiel: select * from verdienst where datum > 'xxxxx' and datum < 'xxxxx'

CREATE TABLE `verdienst` (
`id` int(10) unsigned NOT NULL auto_increment,
`datum` datetime NOT NULL default '0000-00-00 00:00:00',
`betrag` decimal(4,2) NOT NULL default '0.00',
`gesamt` decimal(4,2) NOT NULL default '0.00',
`waehrung` char(3) NOT NULL default '',
`abrechner` varchar(20) NOT NULL default '',
`zusatz` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=800 ;

Hier mal ein Beispiel einer Prozessliste, wobei mich dieses komische Auktionshaus ein bischen wundert wie es da die Datenbank aufruft:

1 web4 localhost usr_web4_17 Sleep 96 --- ---
6 xxxuser localhost.localdomain:33277 auction Sleep 86 --- ---
9 xxxuser localhost.localdomain:33280 auction Sleep 84 --- ---
12 xxxuser localhost.localdomain:33285 auction Sleep 80 --- ---
15 xxxuser localhost.localdomain:33290 auction Sleep 76 --- ---
18 root xxxuser usr_web3_7 Sleep 71 --- ---
19 xxxuser localhost.localdomain:33300 auction Sleep 71 --- ---
22 xxxuser localhost.localdomain:33310 auction Sleep 64 --- ---
25 xxxuser localhost.localdomain:33316 auction Sleep 61 --- ---
35 root localhost network Sleep 4 --- ---
41 web4 localhost usr_web4_17 Sleep 15 --- ---
50 web4 localhost usr_web4_17 Sleep 4 --- ---
53 web3 localhost usr_web3_2 Sleep 1 --- ---

Posted: **2007-03-30 19:55**

WiZARD76 wrote:Sind die hinüber ?

Nein, sie verwenden (vermutlich) die MEMORY-ENGINE, siehe MySQL-Handbuch...

Posted: **2007-03-31 15:16**

Hab zu dem Thema nachgelesen.

Heute habe ich alles runtergefahren was nicht zum Systembetrieb notwendig ist. Ich habe eine aktuelle Xampp Version installiert (Apache 2.2.4, MySQL 5.0.33, PHP 5.2.1) und gestartet. An den Standardconfig Files die dabei sind wurde nichts geändert.

Eine absolut frische Datenbank. Der Webserver + Datenbank lag jetzt aber auf der zweiten Festplatte und nicht wie bei der alten Installation auf Festplatte 1. Ich habe eine einzige Datenbank angelegt und versucht mit ein paar Selects mit php den Inhalt auszulesen ; Zeile für Zeile. Gleiches Phänomen. Sehr sehr langsam , man kann beim Seitenaufbau Kaffee trinken - SQL bremst alles aus.

Ist das nicht komisch ?

;

Außerdem krieg ich immer die Meldung dass der Client das Protocol nicht unterstützt ich soll den Client updaten. Ich habe die libmysqlclient(?) über apt-get upgedated, kriege aber immer noch die Meldung dass ich updaten soll (z.b. beim import einer Datenbank über mysql -h ... ) Ich möchte aber nicht sämtliche Passwörter auf OLD stellen wie auf der MySQL Seite beschrieben wird sondern gleich den Client richtig updaten ; ist ja eh nötig ;

mysql-client 4.0.24-10sarge
libmysqlclient 4.0.24-10sarge

Jedenfalls sagt er jetzt alles ist up to date mit apt-get aber 4.0.24. ist ja beim Client veraltet.

Ich glaube mittlerweile ein Starkstromkabel am Server bewirkt jetzt langsam mehr wunder als das was da los ist.

Posted: **2007-03-31 17:16**

xampp ist wird übrigens von den Entwicklern nicht für den Produktiv-Einsatz auf öffentlich zugänglichen Systemen empfohlen... Spricht etwas dagegen, die Pakete deiner Distribution zu verwenden?

Posted: **2007-03-31 20:00**

Nein, aber für mich ist der Einsatz von Xampp aber genauso ok, weils bisher immer gut lief und einfach handzuhaben war. Aber ob so oder so, es läuft nicht :(

Posted: **2007-03-31 20:33**

Du musst Dich zwischen den Paketen aus xampp und denen Deines Distributoren entscheiden. Dein derzeitiger Mix ist für Deinen aktuellen Kenntnisstand absolut ungeeignet. Wenn Du bei xampp bleiben willst, dann deinstalliere bitte mindestens alle Apache, MySQL und PHP Pakete Deiner Distribution vollständig und rekompiliere anschliessend xampp.
Alternativ und sowohl Deinem Kenntnisstand entsprechend, als auch sicherheitstechnisch Empfehlenswerter, schmeisst Du xampp komplett von der Platte und verwendest die Distributionspakete...

Posted: **2007-04-01 07:22**

WiZARD76 wrote:gehe ich direkt ueber die ssh und mache ein select auf die tabelle, dann erhalte ich: 771 rows in set (0.00 sec)

Ich gehe mal davon aus, dass Du uns damit sagen willst, dass der Datenbank-Zugriff über den MySQL-Client von der Kommandozeile aus problemlos und schnell läuft. Im Umkehrschluss würde das bedeuten, dass nicht der MySQL-Server das Problem ist, sondern entweder PHP selbst oder die in PHP einkompilierten MySQL-Clientbibliotheken (z. B. ein Versionskonflikt?!).

Poste uns doch mal die Ausgabe von top genau zu dem Zeitpunkt, wo ein PHP-Skript mit MySQL-Abfrage hängt - vielleicht verrät das mehr über den eigentlichen Übeltäter.

Posted: **2007-04-03 14:57**

Der eigentliche Übeltäter ist identifiziert und hing nicht mit der SQL Datenbank zusammen, so wie es zuerst schien ... Es war wohl ein dummer zufall...

Mir ist aufgefallen , dass jedesmal wenn per PHP mit Curl oder File() eine externe http:// Seite geladen wird, dass der Server dann voll ausbremst und man 20 Sekunden zugucken kann, auch wenn die Zielseite im normalen Browser schnell aufgeht. Ich habe mal Testweise auf dem betroffenen Server und auf einem anderen Server ein

Code: Select all

echo implode(file('http://www.url.de'));[/quote]

eingegeben und per Webbrowser ausgeführt. Auf dem "kleinen" Server ist die Seite sofort da und auf dem "kaputten" warte ich locker 20 Sekunden. Anbetracht der Serverdaten dürfte dies aber nicht sein, zumal der besser ist als der andere schnellere Server (2xXeon 2.8 Ghz HT, 2x80GB SATA, 1GB ECC-R).

Frage mich nur warum sowohl die alte als auch eine neue Standardinstallation plötzlich Probleme damit haben. Ich habe mal einen Virenscanner installiert und einen Rootkitdetektor und die drüberlaufen lassen - ohne Befund. Ein Ping in der SSH auf die Ziel URL die eingelesen wurde liefert nahezu identische Werte, allerdings ist der PING Befehl auf dem "kaputten" viel viel langsamer und pingt wesentlich seltener als auf dem anderen Server im gleichen Zeitraum.

Komisch oder ?

Posted: **2007-04-03 15:03**

Was sagen die Fehlerwerte bei `ifconfig`?

Posted: **2007-04-03 16:49**

Meinst Du eine "ifconfig" Ausgabe ?

Code: Select all

eth0      Link encap:Ethernet  HWaddr 00:14:22:73:6B:88
          inet addr:83.149.125.162  Bcast:83.149.125.255  Mask:255.255.255.0
          inet6 addr: fe80::214:22ff:fe73:6b88/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29097193 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25992287 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2838202346 (2.6 GiB)  TX bytes:4201581417 (3.9 GiB)
          Base address:0xecc0 Memory:dfde0000-dfe00000

eth0:1    Link encap:Ethernet  HWaddr 00:14:22:73:6B:88
          inet addr:83.149.125.147  Bcast:83.149.125.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Base address:0xecc0 Memory:dfde0000-dfe00000

eth0:2    Link encap:Ethernet  HWaddr 00:14:22:73:6B:88
          inet addr:83.149.125.148  Bcast:83.149.125.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Base address:0xecc0 Memory:dfde0000-dfe00000

eth0:3    Link encap:Ethernet  HWaddr 00:14:22:73:6B:88
          inet addr:83.149.125.149  Bcast:83.149.125.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Base address:0xecc0 Memory:dfde0000-dfe00000

eth0:4    Link encap:Ethernet  HWaddr 00:14:22:73:6B:88
          inet addr:83.149.125.150  Bcast:83.149.125.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Base address:0xecc0 Memory:dfde0000-dfe00000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1303203 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1303203 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:141785426 (135.2 MiB)  TX bytes:141785426 (135.2 MiB)

Na wenn wir den Fehler hier finden ist aber wohl mindestens ein Pfund Kaffee fällig wa :lol:

Posted: **2007-04-03 17:22**

WiZARD76 wrote:Meinst Du eine "ifconfig" Ausgabe ?

Ja.

WiZARD76 wrote:Na wenn wir den Fehler hier finden ist aber wohl mindestens ein Pfund Kaffee fällig wa :lol:

Nein, scheint leider nicht so.

Posted: **2007-04-03 18:01**

Vielleicht noch eine Möglichkeit (ist aber eher im Nebel gestochert): Funktionieren Netzzugriffe denn schneller, wenn Du direkt die IP angibst anstelle des Hostname? Könnte IMHO immerhin sein, dass der lahmende Server einfach nur einen überlasteten DNS-Server befragt... dann könnte ein eigener lokaler DNS als Cache ungemein helfen.

Ansonsten mach mal ein Trace Route zu einem Dir bekannten Host und poste die Ausgabe... vielleicht ist es gar nicht Dein Server, sondern einer der Router auf dem Weg nach draußen, der ein Lastproblem hat.

Posted: **2007-04-03 19:04**

Kaputter Server Richtung heiler Server:

Code: Select all

 1  ge-7-0.r2.sbp.ams.nl.leaseweb.net (83.149.65.252)  0.331 ms  0.371 ms  0.280 ms
 2  gi3-2.amsix.nl.leaseweb.net (83.149.127.53)  0.721 ms  0.706 ms  0.738 ms
 3  amsix.sara.ams.spxs.net (195.69.145.99)  184.998 ms  12.075 ms  13.010 ms
 4  UpstreamWebJanssen.ffmxs06.redbus.ffm.spxs.net (212.211.254.102)  12.101 ms  10.224 ms  11.695 ms
 5  85.197.127.210 (85.197.127.210)  10.981 ms  10.398 ms  10.470 ms

Kaputter Sever Richtung Google.de

Code: Select all

traceroute to google.de (216.239.59.104), 30 hops max, 38 byte packets
 1  ge-7-0.r2.sbp.ams.nl.leaseweb.net (83.149.65.252)  0.353 ms  0.374 ms  0.286 ms
 2  ge1-3.amsix.leaseweb.net (83.149.127.41)  50.888 ms  1.012 ms  0.698 ms
 3  core2.ams.google.com (195.69.145.100)  1.062 ms  0.985 ms  0.861 ms
 4  216.239.43.89 (216.239.43.89)  1.163 ms  1.042 ms  1.087 ms
 5  216.239.43.90 (216.239.43.90)  8.544 ms  8.488 ms  8.517 ms
 6  66.249.95.107 (66.249.95.107)  19.232 ms  19.333 ms  19.215 ms
 7  64.233.174.185 (64.233.174.185)  19.221 ms  19.325 ms  19.237 ms
 8  216.239.49.126 (216.239.49.126)  21.934 ms  23.981 ms  22.343 ms
 9  gv-in-f104.google.com (216.239.59.104)  20.529 ms  19.448 ms  19.337 ms

Heiler Server Richtung kaputter Server:

Code: Select all

 1  router.ffm.webjanssen.de (85.197.112.1)  0.287 ms  0.218 ms  0.198 ms
 2  Fa8-0-0.ffmxs06.redbus.ffm.spxs.net (212.211.254.101)  2.266 ms  3.116 ms  1.838 ms
 3  10ge-2-0.amsix.ams.nl.leaseweb.net (195.69.144.215)  10.775 ms  10.484 ms  10.944 ms
 4  10ge-1-0-0.r1.sbp.leaseweb.net (83.149.127.30)  9.838 ms  12.153 ms  12.553 ms
 5  83.149.125.162 (83.149.125.162)  10.325 ms  9.681 ms  10.224 ms

Auch wieder der selbe Effekt, auf dem "kaputten" funktioniert der Traceroute wesentlich langsamer. Der "kaputte" steht in Holland bei leaseweb ... der Ping innerhalb des eigenen Netzes da scheint aber nicht so doll zu sein bei dem amsix, oder ?

Posted: **2007-04-03 19:46**

Leaseweb scheint träge beziehungsweise zu wenig (deutsche) Peerings zu haben.

Posted: **2007-04-03 21:13**

Ich werd die mal ansprechen und festnageln, das war ja bis vor kurzem nicht so. Vielleicht irgendwelche Netzprobs die die haben ... we will see ...

:D

RootForum Community

SQL bremst Server aus, CPU Last bei 0, - 3%

SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%

Re: SQL bremst Server aus, CPU Last bei 0, - 3%