Кошелек ведет проверку параллельно скачиванию блоков, и делает по этой причине эту проверку не оптимальным методом. Очевидно что 'скачать базу до текущего момента' у соседа и проверить внешним приложением (где то тут была невероятно быстрая 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 (пока не закончится оперативная память, доступная для файлового кеша и буферов).
Topic: Цепочка и RAID 1 (Read 2564 times)
зачем вообще это всё? синхронизация идёт меньше одного дня. После синхронизации одновременно даже 6 кошельков разных криптовалют не нагружают даже ноутбучный винчестер с 5400 оборотов/минуту ( в windows длина очереди диска от 0 до 0.08)
это решаемо предварительным скачивание бд
Ничего я не путаю, просто решаю свою задачу, все требования которой вам не известны.
Вот скачали вы БД предварительно. Потом программа должна её проверить. Это значит, что надо много читать и много искать.
Чтение будет работать с одинаковой скоростью на RAID-0 и RAID-1 (в моём случае с mdadm, а не аппаратным контроллером).
И только ваши догмы и предрассудки (о том, что только RAID-0, если нужна скорость) мешают вам воспринимать других людей не менее умными чем вы сами.
проверка идет в разы быстрее скачивания
есть синтетические тесты скорости диска погоняйте их и убедитесь сами какой вам оптимальнее
это решаемо предварительным скачивание бд
Ничего я не путаю, просто решаю свою задачу, все требования которой вам не известны.
Вот скачали вы БД предварительно. Потом программа должна её проверить. Это значит, что надо много читать и много искать.
Чтение будет работать с одинаковой скоростью на RAID-0 и RAID-1 (в моём случае с mdadm, а не аппаратным контроллером).
И только ваши догмы и предрассудки (о том, что только RAID-0, если нужна скорость) мешают вам воспринимать других людей не менее умными чем вы сами.
Я правильно понимаю, что если положить кошелёк на raid1, то он будет работать во столько раз быстрее, сколько дисков в RAID1-массиве (т.е. если в зеркале 4 одинаковых диска, то цепочка будет синхронизироваться в четыре раза быстрее)?
эм... а вы не путаете 1 с 0? 
RAID1 может ускорить скорость чтения, и то не на всех контроллерах. ибо как бэ идеологически создавался для увеличения надёжности хранения а не скорости
Raid1 - делает зеркалирование дисков
Raid0 - склейку в одно логическое пространство с параллельным вводом-выводом
кошелек работает быстро, а вот синхронизируется первый раз долго, но это решаемо предварительным скачивание бд
Я правильно понимаю, что если положить кошелёк на raid1, то он будет работать во столько раз быстрее, сколько дисков в RAID1-массиве (т.е. если в зеркале 4 одинаковых диска, то цепочка будет синхронизироваться в четыре раза быстрее)?
эм... а вы не путаете 1 с 0? RAID1 может ускорить скорость чтения, и то не на всех контроллерах. ибо как бэ идеологически создавался для увеличения надёжности хранения а не скорости
Quote
Ну и это не отвечает на вопрос - как запустить систему на допустим трёх машинах параллельно для ускорения (типа distcc)
Для ускорения чего? Текущей скорости недостаточно, когда база уже загружена? Обычным пользователям скорости скачивания/добавления новых блоков хватает, проблема только в первоначальной загрузке всей базы. отказались от oracle berkely db и сменили ее на LevelDB
Странные люди. Ведь в этой новой базе данных нет индексов.
"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)
потому что никому не надо было, я предложил вам способы решения...первый же результат в google:
http://serverfault.com/questions/152985/emulate-a-smp-server-with-a-linux-cluster
отказались от oracle berkely db и сменили ее на LevelDB
Странные люди. Ведь в этой новой базе данных нет индексов.
"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)
для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию
Это же отлично! Это означает, что можно параллелить работу на сотни и тысячи ядер, не так ли?
Если есть N машин с многоядерными процессорами, это поможет?
Но всё равно непонятно, как получается много часов.
p.s. что то мне говорит, что необходимости в кластерной реализации кошелька возникнет еще не скоро, но на сколько я знаю для linux есть библиотеки, позволяющие эмулировать многоядерную машину в кластере для тех приложений, которые это еще не поддерживают, конечно же итоговая производительность упрется в скорость сети, но вы можете попробовать...
для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию
Это же отлично! Это означает, что можно параллелить работу на сотни и тысячи ядер, не так ли?
Если есть N машин с многоядерными процессорами, это поможет?
Но всё равно непонятно, как получается много часов.
тупо уприрается в мощность проца.
Правильно ли я понимаю, что там можно большую часть работы по проверке цепочки (а не по майнингу) провести через видеокарту?
Основная нагрузка скорее идет не на вычисление sha256 (мой процессор максимум считает на скорости ~20MH/s т.е. миллионы в секунду, а весь blockchain содержит всего несколько сотен тысяч блоков) а определение связности между транзакциями (проверка, что все монеты потрачены правильно), т.е. для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию.
тупо уприрается в мощность проца.
Правильно ли я понимаю, что там можно большую часть работы по проверке цепочки (а не по майнингу) провести через видеокарту?
заново выситываются и сверяются хеши блоков.
Сколько процентов времени уходит на хеширование,
а сколько процентов времени на поиск блоков в базе данных?
На хеширование в зависимости от мощности проца, поиск по базе в зависимости от дисковой подсистемы. В случае с РАМ-диском там скорей всего все тупо уприрается в мощность проца. мне почти впритык хватило раздела в 10GB
У меня на машине всего 16 GB RAM. Правильно ли я понимаю, что две валюты на ней таким способом не запустить, и обменник не получится?
заново выситываются и сверяются хеши блоков.
Сколько процентов времени уходит на хеширование,
а сколько процентов времени на поиск блоков в базе данных?
месц
2) сколько нужно памяти под tmpfs-диск (т.е. например, если хочется на узле иметь несколько валют, то какого размера память заказывать у хостера на виртуальной машине).
На win7x64 машине месяц назад мне почти впритык хватило раздела в 10GB 1) зачем ему столько времени? (интересна конкретная раскладка)
В процессе скачивания все цепочка блоков полностью проверяется на валидность. Т.е. заново выситываются и сверяются хеши блоков. до считанных часов
Потрясяюще! Интересно:
1) зачем ему столько времени? (интересна конкретная раскладка)
2) сколько нужно памяти под tmpfs-диск (т.е. например, если хочется на узле иметь несколько валют, то какого размера память заказывать у хостера на виртуальной машине).
Да быстрее, но зависимость далеко не линейная.
p.s. размещение базы blockchain на ram-диске ускоряет синхронизацию до считанных часов
p.s. размещение базы blockchain на ram-диске ускоряет синхронизацию до считанных часов
Jump to: