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 <alanma...@gmail.com>: > 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. >
