Bitcoin Forum

Я правильно понимаю, что если положить кошелёк на raid1, то он будет работать во столько раз быстрее, сколько дисков в RAID1-массиве (т.е. если в зеркале 4 одинаковых диска, то цепочка будет синхронизироваться в четыре раза быстрее)?

Да быстрее, но зависимость далеко не линейная.
p.s. размещение базы blockchain на ram-диске ускоряет синхронизацию до считанных часов

Потрясяюще! Интересно:
1) зачем ему столько времени? (интересна конкретная раскладка)
2) сколько нужно памяти под tmpfs-диск (т.е. например, если хочется на узле иметь несколько валют, то какого размера память заказывать у хостера на виртуальной машине).

В процессе скачивания все цепочка блоков полностью проверяется на валидность. Т.е. заново выситываются и сверяются хеши блоков.

месцНа win7x64 машине месяц назад мне почти впритык хватило раздела в 10GB

Сколько процентов времени уходит на хеширование,
а сколько процентов времени на поиск блоков в базе данных?

У меня на машине всего 16 GB RAM. Правильно ли я понимаю, что две валюты на ней таким способом не запустить, и обменник не получится?

Понятия не имею :) На хеширование в зависимости от мощности проца, поиск по базе в зависимости от дисковой подсистемы. В случае с РАМ-диском там скорей всего все тупо уприрается в мощность проца.

Правильно ли я понимаю, что там можно большую часть работы по проверке цепочки (а не по майнингу) провести через видеокарту?

сомнительно.

Основная нагрузка скорее идет не на вычисление sha256 (мой процессор максимум считает на скорости ~20MH/s т.е. миллионы в секунду, а весь blockchain содержит всего несколько сотен тысяч блоков) а определение связности между транзакциями (проверка, что все монеты потрачены правильно), т.е. для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию.

Это же отлично! Это означает, что можно параллелить работу на сотни и тысячи ядер, не так ли?
Если есть N машин с многоядерными процессорами, это поможет?

Но всё равно непонятно, как получается много часов.

на сколько я понимаю 0.8+ версии так и делают, используют сразу несколько процессоров для проверки загружаемой цепочки, и даже для ускорения работы отказались от oracle berkely db и сменили ее на LevelDB
p.s. что то мне говорит, что необходимости в кластерной реализации кошелька возникнет еще не скоро, но на сколько я знаю для linux есть библиотеки, позволяющие эмулировать многоядерную машину в кластере для тех приложений, которые это еще не поддерживают, конечно же итоговая производительность упрется в скорость сети, но вы можете попробовать...

Странные люди. Ведь в этой новой базе данных нет индексов.

"This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes"

зачем тогда вообще нужен движок БД? Не проще ли просто запрограммировать кастомную структуру данных?

Ну и это не отвечает на вопрос - как запустить систему на допустим трёх машинах параллельно для ускорения (типа distcc)

почитайте про document oriented и key-value database, они представляют из себя один больший индекс по primary key (если брать аналогию из реляционных sql db) они предоставляют больше возможностей для ускорения чем более сложные - реляционные.

потому что никому не надо было, я предложил вам способы решения...

первый же результат в google:
http://serverfault.com/questions/152985/emulate-a-smp-server-with-a-linux-cluster

Для ускорения чего? Текущей скорости недостаточно, когда база уже загружена? Обычным пользователям скорости скачивания/добавления новых блоков хватает, проблема только в первоначальной загрузке всей базы.

эм... а вы не путаете 1 с 0? :)
RAID1 может ускорить скорость чтения, и то не на всех контроллерах. ибо как бэ идеологически создавался для увеличения надёжности хранения а не скорости

точно путает!
Raid1 - делает зеркалирование дисков
Raid0 - склейку в одно логическое пространство с параллельным вводом-выводом
кошелек работает быстро, а вот синхронизируется первый раз долго, но это решаемо предварительным скачивание бд

Ничего я не путаю, просто решаю свою задачу, все требования которой вам не известны.

Вот скачали вы БД предварительно. Потом программа должна её проверить. Это значит, что надо много читать и много искать.

Чтение будет работать с одинаковой скоростью на RAID-0 и RAID-1 (в моём случае с mdadm, а не аппаратным контроллером).

И только ваши догмы и предрассудки (о том, что только RAID-0, если нужна скорость) мешают вам воспринимать других людей не менее умными чем вы сами.

кто вам сказал что я умный  :o  ???
проверка идет в разы быстрее скачивания
есть синтетические тесты скорости диска погоняйте их и убедитесь сами какой вам оптимальнее

зачем вообще это всё? синхронизация идёт меньше одного дня. После синхронизации одновременно даже 6 кошельков разных криптовалют не нагружают даже ноутбучный винчестер с 5400 оборотов/минуту ( в windows длина очереди диска от 0 до 0.08)

Кошелек ведет проверку параллельно скачиванию блоков, и делает по этой причине эту проверку не оптимальным методом. Очевидно что 'скачать базу до текущего момента' у соседа и проверить внешним приложением (где то тут была невероятно быстрая opensource утилита для разного анализа blockchain) гораздо эффективнее для 'старта'.

RAID с чередованием (stripe) сам по себе очень плохо решает задачу оптимизации чтения (да и записи если честно), наиболее заметный прирост замечают на блочных/линейных операциях больших объемов, и очень мало какие контроллеры будут делать грамотное кеширование и распределение запросов по устройствам (с отдельными очередями IO на диск, например), я не слышал чтобы софтовые решения LVM или MDADM этим могли похвастаться.

Для базы данных blockchain необходимы высокие IOPS на рандомных запросах, прирост которых для raid0 'дай бог' логарифмический (от количества). И не забываем, raid часто читают весь блок (дефолтные настройки) данных секторов, на которые порезан логический раздел (для оптимизации read ahead) - для базы blockchain это размер должен быть сравним с размером блока (десятки килобайт) или даже транзакции (считанные байты) а значения по умолчанию для типичных рейдов - 2-4 мегабайта. Т.е. raid может даже ухудшить скорость работы.

p.s. у вас 16 GB оперативной памяти, этого спокойно хватит для однократной загрузки блоков, после этого данные перемещаются на обычный диск.
Если у вас linux и оперативной памяти меньше или сравнимо с размером базы blockchain (можно и 8GB обойтись) то можно разместить blockchain на отдельном разделе с ext4, и временно включить на нем journal_write_back (и в опциях монтирования), в этом случае скорость работы с базой будет сравнима со скоростью tmpfs (пока не закончится оперативная память, доступная для файлового кеша и буферов).