Try it out! It would be great if the scheduler and garbage collector could be so good as to making such tricks unnecessary.
On Thu, 31 Aug 2017, 15:59 <raute...@gmail.com> wrote: > Hi Guys, > > So, we wrote a Go service which does some heavy network IO over ZMQ (using > cgo calls). > > Now, we have to put this service on a VM in private cloud which has 56 > cores and 256GB of physical memory. > > I am guessing it is mostly a dual core NUMA Intel Xeon machine with Xen > installed on it. > > We want to horizontally scale the application by launching 4 instances of > this service in this VM. > > We have tested the code for 30K+ QPS on a 16 core EC2 AMI. > > There are two ways we can do it. > > 1. Run 4 instances of the application as it is without changing any > defaults except configuration files and output data folders. > > 2. Run 4 instances of the application after modifying GOMAXPROCS. > - GOMAXPROCS=16 ./run-my-unoptimized-app > > Which of these 2 scenarios would benefits us more in terms of performance. > > Does it makes sense to run all with default GOMAXPROCS value, which would > be 56 for all the 4 instances? > > Or it would be wise to follow option 2 with possibly pinning each to a > range of 16 cores using taskset. > > Would pinning help in second scenario? > > Thanks, > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
