PDA

Bekijk Volledige Versie : ssh en webserver veel te traag



timmy
15/02/08, 04:54
SSh en de webserver zijn veel te traag
ongeveer zo'n 25 seconden wachten voordat ik
ben ingelogd

Ik heb dit probleem al eens eerder gehad
en toen lag het aan DNS resolving.

Echter de log files /var/logs/secure en messages
staat niets vreemds in (ssh schrijft in deze 2 files zijn logs)

een ssh verbinding met een andere server op een
ander netwerk is snel...
dus ligt het niet aan mijn provider.
en moet het wel aan mijn server / netwerk liggen.

iemand suggestie's?
cheerz
TIm

SDGM
15/02/08, 08:00
Misschien heel voor de hand liggend maar heb je al es naar de load van de machine gekeken? Is alles traag of is het specifiek de webserver en ssh?

Het eerste waar ik bij ssh aan denk is inderdaad dns resolving, dit heb je nu uitgeschakeld of hoe heb je dit de vorige keer opgelost?

VinceSTM
15/02/08, 08:24
Ook apache schrijft in zn logs de rDNS van de aanvrager, dus ik denk ook dat het aan de resolver ligt... Wat is de inhoud van je:


/etc/resolv.conf
?

Daarnaast: /var/logs? niet /var/log?

timmy
16/02/08, 05:38
hoe ik het de vorige keer heb opgelost
weet ik niet meer :S (ik word een dagje ouder)

in de resolv.conf staat zoiets als dit:
nameserver 96.84.xxx.xx
nameserver 96.84.xxx.xx
nameserver 96.96.xxx.xx

dat zijn de IP's van mijn hosting provider.

en euh..ja het is
/var/log/

excuses.

Kenneth
16/02/08, 10:40
check de dns servers dmv nslookup hoe snel ze reageren

VinceSTM
16/02/08, 10:45
doe eens


dig

Xolphin
16/02/08, 11:56
hoe ik het de vorige keer heb opgelost
weet ik niet meer :S (ik word een dagje ouder)

Gebruik dan de zoekfunctie :)

http://www.webhostingtalk.nl/netwerktechnologie/127245-verbinding-met-ssh-butt.html#post911008

timmy
16/02/08, 12:25
met dig krijg ik dit:

; <<>> DiG 9.2.4 <<>>
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6037
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.

;; Query time: 16 msec



met nslookup dit:
> nslookup [dns.ip]
Server: [dns.ip]
Address: [dns.ip]#53

Non-authoritative answer:
[een_ander.ip].in-addr.arpa name = rr1.mijn.hoster.nl.

Authoritative answers can be found from:

Sorcer
16/02/08, 12:25
Vraag me af of eventueel de firewall dit probleem niet veroorzaakt. Hier al na gekeken? Succes!

timmy
17/02/08, 03:23
er draait geen firewall op de server

Xolphin
17/02/08, 13:10
@timmy:
Als je zoals in de andere thread die je over dit onderwerp hebt gemaakt staat, nou even 'ssh -v' in plaats van 'ssh' doet, dan kun je zien wat er gebeurd, en zie je ook waar het mis gaat.

@VinceSTM:
Wat heb je aan alleen "dig" dan?

timmy
19/02/08, 04:45
heb de output met Winscp gedaan
omdat ik niet weet hoe dat met Putty moet.

trouwens... niet alleen de SSH is traag maar ook de webserver
dus ik vraag mij af of dit de juiste weg is.

Hoedan ook, de output:

--------------------------------------------------------------------------
Session name: jantje
Host name: [ip] (Port: 69)
User name: admin (Password: Yes, Key file: No)
Transfer Protocol: SFTP (SCP)
SSH protocol version: 2; Compression: No
Agent forwarding: No; TIS/CryptoCard: No; KI: Yes; GSSAPI: No
Ciphers: aes,blowfish,3des,WARN,des; Ssh2DES: No
Ping type: -, Ping interval: 30 sec; Timeout: 30 sec
SSH Bugs: -,-,-,-,-,-,-,-,
Proxy: none
Return code variable: Autodetect; Lookup user groups: Yes
Shell: default, EOL: 0
Local directory: default, Remote directory: home, Update: No, Cache: Yes
Cache directory changes: Yes, Permanent: Yes
Clear aliases: Yes, Unset nat.vars: Yes, Resolve symlinks: Yes
Alias LS: No, Ign LS warn: Yes, Scp1 Comp: No
--------------------------------------------------------------------------
Looking up host "[ip]"
Connecting to [ip] port 69
Server version: SSH-1.99-OpenSSH_3.9p1
We claim version: SSH-2.0-WinSCP-release-3.6.8
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-rsa 1024 [....]
Initialised AES-256 client->server encryption
Initialised AES-256 server->client encryption
Using username "admin".
Session password prompt (admin@[ip]'s password: )
Using stored password.
Sent password
Access granted
Opened channel for session
Started a shell/command
--------------------------------------------------------------------------
Using SFTP protocol.
Doing startup conversation with host.
Type: SSH_FXP_INIT, Size: 5, Number: -1
Type: SSH_FXP_VERSION, Size: 5, Number: -1
SFTP version 3 negotiated.
Type: SSH_FXP_EXTENDED, Size: 38, Number: 200
Type: SSH_FXP_STATUS, Size: 38, Number: 200
Status/error code: 8
Server does not recognise WinSCP.
Getting current directory name.
Getting real path for '.'
Type: SSH_FXP_REALPATH, Size: 10, Number: 528
Type: SSH_FXP_NAME, Size: 23, Number: 528
Real path is '/'
Listing directory "/".
Type: SSH_FXP_OPENDIR, Size: 10, Number: 779
Type: SSH_FXP_HANDLE, Size: 13, Number: 779
Type: SSH_FXP_READDIR, Size: 13, Number: 1036
Type: SSH_FXP_NAME, Size: 2733, Number: 1036
Type: SSH_FXP_READDIR, Size: 13, Number: 1292
Type: SSH_FXP_STATUS, Size: 28, Number: 1292
Status/error code: 1
Type: SSH_FXP_CLOSE, Size: 13, Number: 1540
Type: SSH_FXP_STATUS, Size: 24, Number: 1540
Status/error code: 0
Startup conversation with host finished.

VinceSTM
19/02/08, 07:01
@timmy:
Als je zoals in de andere thread die je over dit onderwerp hebt gemaakt staat, nou even 'ssh -v' in plaats van 'ssh' doet, dan kun je zien wat er gebeurd, en zie je ook waar het mis gaat.

@VinceSTM:
Wat heb je aan alleen "dig" dan?

Als er een timeout plaatsvind bij de nameserver, of op het randje hangt, zou dat een oorzaak kunnen zijn. NS Lookup heeft een veel langere timeout voor lookups dan bijv. applicaties :)

timmy
19/02/08, 11:15
dus TTL wijzigen dan?