ftp Performance poor when syslogd turned on

[William Tidwell]

We had a switch go bad and create a broadcast storm. Following that the syslog daemons on most machines were down. All came up but on one machine ftp performance is now very slow, especially on login. It can easily take up to a minute to get logged in, with syslogd turned off, no problem. This is an rp4440 running HP/UX 11.11.

[Tim Nelson]

99% of the time slow login is due to DNS lookups to log the connection.

Check to see that your DNS is resolving from that server. Turn off DNS and try, turn it back on to test again ( edit /etc/resolv.conf ).

[William Tidwell]

That's true enough about DNS, but it's not the problem in this case. FTP by IP address is just as bad. However it's strange. I turned system logging back on to perform some tests and now it's working normally. Wish I knew what it was.

[William Tidwell]

Back to poor performance again. Turn off the syslog and performance picks right up.

[Tim Nelson]

Have you got a million messages going into syslog ?

[William Tidwell]

No, fairly light. The ftp daemon has the -d switch so it shows the files uploaded. But all in all maybe 2 or 3 messages a minute.

[Tim Nelson]

And no such slow login with telnet or anything else ?

[William Tidwell]

No everything else is fine. It's very strange indeed.

[Tim Nelson]

You mentioned a -d option with your ftpd, what ftpd are you using, I do not see a -d option with the HPUX ftpd.

[William Tidwell]

My mistake, it's configured like such, ftp stream tcp nowait root /usr/lbin/ftpd ftpd -p -l -v -a -u 022

Too many switches to keep track of

[Steven Schweda]

> That's true enough about DNS, but it's not
> the problem in this case. FTP by IP address
> is just as bad. [...]

If the problem is with DNS, it may have
nothing to do with how you specify the FTP
server to the client program, and everything
to do with whether the FTP server can do a
reverse look-up on the IP address of the
client system.

I know nothing, but if the FTP server _is_
doing a reverse look-up so that it can make
nicely formatted messages for its log(s),
then it's possible that it doesn't bother if
it can't talk to the logger. If that were
true, it might explain how a change in the
logging could affect things his way.

In any case, I'd try an nslookup of the
client's IP address on the server. If it
works (properly/quickly), then the problem
probably is unrelated to DNS, but without
running that test, I'd say that it's too soon
to rule out a DNS problem.

In any case, I'd expect a DNS problem to have
no serious effect after the log-in sequence,
so if things stay bad after that, I, too,
would look elsewhere.