Массовая вставка в Hyperledger Fabric сохраняет время ожидания - PullRequest
Новая
       13

Массовая вставка в Hyperledger Fabric сохраняет время ожидания

0 голосов
/ 05 октября 2018

Мы массово вставляем записи в Hyperledger Fabric.Тем не менее, мы решаем проблему с тайм-аутом.Даже если мы продолжаем увеличивать время ожидания, эта ошибка будет возникать позже.

Каждая транзакция вставляет 1000 записей, используя PutState в цикле для всех этих записей (слепая вставка, ничего в наборе для чтения).Мы также увеличили значение BatchTimeout до 3 с и MaxMessageCount до 100, чтобы получить более крупные блоки (мы видим 4 транзакции на блок, поэтому 4000 [4x1000 записей на транзакцию] записей вставляются в книгу с каждым блоком).

В случае сбоя массового обновления для CouchDB, и одноранговый узел должен повторить попытку для каждой (из 1000 записей на транзакцию) записей в отдельности, запросы выполняются слишком долго и превышают время ожидания.Но это наше предположение.Также мы нашли это: https://jira.hyperledger.org/browse/FAB-10558, но в нем говорится, что оно уже исправлено в v1.2.0, той версии, которую мы используем.

Полученная ошибка net/http: request canceled (Client.Timeout exceeded while reading body) из журналов ниже:

Мы попытались установить следующую переменную среды в одноранговом контейнере:

CORE_CHAINCODE_EXECUTETIMEOUT=120s

А также req.setProposalWaitTime(120 * 1000) при использовании Java SDK.

Но тогда мы просто получим ту же ошибку тайм-аута на более позднем этапе.Таким образом, мы можем продолжать увеличивать переменную тайм-аута до большего числа, но мы верим, что это повторится позже.Время, необходимое для вставки в CouchDB, пропорционально количеству записей в CouchDB?Может быть, обновление индекса займет больше времени, когда число документов увеличится?

Журнал ошибок времени выполнения, который мы получаем (после вставки примерно 2-4 миллионов записей), выглядит следующим образом: 

    October 5th 2018, 04:36:38.646  github.com/hyperledger/fabric/core/committer.(*LedgerCommitter).CommitWithPvtData(0xc4222db8c0, 0xc451e4f470, 0xc4312ddd40, 0xdf8475800)
    October 5th 2018, 04:36:38.646  github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc4220c5a00)
    October 5th 2018, 04:36:38.646  goroutine 283 [running]:
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/core/committer/committer_impl.go:105 +0x6b
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/gossip/privdata/coordinator.go:236 +0xc3b
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:771 +0x6c
    October 5th 2018, 04:36:38.646  
    October 5th 2018, 04:36:38.646  github.com/hyperledger/fabric/core/ledger/kvledger.(*kvLedger).CommitWithPvtData(0xc421fb1860, 0xc451e4f470, 0x0, 0x0)
    October 5th 2018, 04:36:38.646  github.com/hyperledger/fabric/gossip/privdata.(*coordinator).StoreBlock(0xc422286e60, 0xc42462cd80, 0x0, 0x0, 0x0, 0xc4312dde78, 0x7329db)
    October 5th 2018, 04:36:38.646  github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock(0xc4220c5a00, 0xc42462cd80, 0x0, 0x0, 0x0, 0x0, 0x0)
    October 5th 2018, 04:36:38.646  panic: Error during commit to txmgr:net/http: request canceled (Client.Timeout exceeded while reading body)
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger.go:273 +0x870
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:558 +0x3c5
    October 5th 2018, 04:36:38.646      /opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:239 +0x681
    October 5th 2018, 04:36:38.646  created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
    October 5th 2018, 04:36:03.645  2018-10-04 20:36:00.783 UTC [kvledger] CommitWithPvtData -> INFO 466e[0m Channel [mychannel]: Committed block [1719] with 4 transaction(s)
    October 5th 2018, 04:35:56.644  [33m2018-10-04 20:35:55.807 UTC [statecouchdb] commitUpdates -> WARN 465c[0m CouchDB batch document update encountered an problem. Retrying update for document ID:32216027-da66-4ecd-91a1-a37bdf47f07d
    October 5th 2018, 04:35:56.644  [33m2018-10-04 20:35:55.866 UTC [statecouchdb] commitUpdates -> WARN 4663[0m CouchDB batch document update encountered an problem. Retrying update for document ID:6eaed2ae-e5c4-48b1-b063-20eb3009969b
    October 5th 2018, 04:35:56.644  [33m2018-10-04 20:35:55.870 UTC [statecouchdb] commitUpdates -> WARN 4664[0m CouchDB batch document update encountered an problem. Retrying update for document ID:2ca2fbcc-e78f-4ed0-be70-2c4d7ecbee69
    October 5th 2018, 04:35:56.644  [33m2018-10-04 20:35:55.904 UTC [statecouchdb] commitUpdates -> WARN 4667[0m CouchDB batch document update encountered an problem. ... and so on

1 Ответ

0 голосов
/ 13 октября 2018

[33m2018-10-04 20:35:55.870 UTC [statecouchdb] commitUpdates -> WARN 4664[0m CouchDB batch document update encountered an problem. Retrying update for document ID:2ca2fbcc-e78f-4ed0-be70-2c4d7ecbee69

Вышесказанное предполагает, что POST http://localhost:5984/db/_bulk_docks не удалось, и поэтому отдельные документы были опробованы отдельно.

Если посмотреть на различные параметры, доступные для настройки, увеличение requestTimeout в разделе книги может стоить того.

Это можно сделать, установив следующую переменную среды в docker-compose для вашего однорангового контейнера:

CORE_LEDGER_STATE_COUCHDBCONFIG_REQUESTTIMEOUT=100s

Имя переменной среды, связанной сПараметр конфигурации можно получить, посмотрев этот ответ.

Конфигурирование CORE_CHAINCODE_EXECUTETIMEOUT и proposalWaitime может не иметь эффекта, как некоторые другие нисходящие соединения (здесь это соединение HTTP между peer и couchdb ) истекло время ожидания, а затем увеличилось исключение тайм-аута.

...