D. Kriesel wrote:
Hi maarten,
Some questions to help myself (and the list) helping:
1) Which file systems on source and target did you use before and after the
server change? Which other ones did you try?
2) What kind of data do you have? Millions of dirs with millions of small
files
On 12/21/10 18:44, Randy Syring wrote:
Did you do testing on the local machine only ( i.e. do tests from one
folder to another)? Doing comparisons on the older server and then the
new server should show you if its just the server to blaim. If that
proves solid, then I would look at network
On 12/21/10 21:56, Adrian Klaver wrote:
On 12/21/2010 09:25 AM, Maarten J H van den Berg wrote:
Hi there,
I'm basically out of ideas. I was tearing my hair out over this until a
couple of days ago (yes, well, I'm bald now). I turn to this list as a
last resort. Can anyone help debugging
On 12/21/10 18:51, Jakob Unterwurzacher wrote:
What about the kernel version? Probably barriers are now working as they
should and you pay the price for that. dpkg package management had huge
performance regressions due to this AFAIR.
Googled a bit on that but I'm left confused: are you
Am 22.12.2010 15:02, schrieb Maarten J H van den Berg:
On 12/21/10 18:51, Jakob Unterwurzacher wrote:
What about the kernel version? Probably barriers are now working as they
should and you pay the price for that. dpkg package management had huge
performance regressions due to this AFAIR.
RE: Severe performance degradation thread
This is a long shot, but I have had issues like this on new servers
with certain RAID hardware, until I forced an initial sync of the RAID
volume. Once the initial sync completed the server performed as
expected.
Best,
Chuck
chuck odonnell wrote:
RE: Severe performance degradation thread
This is a long shot, but I have had issues like this on new servers
with certain RAID hardware, until I forced an initial sync of the RAID
volume. Once the initial sync completed the server performed as
expected.
Are we perhaps
Hi there,
I'm looking for help with a very severe performance problem using
rdiff-backup. Basically we've bought a new server with more and faster
resources to replace a 4-year old one. However, rdiff-backup refuses to
perform on the new server.
Various tests show that generic disk accesses are
Did you do testing on the local machine only ( i.e. do tests from one
folder to another)? Doing comparisons on the older server and then the
new server should show you if its just the server to blaim. If that
proves solid, then I would look at network stuff. Maybe use a different
NIC, etc.
Am 21.12.2010 18:25, schrieb Maarten J H van den Berg:
Hi there,
I'm looking for help with a very severe performance problem using
rdiff-backup. Basically we've bought a new server with more and faster
resources to replace a 4-year old one. However, rdiff-backup refuses to
perform on the
Hi maarten,
Some questions to help myself (and the list) helping:
1) Which file systems on source and target did you use before and after the
server change? Which other ones did you try?
2) What kind of data do you have? Millions of dirs with millions of small files
or millions of files in
On 12/21/2010 09:25 AM, Maarten J H van den Berg wrote:
Hi there,
I'm basically out of ideas. I was tearing my hair out over this until a
couple of days ago (yes, well, I'm bald now). I turn to this list as a
last resort. Can anyone help debugging this strange problem please ?
Regards,
Probably something above 5.
Yeah, please give it a 8 ... maybe then make it a --terminal-verbosity 8 rather
than -v8 so that you don't let the backup-log in the target explode ...
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
13 matches
Mail list logo
