b*******s
发帖数: 5216 | 1 Goroutines
They're called goroutines because the existing terms—threads, coroutines,
processes, and so on—convey inaccurate connotations. A goroutine has a
simple model: it is a function executing concurrently with other goroutines
in the same address space. It is lightweight, costing little more than the
allocation of stack space. And the stacks start small, so they are cheap,
and grow by allocating (and freeing) heap storage as required.
Goroutines are multiplexed onto multiple OS threads so i... 阅读全帖 |
|
w********m
发帖数: 1137 | 2 哦，我大概知道原因了。
你可能把server对client的读和写放到一个goroutine了，造成blocking。
每个client应该对应server上面两个goroutine，一个读，一个写。
这样server上minimal goroutine number应该是2*N + 2
N是client的数目。
还要有个main goroutine和一个scheduler。
goroutine很便宜，一个只要2KB内存，多开几个无妨。 |
|
S*A
发帖数: 7142 | 3
我 double check 了一下，已经是读和写分别一个 goroutine 了。
所以不是这个问题。
多开几个无妨，我也是这么想的。但是实际情况不是这样。
我感觉上是多开了 goroutine 会影响schedule 到那个
tcp socket 的相应时间。或者有什么其他的bug。
在了解到一些 goroutine 的内部实现细节以后，例如是
基于 non blocking io 这些。 我越来越觉得这个 goroutine
对付简单情况可以，很多 goroutine 不太能 scale 的。 |
|
S*A
发帖数: 7142 | 4 内存还是大大的有。其他还能有什么资源。
感觉是 go 的编程模式的问题。
比较正规的解法是用 epoll 这种 call back 的方式来处理的。
go 用那个 non blocking mode IO 和goroutine 在即将要
block 的时候才去换goroutine。这种方式上不了比较大规模。
anyway。 网上看来有不少分享都是要上大并发要去掉 goroutine。
这个我感觉应该是 go 本身编程模式的问题。go 自己的 scheduler
并不适合干大并发。你想想每个 goroutine 都有自己的context
内存。连接多了这个很费的。 |
|
S*A
发帖数: 7142 | 5 buffer 足够，内存不是问题。
就算你有足够buffer，网卡不是一次能传完的，
还是回到调度问题。如果你有很多 goroutine，
如何在几万个goroutine 里面调度不是一个容易的
事情。
go 的编程模式是让 goroutine 写成连续的一个
类似进程的东西。这个方式看来是没法上大规模的。
你看看 go 为什么拒绝提供 net 上的 epoll API。
就是觉得 epoll 这种 event + callback
驱动 IO 的方式和 go 的精髓不合。
我觉得是个 goroutine 调度问题，你一定要说是
channel 问题我也没法。你去仔细看看我提供的
那个连接，连接里有提到这个问题和解决的。非常印证
我的直观理解。 |
|
S*A
发帖数: 7142 | 6 这个不是我混淆了，我很清楚goroutine 和channel 两回是。
是前面那位一定要拿 channel 数和 goroutine 的关系来说。
我是想说，这个 channel 和 goroutine 关系不是问题。
关键问题是 goroutine 对应 tcp 连接这个不能 1：1.
1：1 的话上量会出问题的。 |
|
S*A
发帖数: 7142 | 7 哦，如果 epoll 不是 go 做的话，如何交接收到的数据是个问题。
需要按照 go 的规则把收下的数据包打包成 go 的 object。
这个如果 epoll 用 go 来写也需要有同样的过程。
所以我现在看看纯 go 来写 epoll call back如何。
上层用 goroutine 来写是没有问题的。但是同样要限制数目。
goroutine 太多其实没有帮助，只能帮倒忙。因为你的 CPU
个数是有限的，一次能真正同时做的东西有限。多出来的
goroutine 之间的调度是浪费。相比之下，call back 的代
价要小很多，没有切换 context 的问题。没有 goroutine
霸占的 context 的内存问题。 |
|
S*A
发帖数: 7142 | 8 理论上用 goroutine 来替代 thread，
用 channel 协助调度是比较干净的一个模型。
但是实际中发现，如果每个 tcp 连接都是一个
goroutine 来处理，如果同时很多个 tcp 连接
同时并发发送数据，很容易就出现 tcp connection
reset。
google 了一下，发现有其他人抱怨类似的问题。
解决办法是用什么work pool 之类的限制并发
同时发送的数量。如果这么搞反而就比较麻烦了，
因为 goroutine 本来就是隔离了和 thread
这些打交道，用 work pool 这些其实就是变相
用 thread 来调度。隔靴挠痒的感觉。
求指点。
另外一个发现的问题是，go 貌似不能直接用 raw
data。从网络来到数据包需要经过 decode 过程
才能包裹到 go 的 struct。这个过程需要一个一个
byte shift 到其他类型的type 里面去。不知道
有没有其他好点办法.反正用 native go 貌似没
有好办法的，因为要 box go 的类型。低带宽的数据
可以这么搞，高带宽的数据这么过一下手会浪费一些
CPU。 |
|
|
S*A
发帖数: 7142 | 10 channel 不是问题，每个 tcp socket 要对应一个 goroutine。
因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
来 block。感觉这个 goroutine 对应一个 socket 是不能上
大并发的。
network IO 是不可能耗尽的，就是 blocking 慢而以。
内存应该还好。
发。 |
|
|
s********k
发帖数: 6180 | 12 感觉你有点混淆了：goroutine和channel是两回事，理论上你开无数个goroutine只要
没有数据交互一个channel不开都可以，当然实际上基本不可能。你的问题是一个TCP连
接对应一个goroutine，不应该是channel。
所以channel的数量也不是关键，关键是channel的buffer size，看我上一个回复，如
果有producer consumer问题，你开很多channel，但是每个channel都没有buffer，那
还是会blocking。 |
|
S*A
发帖数: 7142 | 13
epoll
是一定更差啦。关键是差的比较远，我有点吃惊而以。
IO
goroutine 太多 go 自己调度不过来，这个的确会是个问题。
go
go 1.9 的 epoll不知道啊，新的 goroutine 可能已经用 epoll了，
但是还是不如直接控制 epoll + callback。 goroutine 太多我意识到
是个无解的问题。
go 可以直接 system call 调用的。可以用全部 go 来做。
如果我 C 写底层我就直接 C 全部橹了，只考虑 Linux epoll 其实不复杂，
我写过。复杂的是想上面包各种各样东西兼容 kqueue 这些。 |
|
d***a
发帖数: 13752 | 14 我的两分钱如下： :-)
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
futex调用。
我说的不一定对。
JVM
herd |
|
d***a
发帖数: 13752 | 15 我的两分钱如下： :-)
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
futex调用。
我说的不一定对。
JVM
herd |
|
w********m
发帖数: 1137 | 16 Java当青年程序员容易。Leetcode刷刷就可以上路了。
混上老年程序员不容易，要10000小时定律。
问问concurrency，大部分人不知道，只会用轮子。
什么自旋，悲观乐观锁跟天书一样。
所以就跟二爷说的，那一波过去了。
好比火车跑了，把我们这写老帮菜丢在车站了。
Go好啊，一进门就是concurrency.
每个http request都是一个Goroutine。
Goroutine就是map.
Channel就是reduce。
一张一弛，一看就会了。
所以想当老年程序员，go挺好的。
另外，不当老年程序员，当独立程序员，go也好啊。
Wdong这种自己折腾服务器的大牛太少了。
都是买vps。现在内存就是贵啊。
Go的一个Goroutine 2kb起步。
Java的一个thread 2MB。
差正好1000倍。
所以上go就是省钱。 |
|
|
l**********n
发帖数: 8443 | 18 I missed goroutines. what is goroutine? what is a fiber? |
|
h*i
发帖数: 3446 | 19 core.async可以block，也可以不block，用户自己选择，这是优点不是缺点啊。
在不block的时候，core.async的实现和Go里面的goroutine的实现的几乎是一样的，都
是把状态park在适当的地方，等数据来了把context换过来，继续走。而且数据结构都
是追求lightweight, core.async用一个mutable array, goroutine用一个stack, 我没
看出来性能能够如何不同。
async没有什么magical的，就是个语言内部实现的context switch，不用OS的那一套而
已，这样可以更加lightweight。 |
|
h*i
发帖数: 3446 | 20 这只能说明goroutine 适用范围小，要求driver必须是nonblocking的,我问的是，what
if driver是blocking的？你可能回答，go的driver都是基于fiber的。我说，这不就
是limitation么？
core.async不管下面是什么，多线程也好(Java),单线程也好（JavaScript),甚至fiber
也好，对用户来说是透明的，我不需要关心，我一样用，得到一样的async的功能。这
样的好处是巨大的，比如在浏览器端，core.async让clojurescript完全脱离了
callback hell。
至于下面的机制不同，context switch效率不同，这不是废话么，谁都知道。一般来说
，用户更关心能不能的问题，＂core.async不管什么环境都能，goroutine 只能在go环
境里能，所以core.async更好＂。
无论如何，"core.async is just a toy" is nonsense.
★ 发自iPhone App: ChineseWeb 8.6 |
|
|
S*A
发帖数: 7142 | 22
我知道这个 ：-），不是这个问题。
发送的不需要交互，拿到新的 message 需要尽快 publish 给所有其他的 client 。
client 会根据收到的东西发回一个 reply message。这个 reply message
需要有点交互，例如 server 端 update 某些信息要上锁这些。
可以用 Go 自己做 epoll + event。我正在实验。我已经看出来会比
goroutine 好很多。
直接用 goroutine 1：1 socket 不适合做大并发，这个是我想讨论的事情。
其实远远没有到大并发简单的就不行了，大家有兴趣可以试试。这个是我用了
了一下 go 觉得比较坑的地方。 |
|
s********k
发帖数: 6180 | 23 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
的目的就是为了给大多数手动觉得麻烦人提供便利
话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
signal去go吗？ |
|
s********k
发帖数: 6180 | 24 我这里比如都是buffered channel，感觉好像wait group和channel差不多，有点疑惑
，我看前面说在不知道channel多少input时候用wait group，但是你在wait group也会
指定add的数量啊。本质上和for loop一个意思。
你的程序结束比如我在这个goroutine开的channel，这个goroutine结束之后channel和
其他variable同等被回收了？ |
|
发帖数: 1 | 25 SO_REUSEPORT是Linux Kernel 3.9里面新加的，可以让多个process共享socket，减少
socket accept上的瓶颈。
golang不支持这个我挺吃惊的。NGINX 1.9就有了。对于业务繁重的HTTP服务器，或者
压力测试，SO_REUSEPORT必不可少。
感觉默认的goroutine blocking工作模式效率比non-blocking event poll低很多，虽
然编程更容易。
难道后端不应该都是non-blocking模式么？还有goroutine概念，给硬件加速带来负担
。不知道各种网卡traffic steering技术对golang有没有效果。 |
|
|
发帖数: 1 | 27 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line miss
和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试，
估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应
该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算
少的。
The main concepts in Go runtime are:
M - OS thread (Machine).
P - Logical CPU (Processor), there are exactly GOMAXPROCS P's.
G - Goroutine.
Netpoll - network poller (epoll descriptor).
RunQ - scheduler queue with runnable G's.
MHeap - global memory allocator state (contains central caches and free
spans)... 阅读全帖 |
|
s********k
发帖数: 6180 | 28 我觉得你是不是可以换个方法实验
你目前的实验室基于一个200+核心直接run bare golang的http server？但是实际上很
多golang打包container的都是基于pod的，可以试一下k8s，比如你开# of core 个VM
？然后pin每个VM到一个core成为一个node，再每个node上再开2个pod？
所以你原来的测试是1个http server 开N个goroutine，现在变成每个pod上开一个http
server，就应该是1个http server开N/200/2个goroutine
这样的scheduler问题就完全变了。不知道效果如何
miss |
|
发帖数: 1 | 29 感覺golang的默認goroutine設計模式有問題，下面是golang http microbenchmark的
perf report：
60.24% [kernel] [k] arch_cpu_idle
6.43% [kernel] [k] _raw_spin_lock
4.40% http [.] runtime.runqgrab
2.19% http [.] runtime.findrunnable
感覺golang如果有很多goroutine和thread，大部分時間都會用在runtime.runqgrab上
，然後runtime.futex會過載，導致系統60% CPU都是idle |
|
发帖数: 1 | 30 所以我前面提到的golang性能的第二個問題不是algernon獨有，也是golang區別於c的
最大特點：goroutine。目前golang最多能有一千萬併發goroutines，換成內存也就是
幾十GB，對於AWS上的只有幾十GB的VM小系統估計夠用了，但是對於多路1TB共享內存大
系統，golang目前沒有NUMA調度架構顯然不行。
測試golang http，其實變成了測試Linux sys_futex()，唉。。。 |
|
发帖数: 1 | 31 http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
語言的根子。 |
|
发帖数: 1 | 32 SO_REUSEPORT是Linux Kernel 3.9里面新加的，可以让多个process共享socket，减少
socket accept上的瓶颈。
golang不支持这个我挺吃惊的。NGINX 1.9就有了。对于业务繁重的HTTP服务器，或者
压力测试，SO_REUSEPORT必不可少。
感觉默认的goroutine blocking工作模式效率比non-blocking event poll低很多，虽
然编程更容易。
难道后端不应该都是non-blocking模式么？还有goroutine概念，给硬件加速带来负担
。不知道各种网卡traffic steering技术对golang有没有效果。 |
|
|
发帖数: 1 | 34 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line miss
和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试，
估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应
该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算
少的。
The main concepts in Go runtime are:
M - OS thread (Machine).
P - Logical CPU (Processor), there are exactly GOMAXPROCS P's.
G - Goroutine.
Netpoll - network poller (epoll descriptor).
RunQ - scheduler queue with runnable G's.
MHeap - global memory allocator state (contains central caches and free
spans)... 阅读全帖 |
|
s********k
发帖数: 6180 | 35 我觉得你是不是可以换个方法实验
你目前的实验室基于一个200+核心直接run bare golang的http server？但是实际上很
多golang打包container的都是基于pod的，可以试一下k8s，比如你开# of core 个VM
？然后pin每个VM到一个core成为一个node，再每个node上再开2个pod？
所以你原来的测试是1个http server 开N个goroutine，现在变成每个pod上开一个http
server，就应该是1个http server开N/200/2个goroutine
这样的scheduler问题就完全变了。不知道效果如何
miss |
|
发帖数: 1 | 36 感覺golang的默認goroutine設計模式有問題，下面是golang http microbenchmark的
perf report：
60.24% [kernel] [k] arch_cpu_idle
6.43% [kernel] [k] _raw_spin_lock
4.40% http [.] runtime.runqgrab
2.19% http [.] runtime.findrunnable
感覺golang如果有很多goroutine和thread，大部分時間都會用在runtime.runqgrab上
，然後runtime.futex會過載，導致系統60% CPU都是idle |
|
发帖数: 1 | 37 所以我前面提到的golang性能的第二個問題不是algernon獨有，也是golang區別於c的
最大特點：goroutine。目前golang最多能有一千萬併發goroutines，換成內存也就是
幾十GB，對於AWS上的只有幾十GB的VM小系統估計夠用了，但是對於多路1TB共享內存大
系統，golang目前沒有NUMA調度架構顯然不行。
測試golang http，其實變成了測試Linux sys_futex()，唉。。。 |
|
发帖数: 1 | 38 http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
語言的根子。 |
|
发帖数: 1 | 39 我上一個貼提到了golang兩大問題：GOGC和goroutine調度，今天開會同事又發現很多
其他性能問題。
1. encryption(對稱或非對稱)：golang非常慢，比openssl慢10倍不止，因為openssl
寫了很多assembly，尤其在非x86上面特別明顯。
2. string vectorization：libc有很多手寫SSE/AVX優化，對應的golang根本全靠編譯
器，在x86和非x86上表現都很差，也是10倍不止。
3. 沒有標準threadlocal，這個Cpp14也有很多優化，多核性能差距明顯。
4. golang周邊庫不如cpp穩健，尤其和folly、abseil比較
5. golang不支持硬件加速，因為目前很多硬件廠商都倒向LLVM，它彌補了部分GCC、
ICC的弊病，留給golang的市場空間變小了
結論：
a. 嚴肅項目（尤其跟性能相關的後台項目）還是cpp天下
b. 深度學習應該使用python和cpp
c. 刷題最好用cpp或java，未來cpp/java都會有fiber，比goroutine強
總之golang看起來很好，但是實際性... 阅读全帖 |
|
发帖数: 1 | 40 我上一個貼提到了golang兩大問題：GOGC和goroutine調度，今天開會同事又發現很多
其他性能問題。
1. encryption(對稱或非對稱)：golang非常慢，比openssl慢10倍不止，因為openssl
寫了很多assembly，尤其在非x86上面特別明顯。
2. string vectorization：libc有很多手寫SSE/AVX優化，對應的golang根本全靠編譯
器，在x86和非x86上表現都很差，也是10倍不止。
3. 沒有標準threadlocal，這個Cpp14也有很多優化，多核性能差距明顯。
4. golang周邊庫不如cpp穩健，尤其和folly、abseil比較
5. golang不支持硬件加速，因為目前很多硬件廠商都倒向LLVM，它彌補了部分GCC、
ICC的弊病，留給golang的市場空間變小了
結論：
a. 嚴肅項目（尤其跟性能相關的後台項目）還是cpp天下
b. 深度學習應該使用python和cpp
c. 刷題最好用cpp或java，未來cpp/java都會有fiber，比goroutine強
總之golang看起來很好，但是實際性... 阅读全帖 |
|
m***r
发帖数: 359 | 41 大数据日报 2015-02-02
@好东西传送门 出品, 过刊见
http://bd.memect.com
订阅：给 [email protected]
/* */ 发封空信， 标题: 订阅大数据日报
更好看的HTML版
http://bd.memect.com/archive/2015-02-02/short.html
1) 【Kafka在linkedin里的使用情况以及愿景】 by @湾区日报BayArea
关键词：计算框架, Rao Jun, 流计算
Kafka在linkedin里的使用情况以及愿景 [1] kafka也是搭建scalable的web app的万金
油。看看在linkedin里是怎么用的。
[1] http://wanqu.co/2015-02-02-kafka-linkedin.html
2) 【Spark生态系统解析及基于Redis的开源分布式服务Codis】 by @CSDN云计算
关键词：会议活动, 计算框架, 数据库, Hadoop, Spark, 陈超, 活动, 刘奇
【Spark生态系统解析及基于Redis的开源分布式服务Codis】在第... 阅读全帖 |
|
p*******r
发帖数: 123 | 42 【 以下文字转载自 Programming 讨论区 】
发信人: TeacherWei (TW), 信区: Programming
标 题: 好了，现在可以发布我的发明之一了，物联网App Engine
发信站: BBS 未名空间站 (Wed Nov 18 20:11:59 2015, 美东)
和App Store
介绍：
中文版
http://qwhomeautomation.com/doc.appintro.cn.html
英文版
http://qwhomeautomation.com/doc.appintro.html
简单说明一下：
1. 我这个是完全独立的异步I/O，基本上Node.js的Lua版，也可称Node.Lua
2. 异步太恶心，直接折腾成同步，就是一个Goroutine的Lua版
3. Nest就是我系统的一个App。写一个比Nest更聪明的App也不难。更有趣的是Nest
100多个专利，现在看来都难保。
4. 更深层次的意义我先不说，各位琢磨去吧
5. 我花大本钱专利保护。现在系统可以下载免费使用。只支持Insteon设备啊。愿意其
我们QA的用户多得是。 |
|
J*****c
发帖数: 276 | 43 快速看了一下GO，它可以直接做任务并行，类似storm的spout和bolt，只是它将
goroutines和channel做到GO的核心中了，没有基于JVM。现在还不知道GO如何实现
spark的RDD？ |
|
v*s
发帖数: 946 | 44 俺还挺喜欢那个goroutine的。 他的select ／ chan 我觉得好用，和Erlang很像。 |
|
z***y
发帖数: 42 | 45 谢谢分享。
我最近也在学Go，Go的语法其实比较简单，Language specification基本上一天就看完
了。语法很接近C，但又不用自己管理内存，对于系统程序员简直是太好了。我觉得一
个编程语言，尤其是系统语言，应该用非常简洁的语法，提供程序员最需要的功能，以
最大程度上提高编程的效率。Go在C的基础上添加了很多其他语言中的精华，感觉我有
了我所需要的东西，但又不像很多其他语言那样，需要我改变思维方式，比如erlang,
clojure等等。
我觉得Go对于我这样的系统程序员来说，最好的特点有这么几个：
1 static type。dynamic type实在不是用来编大规模系统程序的好方法。
2 interface。没有了Object oriented那样的强加的体系，接近于duck typing，但又
是static的。
3 function as a type
4 GC。不用说了。
5 multiple return values。也不用说了。
6 native的collect types, list, map, etc. 还有array slicing
7 gorou... 阅读全帖 |
|
z***y
发帖数: 42 | 46
只是用6*系列的Go自己的fast compiler的时候才要用binding，原因就是因为multiple
return values，所以calling convention不一样。如果用gccgo，你就可以自己直接连。
但是gccgo还有一些feature不支持。尤其是goroutine还是one-to-one map到system
thread
上。不过performance是gccgo编译出来的好一些。当然compilation speed就差一点了
。看你什
么需要。看你的情况，可以直接用gccgo。 |
|
v*s
发帖数: 946 | 47 貌似他那个goroutine 并发编程的概念还是很简单有趣的。 |
|
|
p*****2
发帖数: 21240 | 49
可以写脚本在browser里运行。而且实现了Go语言的goroutine和channel.我正在用，感
觉挺爽。 |
|
