Hi Ermouth, Joan, thanks for suggesting this. It was straight forward to install it, but in the end I didn't manage to visualize any information because the user/role I was mapped to didn't have enough privileges. I tried logging out too, but it doesn't work because the user is taken from the grid certificate provided by the client (something peculiar in my setup).
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. After reading further about it, it could be that the mapReduce functions are slowing everything down, as suggested in this section: https://docs.couchdb.org/en/1.6.1/maintenance/performance.html#builtin-reduce-functions I will learn myself a bit more on this, and check whether anything can be done in native erlang. Thanks for your help so far. Alan. On Wed, May 20, 2020 at 10:57 PM ermouth <[email protected]> wrote: > > Alan, > > latest version of Photon, an alternative admin panel for Couch, shows list > of ddocs with info about data size and disk size. When ddoc indices files > size is much larger than data size, you probably need to compact > viewindices of the ddoc. You can select several design docs at a time, and > compact their indices in a turn just clicking [Compact...] btn. Hope it > might help. > > Btw, Photon UX is very close to Futon. > > https://github.com/ermouth/couch-photon > > ermouth > > > ср, 20 мая 2020 г. в 17:03, Alan Malta <[email protected]>: > > > Hi everyone, > > > > it's been more than a week that I have been debugging a strange > > performance problem with CouchDB; mainly affecting couchdb views. > > > > About my Couch setup, I have one central couch instance and around 5 > > to 15 other instances replicating documents to it. In addition to the > > replication, each of those other couch instances are also running a > > service that posts documents to the central one via '_bulk_docs' API. > > It's important to note that this model is deployed in production for > > many years now. > > > > What started to happen is that the indexing of the views became very > > very slow, like < 1k changes within 10min. Making GET calls to the > > views (either with or without reduce function), I also see a poor > > response rate (a few tens kilobytes, either remotely or localhost). > > > > Has anyone ever faced such slowness with CouchDB (views)? Would you > > have any recommendations on where I should start looking and tests to > > be performed? I have already ruled out problems with the virtual > > machine and the hypervisor (load is normal for months). I have also > > already recreated the views from scratch; recreated the database from > > scratch (dumping deleted docs). I have also created a view to see > > whether there were any large documents, and the biggest one is only > > .5MB. > > > > When I replicated the database from scratch today, CouchDB indexed > > around 1.5M docs in an hour or so; while it's been the last 2h > > indexing 26k changes to the database... > > > > Any help or pointers would be very much appreciated here. > > Thanks, > > Alan. > >
