I've heard a couple of folks pontificate on compaction in its own process as well, given it has such a high impact on GC. Not sure about the value of individual tables. Interesting idea though.
On Fri, Feb 23, 2018 at 10:45 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: > I've given it some thought in the past. In the end, I usually talk myself > out of it because I think it increases the surface area for failure. That > is, managing N processes is more difficult that managing one process. But > if the additional failure modes are addressed, there are some interesting > possibilities. > > For example, having gossip in its own process would decrease the odds that > a node is marked dead because STW GC is happening in the storage JVM. On > the flipside, you'd need checks to make sure that the gossip process can > recognize when the storage process has died vs just running a long GC. > > I don't know that I'd go so far as to have separate processes for > keyspaces, etc. > > There is probably some interesting work that could be done to support the > orgs who run multiple cassandra instances on the same node (multiple > gossipers in that case is at least a little wasteful). > > I've also played around with using domain sockets for IPC inside of > cassandra. I never ran a proper benchmark, but there were some throughput > advantages to this approach. > > Cheers, > > Gary. > > > On Thu, Feb 22, 2018 at 8:39 PM, Carl Mueller <carl.muel...@smartthings.com> > wrote: > >> GC pauses may have been improved in newer releases, since we are in 2.1.x, >> but I was wondering why cassandra uses one jvm for all tables and >> keyspaces, intermingling the heap for on-JVM objects. >> >> ... so why doesn't cassandra spin off a jvm per table so each jvm can be >> tuned per table and gc tuned and gc impacts not impact other tables? It >> would probably increase the number of endpoints if we avoid having an >> overarching query router. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
