In theory, yes. I've got the same concern - my eventual plan is to launch couch from a "wrapper" process, have that wrapper process catch the expected docker signals - like SIGINT - and then let the wrapper send a shutdown command to couch. It would be pretty fantastic if couch would flush on receiving this signal (or any signal really) - but maybe the erlang of it all makes this difficult...
On Wed, Nov 30, 2016 at 10:48 AM, Daniel Holth <[email protected]> wrote: > Yes, delayed_commits is still false in 2.0. I don't suppose I've ever > noticed any data loss with it turned on in 1.6, but could I expect normal > couchdb 2.0 (or docker-couchdb) restarts to lose the last few seconds of > data? How would I test this? > > On Wed, Nov 30, 2016 at 10:03 AM Peyton Vaughn <[email protected]> > wrote: > > > Hi Daniel, > > Do you have 'delayed_commits' set to true? It's now defaulted to false in > > couch 2.0, but it really causes a pretty hefty performance hit when > > disabled. > > > > Peyton > > > > On Wed, Nov 30, 2016 at 5:57 AM, Daniel Adam <[email protected]> > > wrote: > > > > > Hi, > > > I'm running an index/view re-generation with 10M documents, 10views, > > having > > > 1 node and 8 shards on it. > > > It seems it will take more than 1 day. What are limiting factors for > > that? > > > Looking at perfromance monitoring tools (Task Manager and Process > > > Explorer), it seems neither I/O or CPU is saturated: > > > CPU (8 cores) each core taking <30% its capacity > > > I/O reads ~ 8MB/s > > > I/O writes ~ 1.5MB/s > > > > > > Windows 7 64bit > > > 16GB memory > > > Intel i7-4800 @ 2.7GHz > > > HDD Seagate ST500LM0 > > > > > > Any explanation why the system limits are not being saturated? Seems to > > me > > > the bottleneck is I/O, but the disk is capable of 100MB/s throughput in > > > sequential reads/writes. If the limiting factor is indeed I/O, I assume > > > changing number of shards would not gain much, possibly even 1 shard > > would > > > provide a similar speed. > > > > > > Any way to improve the speed of index rebuild? > > > > > > Thanks, > > > Daniel > > > > > >
