More File-IO, more GOMAXPROCS. On Mon, Sep 4, 2017 at 3:44 AM, rlh via golang-nuts < golang-nuts@googlegroups.com> wrote:
> Without building and measuring it is impossible to know which of these > approaches, or even a third one where you simply run a single instance, is > best for your application. > > Each approach has upsides and downsides. The GC believes GOMAXPROCS and > will uses as much CPU as it believes is available. This can take CPU away > from the other 3 instances. If more CPU is available but the GC doesn't > know about it then those cycles will go unused. > > Build, measure, and figure out why the application is seeing different > performance characteristics. Please report back, 56 HW threads and > 256Gbytes RAM is of considerable interest to many of us. > > > On Thursday, August 31, 2017 at 9:59:59 AM UTC-4, Pradeep Singh 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. > -- *Regards,Linker linlinker.m....@gmail.com <linker.m....@gmail.com>* -- 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.
