|
July 08, 2013, 07:15:59 AM |
|
Кошелек ведет проверку параллельно скачиванию блоков, и делает по этой причине эту проверку не оптимальным методом. Очевидно что 'скачать базу до текущего момента' у соседа и проверить внешним приложением (где то тут была невероятно быстрая 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 (пока не закончится оперативная память, доступная для файлового кеша и буферов).
|