nagyon hosszú reakció idő

Hálózatok általános

Adva van egy 550 MHz P3 -as gép. Benne két hálókártya, négy soros port. Semmi X, és az ntp -n kívül semmilyen "szokásos" szerver folyamat.
Fut rajta azonban összesen 6 példány, általam írott program, amely a soros portokon és a második hálókártyára csatlakozó eszközökkel kommunikál. Mindegyik program a belső hálózat felé az általuk kezelt "portot" ugyanabba a multicast csatornába, a 224.0.0.10 címre küldik, illetve azon fogadják a nekik szóló üzeneteket. (Minden program reuse address -t használ).
Az egyetlen probléma, hogy az ssh kb. 20 másodpercig nem reagál - azaz a kapcsolat kezdeményezés után ck 20 sec mire kéri a jelszót.
Mindemellett az uptime csupa 0.
Ha elkindítom a top -ot, akkor néha beütésszerüen, a másik hálókártyával kommunikáló program CPU 0.3 % felhasználást jelez de a csúcson leginkább a top maga helyezkedik el.
Hogy lehetne a reakció időt javítani?

  • 1587 megtekintés

( ruczati | 2008. 07. 14., h – 20:44 )

ez az ssh nem reagal csak kb 20 mp mulva ez tipikusan valami dns mellekonfiguralas eredmenye szokott lenni...

+1
Gondolom a tipikus reverse dns gondokra gondolt, de a szituáció szerint nem valószínű. Hasonló jelenséggel találkoztam én is belső hálón - idő és nyomozás hiányában switchelések környékére tippeltem, mivel kívülről ugyanezen szolgáltatás sokkal gyorsabban bejön.

+1 ez a megoldás!

nekem hasonló volt!

ssh -v is segített!!

ha jól emlékszem a /etc/ssh/ssh_config állományban kikommenteztem a # GSSAPIAuthentication yes 


GSSAPIDelegateCredentials no 
GSSAPIAuthentication yes

sorokat

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Ha visszateszem a gateway -t akkor megint lelassul. It reked meg:
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/tovis/.ssh/identity ((nil))
debug2: key: /home/tovis/.ssh/id_rsa (0x8096470)
debug2: key: /home/tovis/.ssh/id_dsa ((nil))
--- itt hosszan vár!? ---
debug3: start over,passed a different lst publickey, password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey

Hát ezen nemigen igazodok el - nem érzem magam okosabbnak. Mi köze az authentikációnak a gateway -hez?

* Én egy indián vagyok. Minden indián hazudik.

Meglepő módon nálunk lehet hogy mégis van köze dns-hez - el is kezdtem nyúzni DTrace-el, de idő hiányában megakadt a project. Ettől függetlenül én is köszönöm a tippeket, vv-vel még nem próbáltam bár ismertem a trükköt.
Egyébként van a Sun oldalán egy "iskolapélda" ssh-lassúság nyomozáshoz a DTrace használatára.

Mit lehet használni a DTrace helyett - Debian Etch.
Van még egy ilyen belassuló dolog, amennyiben, nincs internet kapcsolat az Exim4 is hosszú másodpercekig vár valamire, tekintetnélkül arra hogy csak lokális továbbítás/levelezés van. Erre még nem próbáltam "letiltani" a gateway -t.

* Én egy indián vagyok. Minden indián hazudik.

( Darkfish | 2008. 07. 14., h – 20:48 )

Ha egyébként nincs a gép netre kötve, akkor töröld a default gatewayt.

Hihetetlen :) 2 sec alá ment!!!
Nem hiszem el ...
Az adott interfész egyben a multicast szoró is, lehet hogy a kettő összefügg?
Viszont nyomozgatás közben, ugyan ezen az interfészen, azt találtam, hogy RX packets: 3918253 errors:6432
végül vett 539.0 MiB és adott 2.9 GiB
Az uptime 67 nap.
Elég furcsa, lehet hogy itt valami más baj is van, ez az interfész a belső LAN -ra néz azaz egy 10/100 Mbit switch és a többiek, a vétel mindössze a hatoda az adott csomagoknak.

* Én egy indián vagyok. Minden indián hazudik.