Re: Tail memory and service question

[Bob Proulx]

Sean Mehner wrote:
> I am writing to settle a dispute between myself and a vendor.

In that case I have to insert all of the statements that I am not a
lawyer.  I do not speak for anyone.

> We have been told that our DHCP services suffer when we monitor
> their actions by running a tail -f on the /var/log/messages
> file. The said reason for this being that dhcpd writes to the log
> only as fast as it can write to our screen, and therefore must wait
> based on our connections.

Everything affects everything else.  Therefore there will always be
some affect.  But in this case the effect generally is so small as to
be negligible.  As an engineer I discard the effect as being 3rd or
4th order and insignificant.  If in doubt, measure it the effect and
quantify it.  Real data is always best.

Your DHCP server is running slowly?  Are your clients timing out?  And
since you are referring to /var/log/messages I will assume you are
running on a GNU/Linux machine.  I can't imagine a case where a DHCP
server on linux could not keep up.  Only if the machine was extremely
short of memory and spending all of the time swapping to disk could I
conceive of enough system slowdown to have a noticeable affect on a
DHCP server.  I have a site with several hundred DHCP clients all
served by a slow pentium running a DHCP server on Debian GNU/Linux
with no trouble at all.  The syslog is idle most of the time so
tail'ing it has zero affect on the system load.  The tail program with
an idle syslog spends most of its time sleeping.

Or instead are you saying that your linux machine is trying to DHCP
the client network configuration and timing out because the remote
server is too slow?  This must be the case since you are talking about
a vendor.  And the vendor of the DHCP server software is saying that
you on your client tail'ing the syslog file is dragging down their
server?  I find that a completely unreasonable hypothesis.

You might want to run 'tcpdump' on the network and track the packets
flowing back and forth.  Track an individual transaction and see how
long it takes your server to respond to it.  The 'ethereal' program
may be of help analyzing and displaying the tcpdump data.  I highly
recommend those two programs.

> I find this description a little out there, and would like to verify
> if possible if it is at all true.

Trust.  But verify!  :-) Following the old proverb "a fool and their
money are soon parted" it is better to never call someone a fool.
Instead, sell them something.

But let's talk about the specific problem you asked about.  While
sending characters to your screen the system as a whole will need to
do that processing.  Therefore if you are spewing information at a
*fast* pace it will consume more cpu time than if you do not.  Which
hopefully makes sense, right?  The system as a whole will have more
load upon it.  Is that a significant load?  Not usually.  Is the same
host running X windows and needing to update the display for those
characters being moved?  If so then the X11 window updating can
consume significant time.  But if you were logged in with a character
terminal the display would be elsewhere.

Let me channel the persona of Sherlock Holmes.  How much data could be
spewing to your screen?  If it was overwhelming then you would not be
able to read it and eventually you would stop because it would not be
useful.  The very fact that it is useful to you means that I can
deduce that the pace is slow enough to read most of the time.  If it
is slow enough for a human to read then it is slow enough not to slow
the system significantly.  QED.  The syslog is probably idle for most
of the time with sporadic spurts of data logged to it.  A tail -f on
the file would spend most of the time sleeping waiting for more data.

The tail program documents this:

  `--sleep-interval=N'
       Change the number of seconds to wait between iterations (the
       default is 1).  During one iteration, every specified file is
       checked to see if it has changed size.

Therefore if you were to suspect that it were tail is actually
consuming significant time stat'ing files you could increase the sleep
interval between file stats.

> My stance is that tail should be checking the end of a file and
> writing to the screen. Each action seperate from the system logging
> dhcpd messages.

Yes.  Those are completely separate processes and unrelated to each
other.  Running tail cannot in any way directly affect the running
daemon process which is logging to the file you are looking it.  In
fact coming through syslog you are two processes removed.  The DHCP
daemon (client? server?) is logging to syslogd.  The syslog process is
logging to the file.  You are tail'ing the file.  You are twice
removed from the original process.  Of course removed once is enough.
But perhaps that will give you a counter to their statement.

> Also, if you know off hand how much memory something like this might
> take up I would appreciate it. I have looked both when running tail
> -f and when not running it, and don't see a difference.

The 'tail' program is in a loop and in steady state at the time you
are tailing your file.  It won't consume any additional memory in this
case.  Whatever it is using is what it will continue to use.  On my
machine running a stock 2.4.18 kernel with glibc 2.2.5, tail consumes
316 pages of memory and whenever I look it is in the kernel nanosleep
routine.

  ps -el | awk '/SZ/||/tail/{print}'
    F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
  000 S  1000 10829   965  0  69   0 -   316 nanosl pts/6    00:00:00 tail

Bob

-- 
Please follow up to the mailing list.  Replying to me privately is
fine if it is personal.