Mă ocup de această problemă de câteva săptămâni.
Am urmatorul scenariu:
couchdb2.3.1-A <===> couchdb2.3.1-B <===> couchdb3.1.1-A <===> couchdb3.1.1-B
Unde <===> reprezintă două replicări de tip pull, câte una configurată pe fiecare parte. adică: couchdb1 trage de la couchdb2 și invers.
Couchdb rulează în containere docker
Dacă se face o scriere la couchdb2.3.1-A, trebuie să treacă prin toate serverele până când ajunge la couchdb3.1.1-B.
Toate au un HDD exclusiv. Couchdb nu partajează discul cu niciun alt serviciu.
couchdb2.3.1 A și B nu ai nicio problema.
couchdb3.1.1-A a început treptat să crească latența discului în timp. Așa că am încetat să-i mai facem cereri de scriere și am început să vorbim numai cu couchdb3.1.1-B. couchdb3.1.1-A încă primește scrieri, dar numai prin protocolul de replicare. Latența discului nu s-a schimbat.
Modificări pe care le-am făcut de când a început problema:
- Nucleu actualizat de la
4.15.0-55-generic la 5.4.0-88-generic
- Actualizat ubuntu de la
18.04 la 20.04
- Șters
_modificări_globale baza de date de la couchdb3.1.1-A
Mai multe informatii:
- Couchdb folosește volume docker local-persist.
- Discurile sunt pentru WD Purple
2.3.1 couchdbs și WD Black pentru 3.1.1 couchdbs.
- Avem o singură bază de date de
88 GiB și 2 vizualizări: una dintre 22 GB si un mic din 30 MB (foarte actualizat)
statistici docker arată că couchdb3.1.1 utilizează multă memorie în comparație cu 2.3.1:
3,5 GiB pentru couchdb3.1.1-A (nu primesc solicitări directe de scriere)8,0 GiB pentru couchdb3.1.1-A (primind atât solicitări de citire, cât și de scriere)226 MiB pentru 2.3.1-A552 MiB pentru 2.3.1-B
- Compactarea bazei de date se execută noaptea. Problema apare doar peste zi, când se fac majoritatea scrierilor.
- Majoritatea configurațiilor sunt implicite.
Graficul latenței de la monitorizarea munin:
latența discului
Orice ajutor este apreciat.
