Any non trivial program is scalable up a certain point. In your code, you may have some contention. It can be physical (CPU, memory, network, disks, etc ...) or logical (mutexes, channels, shared memory, etc ...) If it is not in your own code, then perhaps it may be in the packages you use, including the Go standard libraries or the runtime itself. The exact cause is difficult to guess, that's why profiling is useful.
Also, the Go scheduler is currently not NUMA aware. It does not exploit well the locality in a machine having multiple sockets. On a two sockets box, it is usually more efficient to run two instances of the application. and pin them to their own NUMA node, rather than one single instance sharing all the CPUs. Regards. Didier. On Thursday, November 24, 2016 at 10:02:21 PM UTC+1, 3702...@qq.com wrote: > > today i am testing my service(something like cdn).system is centos > 6.5,memory=32GB,bandwidth=10Gb and 4000 live stream.one mechine is 16-core > cpu and the other is 8-core cpu.the testing result makes me feel > upset,16-core cpu mechine run about 1000% cpu and play is not smooth,but > the 8-core cpu mechine run about 600% cpu and play > smooth!!!!!!!why?????could someone help??????help me!!!! > -- 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.
