Сжатие текста при передаче по сети

Может rsync со включенным сжатием?

tar + bzip2 + netcat - скорее всего, даст наибольший выигрыш по объему (блочное сжатие).

А scp - он сам умеет сжатие, ежели чего.

Где-то недавно натыкался на тесты именно такого случая, вратце там имело смысл или передавать через netcat (+ gzip), или через ssh (+ тот же gzip), scp или sftp там несколько проигрывало (не фатально, но заметно), т. е. на современных системах оверхед на ssh практически отсутствовал.

Тесты я смотрел, но это слишком костыльно, и не подходит для круглосуточного качания логов, я щитаю

Что-то никак не нагуглю тесты.
Нет случаем под рукой готового сравнения?

порядка терабайта в день

пц. выключить логирование.

ssh -C ?

Нет случаем под рукой готового сравнения?

http://cs.fit.edu/~mmahoney/compression/text.html
Разумный выбор - 7zip/lzma, очень хорошая компрессия при приличной скорости упаковки и быстрая распаковка.

нет, вопрос именно про утилизацию сетевого линка, на другой стороне эти логи разбираются и пишутся в базу.

после применения bzip2, вопрос может встать о разгрузке CPU на передающей стороне

sdio, посоветуй мне что-нить умное

самые модные методы сжатия данных

LZMA: xz, 7-zip, etc
Хорошее сжатие, быстрая распаковка.

К сожалению, нету. Подозреваю, что rsynz должен сжимать хуже gzip, так как работает скорее всего с каждым файлом по очереди, а не со всеми сразу.

посоветуй мне что-нить умное

А какая связь между серверами? Может скрестить NFS и FuseCompress, тогда бы логи писались в сжатом виде на удаленный сервер.

gzip+ftp

связь по меди, в одной подсети, в одном помещении

В серверах небось больше одной сетевухи, можно логи (даже не сжатые) гонять по вторым сетевухам, а «полезные» данные по первым.

мм...хорошо. усложним задачу
Скоро надо будет второй филиал подключать и с него такие же данные в таком же объёме сливать в одну базу.

В голову приходит tar + gzip+ netcat или tar + gzip + scp, но не знаю как это красиво автоматизировать,

нормальный вариант, скрипт написать.

да и слишком уж это костыльно

rsync уже предлагали. Я бы на нем и остановился.

rsync уже предлагали. Я бы на нем и остановился.

Я бы тоже остановился, но что-то мнения не воодушевляют особо.
Придётся потестировать на реальных данных...

как вариант поднять туннель openvpn, он жмёт данные во время передачи. но правда, и CPU неплохо при этом ест..

Придётся потестировать на реальных данных..

Только на приемном конце подними rsync как демон, иначе в качестве транспорта будет ssh

но что-то мнения не воодушевляют особо.

Вообще, да, потестил rsync с сжатием, только на --compress-level=2 или 1 получаем двойной прирост скорости (один из 8 CPU (core) 100% Intel(R) Xeon(R) CPU E5430 @ 2.66GHz)

текстовый файл 750Мб передается чистым rsync'om за 18 сек (40Мб/с), с сжатием за 8 сек (89Мб/с)

$ time sh -c 'gzip -c /dev/shm/test.file | ssh lnx2 «gunzip -c > /dev/shm/test.file»'
за 15 сек (50Мб/с)

$ time sh -c 'gzip -2 -c test.file | ssh lnx2 «gunzip > /dev/shm/test.file»'
8 сек (89Мб/с)

вобщем, стоит озаботиться многопоточным сжатием, pigz, lbzip2, ...

И еще, если этот 750Мб файл сжать предварительно, получается 48Мб и он передается за 1 сек.

Ну, как вариант сжимать файл перед передачей и класть его в tmpfs, передавать и удалять.

Я бы просто передавал по ftp сжатые файлы, а на прёмной стороне разворачивал их перед обработкой, чтобы не возится с netcat. Обычный ftp-клиент умеет вызывать внешнюю команду, поэтому можно так:

put «| gzip -9 -c FILE.txt» FILE.txt.gz

Вместо gzip можно другой компрессор, это уж проще по месту сравнить, насколько кто сильнее сожмёт.

Шикарно, на той стороне действительно можно использовать gz
А где почитать про внешние команды, что-то я не нашёл с ходу такого

bzip2 ... даст наибольший выигрыш по объему

xz

man ftp, в конце «FILE NAMING CONVENTIONS».

А как у вас реализована проверка целостности? По хорошему ведь нужно проверить что файл был передан без ошибок, и удалять файл на исходном сервере только после того, как он был обработан (занесён в БД).

нужно проверить что файл был передан без ошибок

Доверяю TCP в этом вопросе :)
При таких объёмах, файл проще дропнуть на этапе разбора\записи в базу и забыть про него, чем перекачивать

Попробуй openvpn со сжатием, как тебе выше писали. При этом все остальные команды не требуют доработок/изменений, растягивается только сам канал передачи данных от сервера к серверу.

# grep -E '(proto|lzo|fast)' openvpn/client1.conf
proto udp
comp-lzo
fast-io