Hi all, I just wanted to update this thread to say that I _sort of_ found what was causing the overall slowness in CouchDB. I have found in the frontend logs that we had one single client making 150 concurrent requests to our service, each of those requests can map to 1 or many (~20) GET couch views. This, in addition to the high number of documents (~3M), again in addition to all the other clients as well, was causing couch to not perform well its tasks.
Thanks to all of you that helped me investigating this issue. Best, Alan. On Sun, May 24, 2020 at 8:16 PM Alan Malta <alanma...@gmail.com> wrote: > > Hi Joan, all, > > prometheus node metrics suggests a memory consumption of ~90% (around > 55GB), however I have two other CouchDB instances > - in different nodes - that have the same memory pressure, and they > work just fine. Load of the node is pretty low, usually between 2 > and 4 (for a 16VCPUs node). About swapping, it shouldn't be a problem > because those nodes don't really have a swap partition (?). > > On a slightly different subject. I read that separating couch views > into different design docs provide a boost in performance, because > this forks a different process for each design doc. Is it also true if > all the views in a given database/ddoc are written in erlang instead > of javascript? > > Thank you very much. > Alan. > > On Fri, May 22, 2020 at 12:57 AM Joan Touzet <woh...@apache.org> wrote: > > > > Hi Alan, > > > > On 2020-05-21 18:41, Alan Malta wrote: > > > Joan, indeed I had around 60 documents with conflicts. I managed to fix > > > them and I no longer see any conflicts. Low quality performance remains > > > though. > > > > Double-check that you're not running out of memory (swapping to disk) or > > CPU (lots of process churn). The hypervisor may not be telling you what > > you need to know here - try an in-guest tool like top, atop, or s-tui. > > > > -Joan
