Are you able to share the profile with us? On Monday, 28 November 2016 13:56:08 UTC+11, 3702...@qq.com wrote: > > thanks. > i have checked my code and analyze the cpu prof file for many times.i do > not see any problems. > > 在 2016年11月26日星期六 UTC+8上午2:45:13，Didier Spezia写道： >> >> 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.
