Forgot to answer this earlier, I think...
If you can't kill sendsize, it's because it is hang in a system call.
It's often when it try to access a mount point.
Do you have a hanged mount point?
But yes, you are absolutely right. The host in question had problems
with an NFS mount. I didn't
A few days ago I had some backup problems that turned out to be caused
by a hanging NFS mount, causing sendsize to lock up completely - see a
separate post on this. Now I have sorted out this problem, and it seemed
like amdump would once again start properly, but it turns out that the
backup
A few days ago I had some backup problems that turned out to be caused
by a hanging NFS mount, causing sendsize to lock up completely - see
a separate post on this. Now I have sorted out this problem, and it
seemed like amdump would once again start properly, but it turns out
that the backup
Hello list,
I have been working on a performance problem for about a month and I am
out of ideas. I hope someone can help me. What is happening is that
backups of large DLE that start very early seem to dump at a very slow
rate. Where as dumps of DLE on the same host, physical drive, etc. that
On Wed, 7 Mar 2007 at 9:58am, Kenneth Berry wrote
I have been working on a performance problem for about a month and I am
out of ideas. I hope someone can help me. What is happening is that
backups of large DLE that start very early seem to dump at a very slow
rate. Where as dumps of DLE on
Thank you for the tip on columnspec, I was about to create another post
on that problem.
The computer mbthome is both the amanda server and client, it is a Dell
PE2650 dual Xeon processor, 2GB Ram. Tape unit is LTO3 on a dedicated
SCSI controller. Internal HDD's are four SCSI ultra320 10K
On Wed, Mar 07, 2007 at 09:58:09AM -0600, Kenneth Berry wrote:
Hello list,
I have been working on a performance problem for about a month and I am
out of ideas. I hope someone can help me. What is happening is that
backups of large DLE that start very early seem to dump at a very slow
On Wed, 7 Mar 2007 at 11:45am, Kenneth Berry wrote
The computer mbthome is both the amanda server and client, it is a Dell
PE2650 dual Xeon processor, 2GB Ram. Tape unit is LTO3 on a dedicated
SCSI controller. Internal HDD's are four SCSI ultra320 10K configured
as hardware RAID5. On top of
I'm sorry to interject without having read the complete thread but
I wanted to share (remind of previous emails) that I had a problem
with my LTO on Solaris a while back. Turned out the HBA card was
failing, the A side was dropping in performance with no additional/errors
noticable which the B
Thanks for all the great ideas. I have some comments and questions.
From Gene's message:
The dump's are not going straight to tape which really does slow things
down. One of the way I can tell is that the final DLE dump that has been
running since midnight is spooling to disk and the tape is
On Wed, 7 Mar 2007 at 2:30pm, Kenneth Berry wrote
---Sequential Output ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %
CPU /sec %CPU
Here are the corrected bonnie++ results.
1.)
Below are bonnie results on mbthome:/home/public this is on a percraid
controller handled as a single 300GB HDD with LVM allocating the space
to the following filesystems /home, /home/public/,
and /home/public/Ausk... The dump rate last night for this
In my case the machine which works as an Amanda backup
server itself is backed up by Amanda. So which are the
important files/directories (index and config
files/directories or any other important files) that I
should save on some other machine, so that I can
recover data from the Amanda
Has anyone seen this kind of result from an amstatus? (amanda.conf and
disklist to follow)
[EMAIL PROTECTED]:~$ amstatus Daily
Using /var/log/amanda/Daily/amdump from Wed Mar 7 23:18:01 EST 2007
Use of uninitialized value in hash element at /usr/sbin/amstatus line 520,
AMDUMP line 2777.
Use of
On 3/7/07, Stefan G. Weichinger [EMAIL PROTECTED] wrote:
FL schrieb:
On 3/6/07, *Stefan G. Weichinger* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Glad that thinks worked out. Might be a nice thing to write as small
udev-related subsection for the HOWTOs ...
Greets, Stefan.
Maybe
15 matches
Mail list logo
