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

Хорошо известно, что ссылка программное обеспечение делает много ненужный синхронный диск IO во время SyncUP (в дополнении к большому количеству необходимости асинхронной IO), так SyncUP, как ожидается, прямо сейчас, чтобы быть медленными на системы без быстрых дисков ... но даже на системы с супер быстрыми дисками и процессорами, то SyncUP еще довольно медленно. Люди часто делают все виды диких связанных с сетевыми предложениями, которые, по их мнению поможет SyncUp, которые я дисконтирование: , но я не имел возможности сесть и работать на любой из реальных причин медлительности.

Ну, получается, что, когда шифрование бумажник был введен некоторое использование MLOCK () был добавлен, чтобы сохранить личные данные ключа из свопа. Это хорошая вещь, но MLOCK используется наивности, что плохо, потому что это медленные (результаты в флеш TLB). Это не имело бы значения слишком много, за исключением того, побочный эффект изменения был MLOCK всю память, используемую очень распространенный тип данных, используемый все через Bitcoin. Это бессмысленно, потому что большая часть использования не содержит личные данные. (И, возможно, даже негативное воздействие безопасности зашифрованных кошельков в системах с ограниченной памятью mlockable)

Это было довольно трудно отследить понижающий нем не отображается в счетчике OProfile цикла (он показал бы в TLB флеши, но то очевидно, только заднее числе) и не обнаруживалось в некоторых других инструментах производительности как Valgrind / callgrind (который является слишком упрощенным эмуляция знать MLOCK медленно). В конце концов я поймал его на выходе ltrace.

Существует еще некоторые продолжаются дискуссии о лучшем пути, чтобы исправить это, но повышение производительности по крайней мере, на некоторых узлах является весьма значительным. YMMV, если вы не на супер быстрый SSD это улучшение будет гораздо меньше (по крайней мере до тех пор, чрезмерное использование FSYNC не разрешен), и мой AMD AMD Phenom (TM) II X6 1055T с ядром 2.6.35.14-106.fc14 .x86_64 может MLOCK медленнее, чем некоторые другие.

Это также должно ускорить клиент вообще, хотя его особенно очевидно для цепи SyncUP.

Хватит говорить, как о некоторых фотографиях:

Синие и красные линии представляют собой варианта исправления, зеленый запас клиент.


Существует более обсуждение по запросу тянущего (https://github.com/bitcoin/bitcoin/pull/740)