1

我在 go 中编写了一个数据移动器。获取位于一个数据中心的数据并将其移动到另一个数据中心。考虑到 go 例程，认为 go 将是完美的。

我注意到如果我有一个运行 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 Gigs Ram、2.3 GHz 处理器上（说 EC2 :P）

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

我认为 go 是为这种事情设计的，还是我对这个应用程序期望太高了？

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

编辑

我想我的问题不够清楚。对不起。我不是要求魔术，我知道计算机对它们的处理能力有限制。所以我会改写。为什么 1 个实例有 1800 个 go 例程！= 9 个实例，每个实例有 200 个线程？与 9 个实例相比，1 个实例的相同数量的 goroutine 的性能显着降低。

4

2 回答 2

2

请注意，goroutines 也仅限于您的本地机器，并且通道本身不支持网络，即您的特定情况可能没有咬 go 的巧克力网站。

另外：您对将（假设）每次传输都扔进 goroutine 有什么期望？IO-Operations 的瓶颈往往是比特撞击金属，即数据物理传输到介质。可以这样想：无论有多少线程或（在这种情况下为 Goroutines）尝试写入网卡，您仍然只有一个网卡。很可能通过许多并发写入调用来达到它只会减慢速度，因为所涉及的开销会增加

如果您认为这不是问题或想要审核您的代码以优化性能，那么 Go 有简洁的内置功能可以做到这一点：分析 Go 程序（官方 Go 博客） 但实际瓶颈仍然可能在您的 Go 程序之外和/或它与操作系统交互的方式。

在没有代码的情况下解决您的实际问题是毫无意义的猜测。发布一些，每个人都会尽力帮助你。

于 2013-08-02T09:54:34.853 回答
1

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

import "runtime"

func main() {
    runtime.GOMAXPROCS(runtime.NumCPU())
}
于 2013-08-02T17:15:34.553 回答