|
s********k
发帖数: 6180 | 2 赞资料
现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
。搞定这个绝对大包不愁啊
magagop 你底层系统经验这么好，绝对应该搞搞这个 |
|
|
y*j
发帖数: 3139 | 4 关于Golang, 我感觉是CPP的一个简化版，但是砍得太猛了，也许留下stack 上的自动
变量会好一些。至少减轻GC的压力。
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百
度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
|
|
发帖数: 1 | 5 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。 |
|
|
|
发帖数: 1 | 8 这里面讲了，为什么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)... 阅读全帖 |
|
发帖数: 1 | 9 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。 |
|
y*j
发帖数: 3139 | 10 把GC完全关掉，时间一长，非耗尽内存空间不可。
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
还能非
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
|
|
b*******s
发帖数: 5216 | 11 golang + docker may be the best practice |
|
y*j
发帖数: 3139 | 12 Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。
: 俺一直都说，C#是最好的语言。。。。
|
|
发帖数: 1 | 13 CSharp在Linux、非x86架构下有性能很好的编译器和库么？
听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
要。 |
|
发帖数: 1 | 14 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。 |
|
y*j
发帖数: 3139 | 15 我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
化。
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
|
|
d***a
发帖数: 13752 | 16 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。 |
|
s********k
发帖数: 6180 | 17 用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
stream好用啊 |
|
s********k
发帖数: 6180 | 18 page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？
害。 |
|
s********k
发帖数: 6180 | 19 如果本来就是在VM上面再加pod上运行container，这个NUMA的作用还会很大吗？因为没
法控制底层的OS，golang也很难做好scheduler把？
miss |
|
s********k
发帖数: 6180 | 20 我觉得你是不是可以换个方法实验
你目前的实验室基于一个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 |
|
y*j
发帖数: 3139 | 21 看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
害。
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
更厉害。
|
|
d***a
发帖数: 13752 | 22 从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。 |
|
d***a
发帖数: 13752 | 23 是的，不过如果把GC关掉长时间运行下去，page fault会增加的。
miss |
|
s********k
发帖数: 6180 | 24 哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个 |
|
发帖数: 1 | 25 .NET Core 2目前只支持Windows下的arm64，等Linux下也有arm64再開始轉吧。
Mono支持Linux的arm64，但性能應該不行（跟gcc 7.2比） |
|
发帖数: 1 | 26 我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
docker和k8s對非x86的支持也不是很好。
虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
VM
http |
|
s********k
发帖数: 6180 | 27 对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
但是很少golang是在bare的单机上运行，大部分都是distributed的VM上 |
|
T********i
发帖数: 2416 | 28 其实所谓云架构，大多数是没啥必要的。
VM慢了一个数量级以上，无论如何都不能justify。
被人收割骗钱而已。 |
|
p*u
发帖数: 2454 | 29 云本来就是为了节省IT support的costs，不是提高性能。 |
|
s********k
发帖数: 6180 | 30 追求性能肯定要自己做，但是大部分应用上云架构主要是方便，开启服务，scale，
monitor，啥都方便，等到服务做大了，再专门自己搞DC做 |
|
m*****n
发帖数: 3575 | 31 你和软件工程师只有一个本质差别：
你不掌握生产资料，所以只能被剥夺剩余价值
卡尔 马克思 |
|
发帖数: 1 | 32 不明白。软件工程师不是也在被剥夺剩余价值？
本来软件既是生产资料又是劳动产出，结果给来了个开源。
唉唉唉 |
|
发帖数: 1 | 33
你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司 |
|
f******2
发帖数: 2455 | 34 开源是牛逼但不被承认的社会底层的唯一出路，类似十月革命掀桌子
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
|
|
|
m*****n
发帖数: 3575 | 36 R就是这么搞的
一边开源
一边弄个收费高级版
还有Qt系列也是如此 |
|
b******t
发帖数: 9 | 37 algernon三年四百多个星的野鸡库也敢用
想用go webserver， 试试caddy |
|
|
发帖数: 1 | 39 IO虛擬化目前只有intel的vt-d、sr-iov、apic-v做得很好，其他非x86架構都不行，因
為軟件問題。別看白皮書介紹得簡單，裡面非常複雜，非常不好做，坑特別多。性能只
有xeon可以接近裸機，這就是xeon佔領99.9%市場的原因，amd都不行。
是I |
|
w**z
发帖数: 8232 | 40 现在有自己DC的公司已经没几个了。以后也不太会有新的公司用自己DC了 |
|
s********k
发帖数: 6180 | 41 做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在cloud
上，比如netflix，但是99%公司还没到追求极致性能就死掉了 |
|
w**z
发帖数: 8232 | 42 你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
，除了 uber, 都在云上。
：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
cloud
：上，比如netflix，但是99%公司还没到追求极致性能就死掉了 |
|
|
w**z
发帖数: 8232 | 44 that was a bold move.
During its early years, Dropbox ran its entire operation on Amazon’s cloud
computing service. But more recently it has moved much of its
infrastructure off AWS to cut down on costs. The company said that in 2016,
it was able to shrink its cost of revenue by $35.1 million as part of its
AWS migration, which it refers to as “Infrastructure Optimization.” As
tech publication GeekWire notes, the data center move help saved
Dropbox about $75 million over a two-yea... 阅读全帖 |
|
发帖数: 1 | 45 感覺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 | 46 在runtime/proc.go裡面有很多lock(&sched.lock)，
例如把goroutine放到global runq裡面就需要lock
func goschedImpl(gp *g) {
status := readgstatus(gp)
if status&^_Gscan != _Grunning {
dumpgstatus(gp)
throw("bad g status")
}
casgstatus(gp, _Grunning, _Grunnable)
dropg()
lock(&sched.lock)
globrunqput(gp)
unlock(&sched.lock)
schedule()
}
sched是runtime2.go裡面的一個全局變量
var (
allglen uintptr
allm *m
... 阅读全帖 |
|
发帖数: 1 | 47 所以我前面提到的golang性能的第二個問題不是algernon獨有，也是golang區別於c的
最大特點：goroutine。目前golang最多能有一千萬併發goroutines，換成內存也就是
幾十GB，對於AWS上的只有幾十GB的VM小系統估計夠用了，但是對於多路1TB共享內存大
系統，golang目前沒有NUMA調度架構顯然不行。
測試golang http，其實變成了測試Linux sys_futex()，唉。。。 |
|
发帖数: 1 | 48 看清我的結論：性能差別10倍不止，不是10%，如果是50%，我都會說golang很好。但是
差距1000%，我就呵呵了。
LVS |
|
f*******t
发帖数: 7549 | 49 别钻牛角尖了，找到一个特殊的应用说性能差10倍以上，作为技术研究是好的，但没有
实际意义。用Go写backend service的公司很多，碰到性能瓶颈，总会有fix或者
workaround。如果真的需要10倍性能，而Go无论如何都达不到的，就换更合适的语言写
对应的模块唄。 |
|
发帖数: 1 | 50 http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
語言的根子。 |
|
