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
Today, Mozzi wrote:
All tests were done from the same two machines in the same direction,I
just changed the options
It was done on two Gigabit nic's with a crosover cable so network usage
and speed were effectively
not a factor.
This is not true ! A Gigabit card itself never uses jumbo
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
One thing to add:
When this problem shows up, it seems rsync tries to get all the
CPU time on the sending side: 93-98%. Even ssh can only get between 2
and 5% of CPU time. Even though rsync is not growing in memory, top
shows nevertheless that it really gets almost every second of
CPU time. What
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
Today, Mozzi wrote:
In all test the same 2.5 Gig logfile was used for transfer
(2719312019 Nov 12 11:42 maillog.back)
(2.5G Nov 12 11:42 maillog.back)
The transfer was done over two Gigabit nic's one onboard broadcom on
IBM X440 server, Other Intel on standard selfbuilt dual P3 880 machine.
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 do with our internal net)
and falls
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:
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 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
15 matches
Mail list logo
