[Debian] SSH verliest verbinding bij veel data

[GrimaceODespair]

Ik leg met PuTTy via een SSH-connectie verbinding met een Debian server. Alles gaat goed, tot op het moment dat de console heel veel tekst moet verwerken, zoals het cat-ten van een lange .conf (om maar iets te noemen).

Op zo een moment lijkt de verbinding te bezwijken onder de load, maar ik zou dus niet weten op welke manier ik hier iets aan kan doen. Er zit een baud rate in het SSH protocol, maar die kan ik noch met PuTTy instellen, noch terugvinden bij de SSH instellingen serverside.

Heeft iemand een idee wat precies het probleem kan zijn, en in welke richting ik dan de oplossing moet zoeken?

[Verwijderd]

en in welke richting ik dan de oplossing moet zoeken?

Richting de winkel voor een nieuwe netwerkkaart denk ik.

[GrimaceODespair]

Netwerkkaartprobleem lijkt me uitgesloten, omdat ie hier op andere PC's ook zijn gat gaat.

We werken hier wel via een lokale proxy (waar ik niks aan kan bijsleutelen). Dus ik kan me indenken dat daar een probleem zou liggen.

Misschien een bijkomende vraag dan: Is het normaal dat SSH niet zo stabiel is onder heavy load?

[ Voor 60% gewijzigd door GrimaceODespair op 19-05-2003 10:57 ]

[BezurK]

Verwijderd schreef op 19 May 2003 @ 10:50:
[...]
Richting de winkel voor een nieuwe netwerkkaart denk ik.

Lijkt me stug als zijn SSH-verbinding weg valt. Als het de netwerkkaart zou zijn dan zou zijn gehele netwerkverbinding wel wegvallen. Overigens zou hij dat dan al veel eerder gemerkt hebben, en niet pas/alleen bij het gebruiken van SSH

[DPLuS]

GrimaceODespair schreef op 19 mei 2003 @ 10:55:
(...)
Misschien een bijkomende vraag dan: Is het normaal dat SSH niet zo stabiel is onder heavy load?

Heavy load?
Het catten van een bestand is echt geen heavy load hoor!

Heb je toevallig recentelijk libc geupdate op die machine zonder opnieuw op te starten?
Toen ik dat deed liep mijn ssh namelijk ook compleet vast, moest even een service ssh restart doen toen...

Anders zou ik proberen ssh eens opnieuw te installeren...

[Verwijderd]

Doe eens een zooi pings naar die bak, kijk eens of je veel packetloss hebt...

[GrimaceODespair]

code:

152 packets transmitted, 150 packets received, 1% packet loss
round-trip min/avg/max = 12.2/16.6/57.9 ms

Lijkt me niet echt problematisch.

DPLuS schreef op 19 May 2003 @ 11:46:
Het catten van een bestand is echt geen heavy load hoor!
[...]
Anders zou ik proberen ssh eens opnieuw te installeren...

Noem je iets in de trant van "ls -r /" ook geen heavy (network) load? (is serieuze vraag)

Heb SSH ff gerestart, maar dat levert geen verbetering. Die re-install doe ik nog wel es als ik tijd heb. Ben nog niet dermate vertrouwd met Linux dat ik remote SSH zou re-installen. Als ik de boel verneuk, moet ik het halve land afreizen. Tot nader bericht is dit de status van dit probleem dus 'idle'

[Verwijderd]

Wat gebeurd er precies, verbreekt de verbinding direct of duurt het een tijdje en krijg je dan een soort time-out?

[GrimaceODespair]

Verwijderd schreef op 19 May 2003 @ 12:07:
[...] duurt het een tijdje en krijg je dan een soort time-out?

"Nagel op zijn kop" heet dat dan, en iets vertelt me dat je een idee hebt van het probleem

[Verwijderd]

Dat heeft dan toch met die packetloss te maken denk ik.

Zet ook even bij connection in putty bij minutes to keep alive 2 minuten ofzo. Weet niet of dat helpt, alsniet, dan is het zeer waarsch de packetloss

[ Voor 59% gewijzigd door Verwijderd op 19-05-2003 12:12 ]

[GrimaceODespair]

Kan SSH niet met packetloss om?

[Verwijderd]

GrimaceODespair schreef op 19 May 2003 @ 12:12:
Kan SSH niet met packetloss om?

Zie me berichtje, heb een edit gedaan. Opzich zou 1% niet een probleem moeten zijn lijkt me, maar je hebt kans dat je misschien bij vlagen, en vooral wanneer je veel data over de lijn haalt, de packetloss groter is en daarom de verbinding verbeekt.

Als je namenlijk met een gewone ping al 1% packetloss hebt, dan is er toch iets mis met de verbinding, zeker rond deze tijd van de dag.

Zet even een ping sessie op en doe ondertussen even zo'n dikke file catten. Kijk of de packetloss omhoog schiet. Ik denk van wel.

[ Voor 12% gewijzigd door Verwijderd op 19-05-2003 12:16 ]

[GrimaceODespair]

Ok, DeLaNo, bedankt voor de toelichting. Een betere verbinding, daar hebben we de hoop hier al lang voor opgegeven, dus waarschijnlijk zal het bij aankloten blijven

[Verwijderd]

Misschien wel even zinvol om uit te zoeken waar precies 't probleem zit. Dan kun je de betreffende partij in ieder geval op de hoogte brengen van het probleem. Packetloss is namenlijk een zeer vervelend verschijnsel wat veel meer gevolgen heeft dan alleen het verbreken van bv je ssh verbinding....

[GrimaceODespair]

Tijdens "ls -R /" schiet de packet loss niet omhoog (1 keer 3% geregistreerd, maar nou al een paar keer 0 op een stuk of 50 pings).

Ik denk dat ik de impact van packet loss nog niet helemaal goed kan inschatten. Is het niet zo dat de meeste protocollen dit kunnen opvangen door een re-request (bv: de sockets zelf al, vandaar TCP ipv UDP)? Of maak ik nou een denkfout?

[stfn345]

We werken hier wel via een lokale proxy (waar ik niks aan kan bijsleutelen). Dus ik kan me indenken dat daar een probleem zou liggen.
..

Iets zegt me dat het de proxy is
die liggen wel vaker dwars wanneer het om timeouts etc. gaat, net als bij je huidige probleem.

[Verwijderd]

3% packetloss is best veel, ik weet niet waar die server staat maar rond deze tijd van de dag zijn de lijnen absoluut niet zwaar belast, althans in Nederland dan. Inprincipe moet een beetje packetloss niet een groot probleem zijn, maar bij zware packetloss (als nu al 3% is vraag ik me af wat het tijdens piekuren is), dan word alles erg traag en heb je grote kans op timeouts en andere gekkigheden waardoor bepaalde dingen, zoals dus ssh, niet meer correct werken.

Zet voor de gein eens een stuk of 4 ssh verbindingen op en belast ze allemaal met veel data. Laat de ping doorlopen.

Probeer ook eens of je packetloss hebt naar bijvoorbeeld tweakers.net en bijvoorbeeld php.com. Zoja, dan is het probleem tussen ergens tussen je pc en je internet provider.

[ Voor 6% gewijzigd door Verwijderd op 19-05-2003 12:35 ]

[Stacium]

GrimaceODespair schreef op 19 May 2003 @ 12:28:
Tijdens "ls -R /" schiet de packet loss niet omhoog (1 keer 3% geregistreerd, maar nou al een paar keer 0 op een stuk of 50 pings).

Ik denk dat ik de impact van packet loss nog niet helemaal goed kan inschatten. Is het niet zo dat de meeste protocollen dit kunnen opvangen door een re-request (bv: de sockets zelf al, vandaar TCP ipv UDP)? Of maak ik nou een denkfout?

tcp heeft ACK-support
udp niet

[GrimaceODespair]

Heb ff vier consoles simultaan een recursive dir laten doen:

code:

46 packets transmitted, 45 packets received, 2% packet loss
round-trip min/avg/max = 12.1/19.5/126.7 ms

De packet loss blijft constant, maar DeLaNo geeft al aan dat packet loss sowieso niet normaal is rond deze tijd. Ik zit in Maastricht en de server staat in Hoofddorp, allebei Nederland, dus daar verwacht je normaal ook niet teveel problemen.

Als ik de pings maar lang genoeg laat draaien, blijft ie naar T.net rond de 1% hangen, maar naar php.com heb ik 0% (na 240 packets).

Ik heb ook maar eens een traceroute gedaan, en de grootste delay ligt tussen onze proxy en de kabelprovider (ik weet ff niet meer welke ), maar de rest hopt netjes over widexs naar onze server toe.

Ik ga dit probleem ff loslaten, want ik heb nu dringender werkzaamheden. Ik kick het wel als ik er weer aan kan gaan zitten. Bedankt voor de hulp iig.

[Sir Isaac]

Als je je putty echt hard wilt laten werken moet je misschien eens een groot bestand uploaden of downloaden met sftp of scp. Kijk eens wat er dan met je packetloss percentage gebeurt.