我是新來的沙發，並繼承了上約70客戶端Android使用CouchBase移動（開發人員預覽版V2.0）一箇中型項目手機（所有HTC Desire S），然後與主CouchDB服務器同步。CouchBase複製負載平衡 - 如何降低客戶端的複製嘗試的頻率上失敗
不幸的是，建立系統的人不在這裏，所以我正在尋求社區的幫助。
我的觀察：
- 客戶端的手機似乎是在調用複製，那麼失敗的幾乎恆定的狀態，然後再調用複製，失敗，等等。除了未能從服務器拉下新的數據，它也消耗了過多的電池電量。
- 服務器顯着負擔過重。 Erlang和Couch吸收了大量的CPU和內存。
- 當服務器負擔較輕時，複製似乎正常工作。例如，在重新啓動CouchDB服務之後，複製工作很好。
我的假設：
- 對我來說，這聞起來像一個負載均衡的問題。隨着服務器變得繁忙，越來越多的客戶端複製失敗，然後只是更頻繁地請求複製，使問題變得更糟。
如何我試圖修復它：
在客戶端上的CouchBase「對Default.ini」的文件，我已經編輯在嘗試以下，以限制如何通常客戶端調用複製。
- max_replication_retry_count = 1
- http_connections = 5
- connection_timeout = 60000
儘管如此，我仍然可以看到CouchBase犁走在logcat中，不斷嘗試和失敗，以複製。
任何人都可以建議如何我可能會開始調試這一點，從而更有效地隔離問題？把我指向正確的方向？...非常感謝。
這裏的複製錯誤從logcat的
12月9日至28日：48：48.593：I/CouchDB的（4468）：[信息] [< 0.8140.0>]複製"0284a8a927077abfd2b86a2616e07fed"是使用：
09-28 12：48：48.593：I/CouchDB的（4468）：4工作進程
09-28 12時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
12月9日至28日：48：49.824：I/CouchDB的（4468）：[信息] [< 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>>]開始新的複製0284a8a927077abfd2b86a2616e07fed在< 0.8140.0>（funf - >https://*****@monarca.dk:5984/monarca_funf/）
12月9日至28日：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）：[error] [< 0.8140。 0>]複製0284a8a927077abfd2b86a2616e07fed（funf - >https://*****@monarca.dk:5984/monarca_funf/）失敗：changes_reader_died
十二月9日至28日：48：51.245：I/CouchDB的（4468）：[信息] [< 0.8149.0>]重試POST請求到https：// * @ monarca.dk：5984/monarca _funf/_revs_diff在0.25秒內由於錯誤closing_on_request
09-28 12：48：51.245：I/CouchDB（4468）：[info] [< 0.8148.0>]重試POST請求到https：// * @ monarca.dk:5984/monarca_funf/_revs_diff 0.25秒內由於錯誤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」， 「目標」：「https：//開頭* @ monarca.dk：5984/monarca_funf 「 」連續「：假， 」源「： 」funf「， 」過濾器「： 」monarcaandroid/deletefilter「， 」_ replication_id「： 」3dfdfca7dfd47d9352c9048497660e4c「， 」_ replication_state「： 」錯誤「， 」_ replication_state_time「：」 2012- 09-28T12：51：25 + 02：00" }
而這裏的 「deletefilter」 由複製文檔引用。
"function(doc) {\n return !doc._deleted;\n}"
你有沒有得到這個工作？ –