让例程的性能最大化

我写了一个数据移动器。将数据放在一个数据中心并将其移动到另一个数据中心。对于这个给定的例行公事来说，这将是完美的。让例程的性能最大化

我发现，如果我有一个程序运行1800个线程正在传输的数据量是非常低

这里的dstat打印出平均30秒以上

---load-avg--- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- 
1m 5m 15m |usr sys idl wai hiq siq| read writ| recv send| in out | int csw 
0.70 3.58 4.42| 10 1 89 0 0 0| 0 156k|7306k 6667k| 0  0 | 11k 6287 
0.61 3.28 4.29| 12 2 85 0 0 1| 0 6963B|8822k 8523k| 0  0 | 14k 7531 
0.65 3.03 4.18| 12 2 86 0 0 1| 0 1775B|8660k 8514k| 0  0 | 13k 7464 
0.67 2.81 4.07| 12 2 86 0 0 1| 0 1638B|8908k 8735k| 0  0 | 13k 7435 
0.67 2.60 3.96| 12 2 86 0 0 1| 0 819B|8752k 8385k| 0  0 | 13k 7445 
0.47 2.37 3.84| 11 2 86 0 0 1| 0 2185B|8740k 8491k| 0  0 | 13k 7548 
0.61 2.22 3.74| 10 2 88 0 0 0| 0 1229B|7122k 6765k| 0  0 | 11k 6228 
0.52 2.04 3.63| 3 1 97 0 0 0| 0 546B|1999k 1365k| 0  0 |3117 2033

如果我运行的9个实例计划用200个线程每次我看见了更好的性能

---load-avg--- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- 
1m 5m 15m |usr sys idl wai hiq siq| read writ| recv send| in out | int csw 
8.34 9.56 8.78| 53 8 36 0 0 3| 0 410B| 38M 32M| 0  0 | 41k 26k 
8.01 9.37 8.74| 74 10 12 0 0 4| 0 137B| 51M 51M| 0  0 | 59k 39k 
8.36 9.31 8.74| 75 9 12 0 0 4| 0 1092B| 51M 51M| 0  0 | 59k 39k 
6.93 8.89 8.62| 74 10 12 0 0 4| 0 5188B| 50M 49M| 0  0 | 59k 38k 
7.09 8.73 8.58| 75 9 12 0 0 4| 0 410B| 51M 50M| 0  0 | 60k 39k 
7.40 8.62 8.54| 75 9 12 0 0 4| 0 137B| 52M 49M| 0  0 | 61k 40k 
7.96 8.63 8.55| 75 9 12 0 0 4| 0 956B| 51M 51M| 0  0 | 59k 39k 
7.46 8.44 8.49| 75 9 12 0 0 4| 0 273B| 51M 50M| 0  0 | 58k 38k 
8.08 8.51 8.51| 75 9 12 0 0 4| 0 410B| 51M 51M| 0  0 | 59k 39k

平均负载是高了一点，但是关于以后我会担心。虽然网络流量几乎达到了网络潜力。

我在Ubuntu 12.04， 8音乐会公羊， 2.3 GHz处理器（EC2说：P）

另外，我增加了我的文件描述符从1024到10240

我以为去是为这种事情设计的，还是我期待这个应用程序太多了？

有没有什么微不足道的东西我错过了？我需要配置我的系统以最大限度地发挥潜力吗？

编辑

我想我的问题是不够清楚。抱歉。我并不是在追求魔法，我知道电脑对他们所能处理的东西有限制。所以我会改变。为什么1800个例程有1个实例！=每个有200个线程的9个实例？与9个实例相比，1个实例的相同数量的执行例程性能明显降低。

来源

2013-08-01 Jeff

你正在使用什么构建系统（go build，gccgo）？你增加了GOMAXPROCS吗？ http://golang.org/pkg/runtime/只是产卵goroutines不会让你的程序平行。 – LinearZoetrope

@Jeff：在一个问题上抛出更多的线程和/或例程可能是正确的，因为它可能是一个糟糕的主意，也是放慢速度的根源 - 取决于问题及其具体实现。没有“更多的线程 - 更多的吞吐量”的事情。当没有代码可供查看时，您期望从我们那里听到什么？（-1） – zzzz

@Jsor谢谢你的时间。正是我需要的。如果你把它作为答案，我会接受它。此外，谢谢你的礼貌:) – Jeff

您可能必须发布源代码才能获得任何实际输入，但可以肯定的是，您已增加了要使用的cpus数量？

import "runtime" 

func main() { 
    runtime.GOMAXPROCS(runtime.NumCPU()) 
}

来源

2013-08-02 17:15:34 StianE

请注意，goroutines也仅限于您当地的机器，并且渠道不是本地网络支持的，即您的特殊情况可能不是咬牙切齿的巧克力网站。

另外：你期望从投掷（suposedly）每一个转移到一个goroutine？ IO-Operations在位碰到金属时往往会遇到它们的瓶颈，即数据到介质的物理传输。可以这样想：不管有多少线程或（在这种情况下，Goroutine）尝试写入网卡，您仍然只有一个网卡。如果你认为这不是问题或者想要审核你的代码以获得最佳性能，那么去完成内置功能就可以做到了所以：profiling go programs (official go blog) 但是，实际的瓶颈仍然可能在你的程序之外并且/或者它与os交互的方式。

无代码地解决你的实际问题是无意义的猜测。张贴一些，每个人都会尽力帮助你。

来源

2013-08-02 09:54:34 tike

让例程的性能最大化

回答

相关问题