The two sessions you see starting up initially are probably the thread that
queries the server, and the thread that starts searching the filesystems.


=> On Sat, 16 Mar 2002 11:33:15 +1100, John Nawotka <john AT computerguy.com 
DOT au> said:

> We have one node that for some reason has started taking a lot longer to
> complete its backup than any of the other similar nodes.
> [...]
> 03/12/02   07:29:27 ANS1898I ***** Processed 1,180,000 files *****

While not extremely large, this is a decent number of files.  Depending on the
disk technology and the arrangement of the files, evaluating this many could
be a Big Deal.

I once had to deal with a directory structure of the form:

/some/path/[00-99]/[00-99]/[00-99]/

That's 100 directories, with 100 subdirectories, with 100 subdirectories.

1,010,100 directories.  And some files in there too. (usually fewer than the
number of directories)

This was on rather slow disk tech (Raid-5 4.5G drives) and it could take many
hours to run an incremental, even though the change rate on these filesystems
was very very low.

... Anyway, we had similar symptoms.  Once the client downloaded all its
information for the incremental, it chugged along for a -LONG- time without
having anything else to say to the server.  Once it came up with something, a
reconnect was indicated.

So the hiatus is not surprising or unusual.  What you ought to do is take a
look in the scheduler log, and see if you can figure out what filesystem takes
the majority of the time.  Once you've done that, poke around.  There's a good
chance you'll find a single directory with 300,000 files, or some such
frightening thing.

Once you've found it, find the person who's responsible, and give them a
talking to. ;)


Allen S. Rout