Unruly disk usage, and will not shrink

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



Unruly disk usage, and will not shrink



I have about 10 databases in CouchDB, the largest of which is showing about 1MB in Fauxton. Which sounds right, as there are no binaries in it, all just text.



And yet, my Couch data files are 20 Gigabytes!



I have run _compact on each database, which saved me about 5GB (was 25GB!), but that still doesn't explain why they're taking up so much space still.



What can I do to fix this?



EDIT: adding more info following the helpful comments so far (thank you!):



Replication to a new server seems to fix the problem (everything is just a few meg again), for a few days. Then inexplicably the data chomp starts up again. Earlier, I watched it being used heavily, but not taking up any extra space. And then all of a sudden it's off again!



The database sizes in Fauxton remain tiny, it's only the data files / shards that take up the space fauxton info



The documents are mainly things like text messages (received via an API), log files (eg for any given operation, a document exists which contains an array which has events pushed to it) and stuff like that.



Using lots of views (about 8 design docs per db, each with between 1 and 8 views), and one Mango search (which freetext searches the text messages, of which there are 0 in the smallest db, and about 500 in the biggest)



Quite a few of the docs are updated often, and as yet, pretty much nothing is deleted.



No binaries or attachments of any kind. All pure text.





Now at 50GB and spiralling :( Can't believe I can't get any help from anywhere, and no tools to analyze what's happening.
– user4893295
Aug 7 at 10:16





First replicate database to a new one. If this solves the problem it may be an edge case encountered by you only :) If not solved see if you use _local/ documents with a long/bizarre _id. In my case if I had local doc ids with characters outside 0123456789abcdef range, and every update to such document increased db size by approximately 25 MB. Hope this helps.
– bamanow
Aug 9 at 16:37





That sounds like it could be related - can you clarify what you mean by '_local/ documents'?
– user4893295
Aug 9 at 17:10





I meant local documents (documents that are not reicated). _local/ is always a prefix for the _id of such documents
– bamanow
Aug 9 at 20:06





Do what @bamanow suggest with the replication test to make sure that Fauxton is giving you a reasonable estimate of disk usage. Beyond that, are you using views or mango indexes? They take up space also. It would be useful for you to describe your usage of CouchDB, like whether you have a small number of documents that are updated frequently, or a lot of documents that are deleted, or if you use large attachments and if you use views/mango, etc.
– Daniel Paull
Aug 10 at 1:38




1 Answer
1



CouchDB stores the revisions of your documents. You can config the number of revisions stored. It might be possible that your number is insanely high. Check it out. Not sure, just an idea.



Well, you mentioned that you have compacted your db, maybe that would take care of revisions number, not sure.






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard