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 <[EMAIL PROTECTED]> 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
