3 - 5 second delay servicing requests with RH9

[mapman42]

Hopefully someone has seen this issue before and can shed some light on it for me. I have a RH9 server installation (previously RH8 with same issue) that is experiencing a 3 to 5 second delay before servicing requests over the lan or wan, though NO delay over the loopback or localhost. For instance, an ftp request pauses after authentication 3-5 seconds and then either uploads or downloads without any further delays-- the same holds true with a pop3s session. Http requests are particularly exasperating because the pause seems directly related to the elements on the page. A three element page with a 45k .jpg loads completely in 7 seconds, the same page with a 600k .jpg also takes 7 seconds. A page with 20 5k .jpg's takes nearly 60 seconds.

I tried a crossover cable to rule out router and cable issues, also replaced the nics with no improvement. The system itself is barely even coasting. It is an Intel 2.4 gig with a gig of ram. It barely hits 2% active on the cpu with 600 meg of free ram. Somebody PLEASE help.

Below are the stats on the interface. I thought for a moment it might be an old routing table but except for a network that I can't identify (169.254.0.0) that, after deletion, shows up again after a re-boot, everything seems normal. The router's IP is 192.168.1.1 and eth0 is 192.168.1.113.

[root@oregon etc]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:20:78:12:68:AB
inet addr:192.168.1.113 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48445 errors:0 dropped:0 overruns:0 frame:0
TX packets:34039 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:59254881 (56.5 Mb) TX bytes:11452899 (10.9 Mb)
Interrupt:3 Base address:0xe000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:164837 errors:0 dropped:0 overruns:0 frame:0
TX packets:164837 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:29063232 (27.7 Mb) TX bytes:29063232 (27.7 Mb)


[root@oregon etc]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default router 0.0.0.0 UG 0 0 0 eth0
[root@oregon etc]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

 

[sleipnir214]

What FTP server are you running?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[rburke]

One thing I find odd about your situations is the large amount of traffic that is being put through your loopback interface. I have server Red Hat servers and under normal usage the loopback interface has *maybe* a few hundred kilobytes, not Mb passed through it. But from your stats it looks like there is half the amount of eth0 traffic in the loopback. Do you hav anything that would be using the loopback on this machine??

Burke

 

[mapman42]

To answer the questions...

I've been using the loopback address for speed comparisons with the other machines on the local net recently, that may be why traffic is so heavy on that address. With the loopback address, there isn't the latency (pause) that is so frustrating with connections utilizing eth0.

The ftp daemon I'm using is wuftpd. It is set up to only be available on the local lan. Httpd and pop3/pop3s/imap services are available over the wan.

 

[LedZepRock]

I had a problem like this, and it was DNS lookups that made the problem. Is DNS working, can you do a NSLOOKUP???

I had bloked DNS through my firewall between 2 subnets, so as I let it through (UDP 53 both directions) it was fine.

Ta

 

[mapman42]

Hmmmm. That wasn't exactly it, but it gave me some ideas. By the way, the problem is resolved!
I'm not running a dns server locally, but instead relying on the comcast dns via my router and cable modem. Since the dns of my server is dynamic, I use the dynadns and zoneedit servers to keep the world up-to-date with me.
It turned out that the primary dns server that was in the eth0 configuration is no longer in service and hasn't been for a year or so now. So all dns requests were first timing out on that server before hitting the secondary dns. It is amazing how many things use that. The improvement was instant and dramatic. Thanks to all of you that provided input to my question, and I hope this will help someone in the future.