2

私は Couch を初めて使用し、約 70 台のクライアント Android フォン (すべて HTC Desire S) で CouchBase Mobile (Developer Preview V2.0) を使用する中規模のプロジェクトを継承し、マスター CouchDB サーバーと同期します。

残念ながら、システムを構築した人はもうここにいないので、コミュニティに助けを求めています。

私の観察:

  • クライアントの電話は、ほぼ一定の状態で、複製の呼び出し、失敗、複製の再呼び出し、失敗などを繰り返しているようです。サーバーからの新しいデータの取得に失敗するだけでなく、バ​​ッテリーを大量に消費します。パワー。
  • サーバーは目に見えて過負荷になっています。Erlang と Couch は、多くの CPU とメモリを消費しています。
  • サーバーの負担が少ない場合、レプリケーションは正常に機能しているようです。たとえば、CouchDB サービスを再起動した後、レプリケーションはしばらくの間正常に機能します。

私の仮定:

  • 私には、これは負荷分散の問題のように思えます。サーバーがビジー状態になると、より多くのクライアントの複製が失敗し、複製をより頻繁に要求するようになり、問題が悪化します。

私がそれを修正しようとした方法:

  • クライアントの CouchBase "default.ini" ファイルで、クライアントがレプリケーションを呼び出す頻度を制限するために、次のように編集しました。

    • max_replication_retry_count = 1
    • http_接続 = 5
    • 接続タイムアウト = 60000

それにもかかわらず、CouchBase が LogCat 内で絶え間なくレプリケートを試行して失敗しているのを今でも見ることができます。

問題をより効果的に切り分けるために、これのデバッグを開始する方法を誰かが提案できますか? 正しい方向に私を向けますか?...どうもありがとう。


LogCat
09-28 12:48:48.593: I/CouchDB(4468): [info] [<0.8140.0>] Replication"0284a8a927077abfd2b86a2616e07fed"is using:
09-28 12:48:48.593:): 4 つのワーカー プロセス
09-28 12:48:48.593: I/CouchDB(4468): 500 のワーカー バッチ サイズ
09-28 12:48:48.593: I/CouchDB(4468): 5 つの HTTP 接続
09-28 12 :48:48.593: I/CouchDB(4468): 60000 ミリ秒の接続タイムアウト
09-28 12:48:48.593: I/CouchDB(4468): ソケット オプション: [{keepalive,true},{nodelay,false} ]
09-28 12:48:48.593: I/CouchDB(4468): ソース開始シーケンス 4971
09-28 12:48:49.824: I/CouchDB(4468): [info] [<0.8140.0>] ドキュメントfunf_client_to_server_49fd7812-409d-47df-a1cd-888db15a24aeによってトリガーされたレプリケーション0284a8a927077abfd2b86a2616e07fed
09-28 12:48:49.834: I/CouchDB(4468): [info] [<0.8139.0>] <0.8140.0> で新しいレプリケーション0284a8a927077abfd2b86a2616e07fedを開始 ( funf-> https://*****@monarca.dk:5984/monarca_funf/)
09-28 12:48:51.225: E/ CouchDB(4468): [エラー] [<0.8140.0>] ChangesReader プロセスが次の理由で終了しました: {file_corruption,
09-28 12:48:51.225: E/CouchDB(4468): <<"ファイルの破損">>}
09 -28 12:48:51.225: E/CouchDB(4468): [エラー] [<0.8140.0>] レプリケーション0284a8a927077abfd2b86a2616e07fed( funf-> https://*****@monarca.dk:5984/monarca_funf/) が失敗しました: changes_reader_died
09-28 12:48:51.245: I/CouchDB(4468): [ info] [<0.8149.0>] エラーのため、 https:// * @monarca.dk:5984/monarca_funf/_revs_diff への POST リクエストを 0.25 秒で再試行しています。
09-28 12:48:51.245: I/CouchDB(4468): [info] [<0.8148.0>] https:// * @monarca.dk:5984/monarca_funf/_revs_diff への POST リクエストを 0.25 秒で再試行していますerror Closing_on_request
09-28 12:48:51.476: E/CouchDB(4468): [エラー] [<0.298.0>] レプリケーションでエラーが0284a8a927077abfd2b86a2616e07fed発生しました (ドキュメントによってトリガーされましたfunf_client_to_server_49fd7812-409d-47df-a1cd-888db15a24ae): changes_reader_died


問題のレプリケーション ドキュメントは次のとおりです。
{"_id":"funf_client_to_server_49fd7812-409d-47df-a1cd-888db15a24ae","_rev":"825-082674db3441880a23d6b6aa51be7e3e","target":"https:// * @monarca.dk:5984/monarca_funf","continuous" :false,"source":"funf","filter":"monarcaandroid/deletefilter","_replication_id":"3dfdfca7dfd47d9352c9048497660e4c","_replication_state":"error","_replication_state_time":"2012-09-28T12:51: 25+02:00"}


そして、これが複製ドキュメントで参照されている「deletefilter」です。

"function(doc) {\n  return !doc._deleted;\n}"
4

3 に答える 3

0

androidのcouchbase mobileなので、couchdb 1.1くらいか初期のcouchdb 1.2をベースにしていると思います。これは、試した設定 (max_replication_retry_count、http_connections、および connection_timeout) がcouchdb 1.2 リリース バージョンに組み込まれる前の可能性があります。それは単なる推測です。1)couchdb/couchbase のバージョンをアップグレードする(新しいビルドを見つけた場合はお知らせください)、または 2)バックグラウンドで単一のレプリケーションを実行するタイマー タスクを用意することをお勧めします。

于 2012-09-30T05:51:47.753 に答える
0

_replicatorデータベースを複製に使用することをお勧めします。無料でレプリケーションの再試行を行います。レプリケーションを再試行するまでの遅延は指数関数的に増加します。

情報はこちらから

于 2012-10-01T14:29:52.070 に答える