Bekijk Volledige Versie : Bandbreedte probleem?
Hallo,
Ik zit met het volgende probleem, server load is goed meestal onder de 1, traffic gemiddeld rond de 230GB/dag.
Maar om onbekende rede gaat de bandbreedte van 25Mbps naar 5Mbps dit is al 2 keer voorgevallen, vorige week en vandaag.
Vorige week heb ik voor 3u een trage site gehad, wat gezocht waar eventueel het probleem lag, maar heb niets aan de instellingen veranderd en na een tijd weer alles terug inorde.
Bij normale bandbreedte heb ik rond de 300processen, maar als bandbreedte laag is maar 180.
Server is een P4 2.8Ghz, 1024MB ram, CentOS 4.1 en bestaat uit een grote site die hoofdzakelijk images en files bevat,50K+ unique bezoekers per dag. Images en files lokatie word opgezocht in een mysql db.
Ik krijg soms een timeout als ik de server ping, 83.149.104.34 hoe zit dit bij jullie?
Ik heb vorige week een mail gestuurt naar Leaseweb of er eventueel een netwerk probleem was maar zei vonden niets en zeiden dat het wss aan de server lag.
Iemand enig waar dit kan aan liggen en hoet dit kan opgelost worden? Misschien ligt het probleem toch bij het netwerk?
Dank bij voorbaat
Vanaf XS4ALL .BE :
Pinging 83.149.104.34 with 32 bytes of data:
Reply from 83.149.104.34: bytes=32 time=70ms TTL=54
Request timed out.
Reply from 83.149.104.34: bytes=32 time=164ms TTL=54
Reply from 83.149.104.34: bytes=32 time=178ms TTL=54
Ping statistics for 83.149.104.34:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 178ms, Average = 137ms
Vanaf KDIS :
22 packets transmitted, 21 received, 4% packet loss, time 21022ms
rtt min/avg/max/mdev = 1.010/1.160/1.547/0.136 ms, pipe 2
vanaf Skynet .BE :
12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max/mdev = 9.983/17.668/39.984/8.144 ms
Netwerk lijkt me sterk :
Naar een server van ons (ook lsw) :
Pingen naar 82.192.72.xxx met 32 byte gegevens:
Antwoord van 82.192.72.xxx: bytes=32 tijd=10 ms TTL=57
Antwoord van 82.192.72.xxx: bytes=32 tijd=10 ms TTL=57
Antwoord van 82.192.72.xxx: bytes=32 tijd=9 ms TTL=57
Antwoord van 82.192.72.xxx: bytes=32 tijd=10 ms TTL=57
Ping-statistieken voor 82.192.72.xxx:
Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
(0% verlies).De gemiddelde tijd voor het uitvoeren van één bewerking in mill
iseconden:
Minimum = 9ms, Maximum = 10ms, Gemiddelde = 9ms
Vanaf home (wanadoo dsl) naar 83.149.104.34 :
Pingen naar 83.149.104.34 met 32 byte gegevens:
Antwoord van 83.149.104.34: bytes=32 tijd=11 ms TTL=56
Antwoord van 83.149.104.34: bytes=32 tijd=10 ms TTL=56
Antwoord van 83.149.104.34: bytes=32 tijd=10 ms TTL=56
Antwoord van 83.149.104.34: bytes=32 tijd=11 ms TTL=56
Ping-statistieken voor 83.149.104.34:
Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
(0% verlies).De gemiddelde tijd voor het uitvoeren van één bewerking in mill
iseconden:
Minimum = 10ms, Maximum = 11ms, Gemiddelde = 10ms
Vanaf server :
PING 83.149.104.34 (83.149.104.34) 56(84) bytes of data.
64 bytes from 83.149.104.34: icmp_seq=0 ttl=61 time=0.838 ms
64 bytes from 83.149.104.34: icmp_seq=1 ttl=61 time=0.802 ms
64 bytes from 83.149.104.34: icmp_seq=2 ttl=61 time=0.929 ms
64 bytes from 83.149.104.34: icmp_seq=3 ttl=61 time=1.20 ms
--- 83.149.104.34 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.802/0.944/1.207/0.158 ms, pipe 2
Lijkt niks mis ?
Bedankt,maar wat ik raar vind is dat het vorige keer vanzelf trager ging en vanzelf terug sneller, ik hebt niets aan de instellingen veranderen.
Enig idee waar het dan aan kan liggen?
Hier kun je zien hoe traag het op dit moment gaat, kleine site op de server http://www.domainshuffle.com/
Hier nog een bin op server: http://83.149.104.34/10mb.bin
Snelheid is opzich goed (volle lijn).
Maar de website idd erg traag.
Hoe zit het met het geheugen gebruik ?
En met swap gebruik ?
En geen leuke cron jobs aanwezig :) ?
Nee vind geen cronjobs die voor problemen kunnen zorgen. Is er mss een gemakkelijke manier op alle cronjobs uit te zetten?
Output van top:
top - 22:54:51 up 2:44, 1 user, load average: 0.46, 0.58, 0.51
Tasks: 158 total, 1 running, 135 sleeping, 0 stopped, 22 zombie
Cpu(s): 3.7% us, 4.8% sy, 0.0% ni, 89.9% id, 0.2% wa, 0.2% hi, 1.3% si
Mem: 1034492k total, 1008924k used, 25568k free, 18112k buffers
Swap: 2096472k total, 144k used, 2096328k free, 842748k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1125 root 25 0 21648 13m 9832 S 2.7 1.3 2:46.74 httpd
29067 root 16 0 2220 1020 748 R 0.3 0.1 0:10.01 top
1 root 16 0 2644 552 472 S 0.0 0.1 0:00.59 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.12 ksoftirqd/1
6 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/0
7 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/1
8 root 6 -10 0 0 0 S 0.0 0.0 0:00.00 khelper
9 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid
Volgende dag.. alles terug inorde, rare boel :)
Origineel geplaatst door Ace
Volgende dag.. alles terug inorde, rare boel :)
idd rare webserver :)
Je kunt met een trace natuurlijk geen bandbreedte testen.
Het lijkt mij zeker niet uitgesloten dat de beschikbare bandbreedte in het netwerk fluctueert. Het vervelende is echter, dat er lastig achter te komen is, als klant. Ik heb ook wel eens meegemaakt dat ik op het ene moment met 300Kbps ging, en een dag later 3MB(byte)ps. Als op dezelfde node lekker gepompt wordt, blijft er minder voor de rest over :rolleyes:
Hey...
Ik zit net aan iets te denken.
Jij zit waarschijnlijk ook op een 100mbit switch.
Zijn er nog meer 'grote' gebruikers daar toevallig op aangesloten ?.
Zodat er dus een kapaciteits probleem komt, omdat de switch maar een 100mbit uplink heeft?...
Misschien een idee om daar is naar te kijken.
En ik zou zeker ook even kijken hoe oud de server is, en of daar niks mis mee is.
Tevens, de server load is 1 zeg je, maar wat is het cpu gebruik (%) ?
Maar het is raar dat het zo echt in sprongen gaat, van 25 tot 5mpbs dan zo voor een paar uur en dan weer terug rond de 25mbps.
Ik weet niet of er nog meer grote gebruikers zijn aan gesloten op die switch ik zal het eens vragen aan leaseweb.
Ik heb deze server voor ongeveer 2 maanden weet niet of hij hiervoor al gebruikt is ofzo.
CPU gebruik is meestal rond de 7%.
Ik heb zojuist een mail terug gehad van leaseweb, maar ja nu is ondertussen het probleem al verholpen.
Dit stond in de mail:
Nee, de server hangt op een 1Gbps verbinding naar onze coreswitches en heeft geen last van overbelasting.
Iemand enig idee wat het kan zijn?
Als het nogmaals voorvalt:
- inloggen op server, kijken naar processen, en welke belasting die geven
- kijken naar logfiles, naar vreemde boodschappen
- vanaf enkele andere plaatsen traceroutes uitvoeren, en zoeken naar vreemde paden of packet loss. Ook reverse path bekijken, voor assym routering
- errors op je netwerkpoorten bekijken (slechte kabel?)
- je kan altijd tools als smokeping en zo installeren, en enkele populaire netwerken erin plaatsen, en kijken waar het probleem zit.
- kijken wat de server doet (swapping, processen onderzoeken, hardwarebeperkingen (bv IO naar disks bij grote schrijfoperaties)...)
- ... allemaal systeembeheer ;)
Bedankt voor de tips :)
Maar een paar weet ik wel niet hoe doen.
- Het gedeelte met reverse path voor assym routering bv :)
- hoe zie je errors op je netwerk poort? (netstat?)
- de IO naar disks hoe zie je die?
Origineel geplaatst door Ace
- hoe zie je errors op je netwerk poort? (netstat?)
Je switch of die van je provider zou CRC errors moeten geven.
Deze kunnen inhouden dat:
1- De netwerkkabel kapot is.
2- De netwerkkaart kapot is.
3- De netwerkpoort (switch) is kapot.
1) asym routering. Doe een traceroute vanaf een IP naar je server. Doe dan een traceroute van je server naar dat IP (de omgekeerde richting dus). Vergelijk als het verkeer een ander pad volgt (omgekeerd dus).
2) fouten: op de switch (moet een managed zijn), of op je OS (ipconfig in linux).
3) io naar disks: 'man iostat'
Bedankt voor de uitleg!
En ik kan niet aan de switch spijtig.
Ik was al aan tabben op 'io' maar er kwam niets, zal ik dat eens moeten installeren dan.