Enabling GOMAXPROCS for jujud

[Nate Finch]

I think this is a good idea. yes, we'll need some testing to make sure we
don't have races and deadlocks, but Go has a race detector and panics
nicely on deadlocks. Certainly, enabling multiprocessing on the one machine
that is most likely to be a bottleneck to a large system is a worthwhile
goal.  Just because we default to m1.small doesn't mean that that's what
everyone will use (in fact, as we've seen, it definitely is not good enough
for large environments).

I try never to avoid important features because they might be scary.

Also, just for the record, buffered channels will block just like
unbuffered channels once they're full, so you can't count on that saving
you from blocking.  Also why I almost never use buffered channels. They're
actually much more difficult to reason about than unbuffered channels that
just always block.


On Tue, Oct 29, 2013 at 5:33 AM, Andrew Deane <andrew.deane at canonical.com>wrote:

> From my experience we will need to pay attention to the logical flow of
> the application. Its not a simple case of enabling all CPUs. We will need
> to run many tests repeatedly to ensure there are no races or potential
> deadlocks. Unbuffered channels are a particular cause of deadlock.
>
> That said, enabling max procs really is worth all the testing. At my old
> gig, throughput rocketed. I found it best not to take all the available
> CPUs and play nicely with any other processes on the machine. I think
> 2/3rds available CPU was the spot, but that was for a particular workload
> on a particular machine.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131029/eb364bd9/attachment.html>