Comments 7
Спасибо за статью) Идея интересная, а код можно посмотреть? А то без кода сложно оценить ценность теоретических изысканий. И меня сильно интересует и смущает эффективность режима дедубликации на практике: 1) пусть с сети мы нагрузку снимаем, но на файловую систему она и переходит (запись на диски кучи разрозненных блоков, плохо поддающихся оптимизации — либо нужна специализированная ФС); 2) как и где осуществляется индексация блоков данных, что если таблица индексации увеличится до размеров, когда ее частично засвопит ОС? Вопросов много, поэтому и тема и статья интересны — еще раз спасибо Вам)
Спасибо за вопросы.
Код нельзя выложить в открытый доступ. Все описанное в статье было честно, эффективно реализовано и результаты (графики) получены для описанных в статье экспериментов. Поэтому в статье описаны не только теоритические выкладки. Теория скорее объясняет в нашем случае результаты практических экспериментов.
Другие вопросы, которые вы задали, выходят за рамки статьи. Сеть за них, так скажем, не отвечает. Но немного отвечу.
1) ФС всегда пишут сначала в память (RAM). Далее блоки, которые нужно записать на диск собираются в «пакеты» и оптимизированно (последовательно) записываются на диск. То есть запись, как правило, не по одному блоку со случайным доступом к диску. Конечно сервер может быть перегружен от данных клиентов. Тогда в действие вступает дополнительный сетевой протокол, ответственность которого — лимитировать скорость отправки данных клиентами/отказать некоторым клиентам в обслуживании/перераспределить нагрузку (например, на другой шард). Вариантов много. Цель статьи — повысить максимальную пропускную способность протокола, а дальше ее можно динамически менять в своем диапазоне.
2) Обычно индексы стараются полностью хранить в памяти. Индекс может быть распределенным (шардированным), чтобы памяти многих машин хватило для хранения индекса. Также можно использовать пространственную локальность (prefetch индекса с диска), либо временную локальность (вытеснять давно не использованные блоки из индекса) — тогда индекс становится кешом со всеми вытекающими методиками связанными с кешами.
Код нельзя выложить в открытый доступ. Все описанное в статье было честно, эффективно реализовано и результаты (графики) получены для описанных в статье экспериментов. Поэтому в статье описаны не только теоритические выкладки. Теория скорее объясняет в нашем случае результаты практических экспериментов.
Другие вопросы, которые вы задали, выходят за рамки статьи. Сеть за них, так скажем, не отвечает. Но немного отвечу.
1) ФС всегда пишут сначала в память (RAM). Далее блоки, которые нужно записать на диск собираются в «пакеты» и оптимизированно (последовательно) записываются на диск. То есть запись, как правило, не по одному блоку со случайным доступом к диску. Конечно сервер может быть перегружен от данных клиентов. Тогда в действие вступает дополнительный сетевой протокол, ответственность которого — лимитировать скорость отправки данных клиентами/отказать некоторым клиентам в обслуживании/перераспределить нагрузку (например, на другой шард). Вариантов много. Цель статьи — повысить максимальную пропускную способность протокола, а дальше ее можно динамически менять в своем диапазоне.
2) Обычно индексы стараются полностью хранить в памяти. Индекс может быть распределенным (шардированным), чтобы памяти многих машин хватило для хранения индекса. Также можно использовать пространственную локальность (prefetch индекса с диска), либо временную локальность (вытеснять давно не использованные блоки из индекса) — тогда индекс становится кешом со всеми вытекающими методиками связанными с кешами.
Скажите, пожалуйста, какую реализацию UDT Вы использовали, существующую или написанную самостоятельно?
На этом этапе работы мы проводили тестирование уже существующих решений, поэтому использовали готовую реализацию протокола UDT
Существующую, это какую?
Если udt.sourceforge.net, то эта реализация достаточно требовательна к CPU. Это надо учитывать, чтобы не получить искаженные результаты.
Если udt.sourceforge.net, то эта реализация достаточно требовательна к CPU. Это надо учитывать, чтобы не получить искаженные результаты.
Спасибо за комментарий
Даже эта реализация в первом приближении показала неплохую производительность в сетях с большими задержками. Но по причинам, описанным в статье, протокол UDT для нашей задачи не подошел. Поэтому рассмотрение других реализаций, а тем более написание собственной было не целесообразно.
Даже эта реализация в первом приближении показала неплохую производительность в сетях с большими задержками. Но по причинам, описанным в статье, протокол UDT для нашей задачи не подошел. Поэтому рассмотрение других реализаций, а тем более написание собственной было не целесообразно.
Только я заметил, что на втором графике при задежке 100мс пропускная способность в районе 200 Мбит/с?
Sign up to leave a comment.
Сетевой протокол для резервного копирования данных в сетях с задержками и потерями пакетов