login process takes long time

[Fernando Acevedo]

this is the result of the traceroute, after I press enter the traceroute command takes several seconds to start, but once started it only show this information inmediatly.

traceroute xx.xx.x.xxx
traceroute to xx.xx.x.xxx (xx.xx.x.xxx), 30 hops max, 20 byte packets
1 xx.xx.x.xxx (xx.xx.x.xxx) 1 ms 1 ms 0 ms

[Mark Greene_1]

Great. Now take the IP address from this line:

traceroute to xx.xx.x.xxx (xx.xx.x.xxx), 30 hops max, 20 byte packets


and talk to your network admin about what changes they made to it recently. In fact, maybe show them the whole traceroute output to ensure that the results are what they would have expected.

[Fernando Acevedo]

I did the sema traceroute from two servers working perfectly and the result is very similar.

ONE SERVER WORKING PERFECTLY
traceroute to xx.xx.x.xxx (xx.xx.x.xxx), 30 hops max, 20 byte packets
1 xx.xx.x.xxx (xx.xx.x.xxx) 0 ms 0 ms 0 ms

OTHER SERVER WORKING PERFECTLY
traceroute to xx.xx.x.xxx (xx.xx.x.xxx), 30 hops max, 40 byte packets
1 xx.xx.x.xxx (xx.xx.x.xxx) 0.252 ms 0.213 ms 0.149 ms

So I don't think that info show something important, the only difference as I said before is that in the server having problems the traceroute takes several seconds to start working.

[Patrick Wallek]

Is this server overworked? What is the CPU load like? What about memory usage? Any page-outs?

If the server is overworked, it is possible that you could have login issues as a result.

If you have glance, run it and check the CPU usage and RAM usage. Also run 'swapinfo -tam' and see if any of your swap areas have significant usage.

[Fernando Acevedo]

Hi Patrick: looks like the server is very relaxed. this is the output of te top

CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.05 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
1 0.14 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
2 0.00 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 0.06 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%

AND THE SWAPINFO COMMAND SHOWS ALL THE SWAP MEMORY FREE.

[Mark Greene_1]

ok, let's check for network errors. Run netstat -s|pg and look for the numbers for these lines:

TCP:
completely duplicate packets
packets with some dup, data
out of order packets
packets ( bytes) of data after window
packets received after close
segments discarded for bad checksum

embryonic connections dropped
retransmit timeouts
persist timeouts
keepalive timeouts

What's important here is not so much how big the numbers are, but how they compare with the number from the line:

packets received

and the second group above compare to the number in this line:

connections established

if any of the numbers of the errors are 50% or greater of the number of packets received or connections established, you could simply have a bad LAN card.

mark

[Fernando Acevedo]

thanks mark but everything looks fine here, however I don't see the second group of errors, this is the output:

2197033 packets sent
2114758 data packets (1696960111 bytes)
749 data packets (370299 bytes) retransmitted
65927 ack-only packets (52642 delayed)
0 URG only packets
0 window probe packets
5692 window update packets
9907 control packets
1575646 packets received
751515 acks (for 145645216 bytes)
2751 duplicate acks
0 acks for unsent data
567368 packets (23756251 bytes) received in-sequence
249 completely duplicate packets (863 bytes)
185 packets with some dup. data (578 bytes duped)
2235 out-of-order packets (63 bytes)
0 packets (0 bytes) of data after window
0 window probes
1436 window update packets
1 packet received after close
0 discarded for bad checksums
0 discarded for bad header offset fields

[Fernando Acevedo]

sorry, I haven't seen the whole output, anyway, I don't see many erros at all.