How many views do you have per db? Remember that each view will use the
same 'q' value as the database. A single q=8 database with ~30 active
views will use
1 db + 30 views = 31 * 8 shards = 248 shards per node
248 * n=3 replicas = 744 shard replicas across 3 nodes
There is absolutely nothing wrong with increasing your limit on file
descriptors to a few hundred thousand - Couch can handle this.
If your databases are that small, recommend changing your default 'q'
value to 1, and this will cut your file handle number by 8. 30 views
in a single database will result in 31 shards.
As for the big shards...are you deleting a lot of documents? You might
have a runaway problem with tombstones. `GET /{db}` will give you these
statistics.
-Joan
----- Original Message -----
> From: "Mike Ray" <[email protected]>
> To: [email protected]
> Sent: Friday, September 28, 2018 7:46:45 AM
> Subject: Troubleshooting emfile, descriptors and shards
>
> Env:
>
> CouchDB, NodeJS, Nano on Debian 8
> ~30 DBs with identical design docs, ranging from 5 docs to 3000
>
> I’ve been working with CouchDB for a while in development, and now
> I’m scaling up for production I’m hitting issues.
>
> Specifically, my shards and file descriptors seem to be spiralling
> out of control.
>
> No doubt it’s something in my code rather than an issue with CouchDB
> per se, but I don’t see a way of finding out what’s going on. It’s
> not relative to the number of docs, but using prometheus I can see a
> couple of the DBs are hitting several thousand allocated file
> descriptors. I then hit ‘emfile’ errors (for which I’ve increased
> the available as per documentation, but I guess this is a temporary
> fix at best, as things grow). Additionally, shards grow to crazy
> sizes, and compaction does little to fix the problem. The only
> solution is to replicate the DB to a temp DB, then destroy and
> replicate back.
>
> How can I debug this? And, is there any way of writing middleware for
> Nano during the ExpressJS request so I can see what’s going on?
>
>
