На скрине запечатлен процесс прогулки по ноде 7.28ТБ на ssd 16ТБ.
Вводная диспозиция : имеется нода, которая существует с момента старта сторжа версии 3.
Жила она всё это время на hdd сигейте 16ТБ ST16000NM001G.
Я решил сделать дефрагментацию и заодно прогулку.
Для этого я сделал зеркало на 16ТБ ssd micron 9300 про. Затем отломил зеркало на hdd и получил ноду на ssd , которая затем будет пофайлово копироваться на hdd - это не долго , примерно сутки.
Но сейчас не об этом, а о запущеном перед переносом прогульщике с отключенным ленивым прогульщиком.
Так вот… Наш любимый прогульщик, как по мне, стоит признать мертвой технологией, по той простой причине, что нода даже будучи запущена на хайэнд оборудовании выполняет прогулку уже более получаса, безусловно процесс немного замедлил идущий также перенос в корзину, но это не так принципиально. Даже в случае с параллельной работой переноса в корзину, это все очень долго.
Что говорит о том, что на диске, фрагментированном за годы работы ноды на этом диске, этот процесс с практической точки зрения является бесконечным.
Да есть всякие там костыли, типа zfs с метой на ssd… Но я не преемлю дополнительную точку отказа на пустом месте, не говоря за повышение стоимости, что при нынешней доходности невозможно.
Костыль в виде барсучьего кеша также меня совсем не впечатлил.
Разговоры о “ни чего не покупайте для сторжа” так же не забываем… Так ведь ?
НО! В общем случае, по моему мнению, это плохое решение, которое требует замены.
Ну и собственно сама нода.
Если вы используете диск целиком для узла, то вы можете включить фичу dedicated disk:
Правда использование на доске не будет обновляться корректно, зато совсем не нужен used-space-filewalker и узел будет принимать данные, пока место не кончится (резерв по умолчанию 300ГБ, но его можно изменить).
Другая экспериментальная многообещающая фича - hashstore:
Мы скоро опубликуем, как её можно включить и использовать. Пока что она скрыта в текущей релизной версии.
А текущий обходчик будет работать медленно без кэширования метаданных в SSD слое (доступно также в Windows, называется storage layers), либо в памяти (нужно не менее 1GB на каждый TB данных), либо badger cache.
В случае Windows NTFS ещё помогает дефрагментация, однако для случая SSD это не должно быть важно. Если у вас оно работает медленно на текущем SSD, то возможно требуется обновить firmware.
Алексей! Да бог с ним с обходчиком, диски выделенные, потому он отключен обычно. Мне почему то кажется что сейчас версия ноды на windows стала даже принимать ингреса в 3-4 раза меньше чем на линуксе. Ощущение что что-то в коде ноды некорректно работает с файловой системой.
Я собираюсь проверить эту версию, перенеся одну ноду на линукс с zfs и метой, и сравнить ингрес на ноде на windows и ноде на линукс.
Потому как перенос ноды windows на ссд не дал оcобого преимущества в ингресе, в сравнении с той же нодой на hdd.
Аппаратное обеспечение никогда особо не влияло на количество входящих данных. Каждый узел - уникален и обслуживает клиентов по запросу. Даже на том же сервере они ведут себя по-разному, потому что используются разными клиентами: помните про фильтр /24? Вот он и помогает сателлитам выбирать узлы так, чтобы на одном сервере не оказалось несколько кусочков одного и того же сегмента, а значит с высокой долей вероятности эти узлы будут обслуживать совершенно разных клиентов.
Windows NTFS известна тем, что обычно работает медленнее, чем даже ext4 на том же оборудовании, так что перемещение на ZFS может иметь положительный эффект.