]
Subject:Re: Speed problem
Classification:
On Wed, 13 Nov 2002 [EMAIL PROTECTED] wrote:
I agree, rsh as root is bad. I wouldn't suggest that. I'm talking
about
running rsync --daemon, using /etc/rsyncd.conf to control the form of
the access. It's pretty good
On Thu, Nov 14, 2002 at 09:44:45PM +1100, Donovan Baarda wrote:
On Wed, Nov 13, 2002 at 02:17:28AM -0800, jw schultz wrote:
While the receiver bears the brunt of the CPU work the
sender is hardly idle. Aside from generating the initial
The reciever _doesn't_ bear the brunt of the CPU
On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote:
Here's one of my setups. It's invoked from inetd.
...
Good luck.
Thank you ! I'll try it, but maybe only from next monday on because
fridays are sometimes hard at work (users crying on fridays
extremely loud, maybe I shouldn't torture them that
On Tue, 12 Nov 2002, Wayne Davison wrote:
On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
And why it tries to get 100% CPU even though there's nothing to do ?
What do you mean nothing to do? Rsync is creating the new version of
a changed file which is done both by
On Wed, Nov 13, 2002 at 10:02:34AM +0100, [EMAIL PROTECTED] wrote:
On Tue, 12 Nov 2002, Wayne Davison wrote:
On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
And why it tries to get 100% CPU even though there's nothing to do ?
What do you mean nothing to do? Rsync is
PROTECTED]
Sent by: [EMAIL PROTECTED]
11/11/02 01:45 PM
Please respond to uwp
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: [EMAIL PROTECTED]
Subject:Re: Speed problem
Classification:
On Mon, 11 Nov 2002 [EMAIL PROTECTED] wrote:
This would
On Tue, Nov 12, 2002 at 07:27:12AM +0100, [EMAIL PROTECTED] wrote:
On Mon, 11 Nov 2002, jw schultz wrote:
What is the CPU load of rsync on the receiver? That is
important.
I'll check that.
The disks have an upper limit of 52 MB/s (ext2) respectively
45 MB/s (ext3). It's an IDE
On Mon, 11 Nov 2002, I've been saying:
But why does it only happen with rsync ?
Ok, the last tests with rsync/rsh have shown the following:
(all on the receiving side)
CPU: 100%
Load: 2.5
blocks in: 38000/s
even though nothing get written
(no statistics)
when it starts to write, it goes from
Ok, now I found something. When the effect of heavy speed drop occurs,
it doesn't seem to send much bytes anymore. Block-in rate on the receiving
side drops dramatically from 31000/s to 5000/every 4-8 seconds (which
results to a rate of nearly 1 MB/s, that's what I got in the end).
CPU load goes
Heya !
It seems that we found it out. It's the partial flag. We tested a lot of stuff
here with strace and could see that after some while there came timeouts
on some descriptors (0 = stdin). We saw that after those timeouts got
heavy the blocks-in-out dropped heavily. But the reason wasn't clear
On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
And why it tries to get 100% CPU even though there's nothing to do ?
What do you mean nothing to do? Rsync is creating the new version of
a changed file which is done both by transferring data over the network
and by copying
At 16:30 11-11-2002 +0100, you wrote:
Mermgfurt !
I have some problem with syncing two machines which are connected
over a Gigabit-connection. I'm trying to use rsync with ssh because of
the authorisation mechanisms (keys). It starts quite ok with 18 MB/s
(this small speed may have something to
I don't have a system with ssh available to check with (believe it or not,
it's not approved for our network), but i think the sshd_config or
ssh_config might be able to specify using compression as a default. Is
ssh on the sending side, perchance, using a lot of CPU? I don't know of
any cpu
On Mon, Nov 11, 2002 at 04:30:05PM +0100, [EMAIL PROTECTED] wrote:
Mermgfurt !
I have some problem with syncing two machines which are connected
over a Gigabit-connection. I'm trying to use rsync with ssh because of
the authorisation mechanisms (keys). It starts quite ok with 18 MB/s
(this
On Mon, 11 Nov 2002 [EMAIL PROTECTED] wrote:
I don't have a system with ssh available to check with (believe it or not,
it's not approved for our network), but i think the sshd_config or
Unbelievable !
ssh_config might be able to specify using compression as a default. Is
ssh on the
On Mon, 11 Nov 2002, jw schultz wrote:
On Mon, Nov 11, 2002 at 04:30:05PM +0100, [EMAIL PROTECTED] wrote:
Mermgfurt !
I have some problem with syncing two machines which are connected
over a Gigabit-connection. I'm trying to use rsync with ssh because of
the authorisation mechanisms
On Mon, 11 Nov 2002 jw schultz wrote:
You haven't really provided enough data to even guess what
is limiting your performance.
As I said in the last mail: One limit for sure is ssh.
But: with arcfour I'm getting 18 MB/s and that's where
rsync is actually starting. It's just getting down and
On Mon, 11 Nov 2002 Bruno Ferreira wrote:
Look for the processor usage in the machines that are transfering the
files. You'll probably see that one of those machines has about 100%
This doesn't seem to be the worst point. I mean: the machine is not
going down under pressure or something like
On Mon, 11 Nov 2002, Paul Faure wrote:
Try it without ssh.
But ssh have those nice authentication features...
ssh may be waiting in the random pool for more entropy (randomness).
When it grabs a lot of random data, it must wait for more random things
Are you sure bout that ? I'm throwing a
On Tue, Nov 12, 2002 at 01:05:38AM +0100, [EMAIL PROTECTED] wrote:
On Mon, 11 Nov 2002 jw schultz wrote:
You haven't really provided enough data to even guess what
is limiting your performance.
As I said in the last mail: One limit for sure is ssh.
Yes, I saw that. Some time after i
You haven't really provided enough data to even guess what
is limiting your performance.
How similar is the directory tree on the target (receiving)
machine? There are three general possibilities:
- It's empty.
- It's present, and substantially similar to the sending end.
- It's
On Mon, 11 Nov 2002, Craig Barratt wrote:
You haven't really provided enough data to even guess what
is limiting your performance.
How similar is the directory tree on the target (receiving)
machine? There are three general possibilities:
- It's empty.
That is the case at the
On Mon, 11 Nov 2002, jw schultz wrote:
What is the CPU load of rsync on the receiver? That is
important.
I'll check that.
The disks have an upper limit of 52 MB/s (ext2) respectively
45 MB/s (ext3). It's an IDE RAID with 12 WD disks.
You are giving us dribs and drabs. Now you mention
23 matches
Mail list logo
