rsync - Jan 2008 - rsyncd performance when handling multiple clients in parallel

Hi:

I use rsync to transfer multiple files from several clients to a server in
parallel. I am wondering how many concurrent connections the server should
handle to maximize the throughput (number of bytes written to server). In
an extreme case, if only one connection allowed, the disk IO speed of
server will not be fully utilized. On the other hand, if the server allows
too many connections, the hard driver header will move around for writing
different files, which may also slow down the disk IO throughput.

Does rsyncd do any optimization for handling concurrent connections? and
does anyone have experience on fine tuning the server to maximize the
throughput?  Thanks.

Chuang

On Fri, 2008-01-25 at 14:21 -0600, chuang liu wrote:
> Does rsyncd do any optimization for handling concurrent connections?
No.  Concurrent connections are handled by completely independent server
processes.

Matt

Hi,

On Fri, 25 Jan 2008, chuang liu wrote:
> I use rsync to transfer multiple files from several clients to a server in
> parallel. I am wondering how many concurrent connections the server should
> handle to maximize the throughput (number of bytes written to server). In
> an extreme case, if only one connection allowed, the disk IO speed of
> server will not be fully utilized. On the other hand, if the server allows
> too many connections, the hard driver header will move around for writing
> different files, which may also slow down the disk IO throughput.
> 
> Does rsyncd do any optimization for handling concurrent connections? and
> does anyone have experience on fine tuning the server to maximize the
> throughput?  Thanks.
The best fine tuning for rsync servers is to add more RAM.

At ftp5.gwdg.de, I have 32 GB RAM and rsyncd is allowed to run 333 
concurrent sessions (beneath 999 vsftpd and 2500 apache instances).
These limits are not due to ressource limitation, but to limit race 
situations like f.e. a "scripted" rsync loop every five seconds.

With 80 Mbytes/sec net output the disk input is mostly below 20 MByte/sec
(varying with the diversity of the file requests) due to the buffer cache 
and "long living" inode cache, and all process memory can be held in
core
without swapping.

Your base situation differs - you are doing input to the rsync server. So 
the buffer cache function is different for you (it will help mainly to 
order the disk writes more efficiently), but a big inode cache will save a 
lot of directory lookup disk I/O.
 
A growing inode cache on 32-bit systems (say > 700 MB) can lead to hash 
collisions which can almost starve the system, so I would recommend x86_64 
arch for bigger rsync servers.


Viele Gr??e
Eberhard M?nkeberg (emoenke@gwdg.de, em@kki.org)

-- 
Eberhard M?nkeberg
Arbeitsgruppe IT-Infrastruktur
E-Mail: emoenke@gwdg.de      Tel.: +49 (0)551 201-1551
-------------------------------------------------------------------------
Gesellschaft f?r wissenschaftliche Datenverarbeitung mbH G?ttingen (GWDG)
Am Fassberg 11, 37077 G?ttingen
URL:    http://www.gwdg.de             E-Mail: gwdg@gwdg.de
Tel.:   +49 (0)551 201-1510            Fax:    +49 (0)551 201-2150
Gesch?ftsf?hrer:            Prof. Dr. Bernhard Neumair
Aufsichtsratsvorsitzender:  Prof. Dr. Christian Griesinger
Sitz der Gesellschaft:      G?ttingen
Registergericht:            G?ttingen  Handelsregister-Nr. B 598
-------------------------------------------------------------------------