On Mon, Jun 02, 2008 at 01:17:42AM +0400, Alexey Tourbin wrote:
> On Sun, Jun 01, 2008 at 05:48:46PM +0400, Alexander Bokovoy wrote:
> > 1. Оптимизировать работу по rsync: меньше объем данных для
> > последовательных синхронизаций, меньше нагрузка на сервер _и_ клиент,
> > поскольку анализ блоков rsync все равно производит, а данные в удобном
> > для rsync формате позволяют этот анализ сократить.
> 
> Нагрузка на сервер от rsync'а -- это какая-то городская легенда.

Если сравнить процесс vsftpd, который в основном занимается тем, что делает
sendfile(2), с rsync -H, который при работе с 100G архивом не помещается
в 64M памяти и что-то считает, то vsftpd создаёт на порядки меньшую загрузку
чем rsync.  1024 одновременных ftp-сессий для vsftpd это не вопрос, а вот
128 rsync-сессий это уже проблема.

> rsync(1):
> 
> 	Rsync finds files that need to be transferred using a "quick check"
> 	algorithm (by default) that looks for files that have changed in size
> 	or in last-modified time.
> 
> Когда кто-то синхронизирует сизиф, rsync server сканирует не все поряд
> файлы, а только те, которые изменились (то есть новые rpm пакеты).
> Файлов же менятся ограниченное количество (для x86_64 -- 2.3G в месяц).
> Значит, если воткнуть в сервер лишние 2G, которые стоят $100 или вроде

2G серверной памяти для серверов предыдущего поколения (DDR1 ECC REG)
стоит примерно $240.  И хорошо ещё, если под неё есть свободный слот.

> того (а также нужно смонтировать фс с опцией noatime), то rsync server
> перейдёт преимущественно в in-memory режим.

Пока что такого in-memory добиться не удаётся.


-- 
ldv