LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

2

Задача такая: перекидывать логи по сети, с одного сервера на другой, удалить переданные логи.
Сейчас это делается по ftp.
Но, так как как файлы текстовые и их много (порядка терабайта в день), то меня жаба душит по части утилизации сети.
Какие сейчас самые модные методы сжатия данных (в данном случае это простой текст, так что ожидаю многократый выигрыш по сравнению с ftp)?
В голову приходит tar + gzip+ netcat или tar + gzip + scp, но не знаю как это красиво автоматизировать, да и слишком уж это костыльно

★★★★★

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

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

sergv
()

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

berrywizard ★★★★★
()
Ответ на: комментарий от berrywizard

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

zolden ★★★★★
() автор топика

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

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

ukr_unix_user ★★★★
()
Ответ на: комментарий от GAMer

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

zolden ★★★★★
() автор топика
Ответ на: комментарий от zolden

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

redixin ★★★★
()

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

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

quantum-troll ★★★★★
()
Ответ на: комментарий от zolden

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

xaizek ★★★★★
()
Ответ на: комментарий от zolden

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

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

sdio ★★★★★
()
Ответ на: комментарий от zolden

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

zolden ★★★★★
() автор топика

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

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

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

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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

zolden ★★★★★
() автор топика
Ответ на: комментарий от zolden

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

victorb ★★
()
Ответ на: комментарий от zolden

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

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

sdio ★★★★★
()
Ответ на: комментарий от zolden

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

Вообще, да, потестил 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Мб/с)

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 2)
Ответ на: комментарий от sdio

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

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

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

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 2)
Ответ на: комментарий от sdio

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

blind_oracle ★★★★★
()

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

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

zolden ★★★★★
() автор топика
Ответ на: комментарий от sergv

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

xz

anonymous
()
Ответ на: комментарий от zolden

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

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

zolden ★★★★★
() автор топика

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

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

justAmoment ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.