Re: [Nssbackup-team] [Question #116342]: tar takes a long time, 100% CPU, with no output

2010-07-03 Thread B.J. Herbison
Question #116342 on NSsbackup changed:
https://answers.launchpad.net/nssbackup/+question/116342

Status: Answered = Open

B.J. Herbison is still having a problem:
Thank you for the response. I appreciate that you did not write and do
not maintain tar, but I hope you have insight into how nssbackup is
using tar.

I don't have insight into the NAS device, but a simple two window
experiment with cat and ls -l showed that writing to a file shows up in
the file size before the file is closed so it appears that the backup
process is hung before gzip has enough data to start writing to disk.

Looking at top, tar is taking 100% of a CPU and gzip 0%. Looking at ps,
tar has over nine minutes of CPU time in ten minutes, gzip still shows
up at 0:00.  There was a burst of network traffic at the backup start
(writing the nine files relating to the backup) but the network traffic
has been under 4 KiB/s since then.  I did not catch the start of the
backup with iotop, but I never saw the tar process on the list.  (I
should have read the man page and used iotop -o or pressed o before
the backup started.)

Do you have any suggestions for what I could try next?

I remember tar having some problems with long file names quite a while
ago (over a decade) but I don't remember the symptoms -- and I don't
remember doing anything strange that would add unusually long file names
between when the backups worked and when they stopped.

(By the way, do the old nssback.date.log files left by a failed run
get cleaned up automatically at some point or will I need to clean them
up manually when this issue gets resolved?)

Thank you for your help with this problem.

You received this question notification because you are a member of
NSsbackup team, which is an answer contact for NSsbackup.

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp


Re: [Nssbackup-team] [Question #116342]: tar takes a long time, 100% CPU, with no output

2010-07-02 Thread Anton Feenstra

On 01/07/10 12:49, B.J. Herbison wrote:

Question #116342 on NSsbackup changed:
https://answers.launchpad.net/nssbackup/+question/116342

B.J. Herbison gave more information on the question:
Additional information: The target device is a mounted network drive,
but it is available with over 1TB free. The backup created nine files in
the target directory so it is writable.  Nothing looks unusual in the
log file, the last line talks about invoking tar.


To answer your previous questions, yes in most systems you should expect 
the filesize to grow as tar produces its output. In some cases, however 
the filesize may not be updated, e.g. over nfs on some systems. Do you 
have direct access to the server on which your network drive resides? 
There, certainly, filesize must be up to date and thus should be growing.


Other ways to monitor tar is by 'top'; you should normally see 
alternating activity of tar (collecting and reading files) and gzip 
(compressing tar's output on the fly). In addition, your network monitor 
should register outgoing data. Finally, using 'iotop', you should be 
able to monitor disk io of the tar process reading files.


Collecting this information should give more clues about where the error 
originates. Could you report back to us with that?



--
Groetjes,

Anton
 _ ___
| |   |
|  _   _  ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University  Amsterdam |
|(   |   )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands  |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | feens...@few.vu.nl - www.few.vu.nl/~feenstra/ |
| | Just a Minute While I Reinvent Myself (Red Hot  |
| | Chili Peppers)|
|_|___|

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp


Re: [Nssbackup-team] [Question #116342]: tar takes a long time, 100% CPU, with no output

2010-07-02 Thread Anton
Question #116342 on NSsbackup changed:
https://answers.launchpad.net/nssbackup/+question/116342

Status: Open = Answered

Anton proposed the following answer:
On 01/07/10 12:49, B.J. Herbison wrote:
 Question #116342 on NSsbackup changed:
 https://answers.launchpad.net/nssbackup/+question/116342

 B.J. Herbison gave more information on the question:
 Additional information: The target device is a mounted network drive,
 but it is available with over 1TB free. The backup created nine files in
 the target directory so it is writable.  Nothing looks unusual in the
 log file, the last line talks about invoking tar.

To answer your previous questions, yes in most systems you should expect 
the filesize to grow as tar produces its output. In some cases, however 
the filesize may not be updated, e.g. over nfs on some systems. Do you 
have direct access to the server on which your network drive resides? 
There, certainly, filesize must be up to date and thus should be growing.

Other ways to monitor tar is by 'top'; you should normally see 
alternating activity of tar (collecting and reading files) and gzip 
(compressing tar's output on the fly). In addition, your network monitor 
should register outgoing data. Finally, using 'iotop', you should be 
able to monitor disk io of the tar process reading files.

Collecting this information should give more clues about where the error 
originates. Could you report back to us with that?


-- 
Groetjes,

Anton
  _ ___
| |   |
|  _   _  ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University  Amsterdam |
|(   |   )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands  |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | feens...@few.vu.nl - www.few.vu.nl/~feenstra/ |
| | Just a Minute While I Reinvent Myself (Red Hot  |
| | Chili Peppers)|
|_|___|

You received this question notification because you are a member of
NSsbackup team, which is an answer contact for NSsbackup.

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp


[Nssbackup-team] [Question #116342]: tar takes a long time, 100% CPU, with no output

2010-07-01 Thread B.J. Herbison
New question #116342 on NSsbackup:
https://answers.launchpad.net/nssbackup/+question/116342

This morning my backups are taking a long time, how can I tell what tar is 
doing?

Previous incremental backups have taken up to 10 minutes, full backups up to 20 
minutes (fairly new system and I haven't move most of my files onto the system 
yet).

This morning the first incremental ran for almost an hour until I killed it. 
The tar process was using 100% of a CPU, and the files.tar.gz was still zero 
bytes long.  I restarted it, and the tar process has 24 minutes of CPU time 
with no recorded output.

Question 1: Should I expect to see the tar file have zero bytes until the end, 
or should I see the file size increase as it goes?

Question 2: How can I debug this?  Is there a way to get debug output from tar 
as run from nssbackup 0.2.1?

-- 
You received this question notification because you are a member of
NSsbackup team, which is an answer contact for NSsbackup.

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp


Re: [Nssbackup-team] [Question #116342]: tar takes a long time, 100% CPU, with no output

2010-07-01 Thread B.J. Herbison
Question #116342 on NSsbackup changed:
https://answers.launchpad.net/nssbackup/+question/116342

B.J. Herbison gave more information on the question:
Additional information: The target device is a mounted network drive,
but it is available with over 1TB free. The backup created nine files in
the target directory so it is writable.  Nothing looks unusual in the
log file, the last line talks about invoking tar.

-- 
You received this question notification because you are a member of
NSsbackup team, which is an answer contact for NSsbackup.

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp