bandwidth issue
Hello, I have a question concerning the performance of rsync beteen two sites, one in India one in Germany. File exchange between 2 Linux-machines is done using rsync-3.0.5 (typical file size 1.5 GB). Destination machine is: Linux machine1 2.6.9-55.0.9.ELsmp #1 SMP Tue Sep 25 02:16:15 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Source machine is: Linux machine2 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux ping between the two hosts yields in average 190ms. The bandwidth specified by the ISP is 6 Mbps. However, from rsync-logs I only get 340 KB/s which is about 2.7 Mbps (typical file size is 1.5 GB). Running 2 rsync processes in parallel I get 340 KB/s for EACH process, which is 5.4 Mbps in total. Starting a third parallel process bandwidth is going down, but the sum is still about 5.4 Mbps. I think the problem is related to the buffer size. Is it ok to change buffersize with this command line option: --sockopts=SO_SNDBUF=13,SO_RCVBUF=13 Is it sufficient to change only those 2 parameters ? Will this also change the buffersize af the other host (via rsync communication)? In the logs I do not get any information that the sockopts parameter is changing something (although I am using ). Any help or hint greatly appreciated. Thanks, gp -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: bandwidth issue
On Wed, Mar 11, 2009 at 7:41 AM, Gero Pflanz gero.pfl...@gmx.de wrote: Is it sufficient to change only those 2 parameters ? Will this also change the buffersize af the other host (via rsync communication)? In the logs I do not get any information that the sockopts parameter is changing something (although I am using ). You should change the buffer sizes on both ends of the connection in my experience if you are running one side in daemon mode. If you are running over an SSH tunnel, there may be additional complications, and some tweaking might need to be done at the SSH layer. At 190 ms, you need this window size: 6 Mb/s * 0.190 s = 114 bits = 142500 bytes This value is greater than 64KB, would require the use of TCP windows scaling options. Most recent OS (even windows) support this TCP window scaling automatically, but I have seen some ill-behaved firwealls, IDS, VPN gateways, and other network devices that choke on TCP connections with the windows scaling options set. All you can do is try to see if such a device is in your path. Note that if your rsync proccess is CPU or disk bound, these settings will not help. Try lowering the compression level or using the whole-file option if that is the case. -- RPM -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 6183] New: rsync error file too large (27)
https://bugzilla.samba.org/show_bug.cgi?id=6183 Summary: rsync error file too large (27) Product: rsync Version: 3.0.4 Platform: Other OS/Version: AIX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: way...@samba.org ReportedBy: bros...@gmail.com QAContact: rsync...@samba.org I am on AIX 5.3 TL8, I get this error when trying to transfer files, the file size is 2729126908 bytes and stops at 2G, (see output at bottom) i tried to copy it using scp and it works fine, rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken pipe (32) rsync: write failed on /export/data/c2dev/c2/backup/mksysb/daily/mksysb_0310_abcdef51.gz: File too large (27) rsync error: error in file IO (code 11) at receiver.c(298) [receiver=3.0.4] rsync: connection unexpectedly closed (14240 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(632) [sender=3.0.4] My version of rsync are identical on both sides: # rsync --version rsync version 3.0.4 protocol version 30 Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace, append, ACLs, no xattrs, no iconv, no symtimes here is the output of rsync using multiple -v data recv 32768 at 2147221504 data recv 32768 at 2147254272 data recv 32768 at 2147287040 data recv 32768 at 2147319808 data recv 32768 at 2147352576 data recv 32768 at 2147385344 data recv 32768 at 2147418112 data recv 32768 at 2147450880 rsync: write failed on /export/data/c2dev/c2/backup/mksysb/daily/mksysb_0311_abcdep51.gz: File too large (27) _exit_cleanup(code=11, file=receiver.c, line=298): entered rsync error: error in file IO (code 11) at receiver.c(298) [receiver=3.0.4] _exit_cleanup(code=11, file=receiver.c, line=298): about to call exit(11) rsync: connection unexpectedly closed (49 bytes received so far) [generator] _exit_cleanup(code=12, file=io.c, line=632): entered rsync error: error in rsync protocol data stream (code 12) at io.c(632) [generator=3.0.4] _exit_cleanup(code=12, file=io.c, line=632): about to call exit(12) -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 6183] rsync error file too large (27)
https://bugzilla.samba.org/show_bug.cgi?id=6183 --- Comment #1 from bros...@gmail.com 2009-03-11 11:38 CST --- Justed tested using rsync 3.0.2, and it works fine (same file, same servers) so the problem occursd using rsync 3.0.4 -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: proposal to speed rsync with lots of files
Using inotify with rsync is a great idea. If one has a job that runs daily to get differences on a very large filesytem with very small files, then can do this (assuming the initial copy is already completed): inotify watch source filesystem (or tree) take down all the notices in a txt file (absolute path) use rsync with the results from the txt file and place them in the destination repository re-resync again to be 100% sure. I like this idea. On Fri, Mar 6, 2009 at 11:58 AM, Wayne Davison way...@samba.org wrote: On Thu, Mar 05, 2009 at 03:27:50PM -0800, Peter Salameh wrote: My proposal is to first send a checksum of the file list for each directory. If is found to be identical to the same checksum on the remote side then the list need not be sent for that directory! My rZync source does something like that for directories: it treats a directory-list transfer like a file transfer. That means that the receiving side sends a set of checksums to the sending side telling it what it's version of the directory looks like, and then the sender sends a normal set of delta data that lets the receiver reconstruct the sender's version of the directory (which it compares to its own). One potential drawback is having to deal with false checksum-matches (which should be rare, but would require the dir data to be resent) I hadn't optimized it for block size or (possibly) data order to make it more efficient, but it is an interesting idea for speeding up a slow connection. I'm not sure if it would really help out that much for a more modern, faster connection, because rsync sends the file-list data at the same time as it is being scanned, and sometimes the scan is the bottle-neck. The best way to optimize sending of really large numbers of files that are mostly the same is to start to leverage a file-change notification system, such as inotify. Using that, it is possible to distill a list of what files/directories need to be copied, and to just copy what is needed. ..wayne.. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
