|
s********k
发帖数: 6180 | 2 有几个人能有做出Nginx水平啊，广大人民群众的需求这点少的牛人满足不了啊 |
|
|
|
发帖数: 1 | 5 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b + i))
// scanobject scans the object starting at b, adding pointers to gcw.
// b must point to the beginning of a heap object or an oblet.
// scanobject consults the GC bitmap for the pointer mask and the
// spans for the size of the object.
//
//go:nowritebarrier
func scanobject(b uintptr, gcw *gcWork) {
// Note that arena_used may change concurrently during
// scanobject and hence scanobject may encounter a pointer to
// a new... 阅读全帖 |
|
发帖数: 1 | 6 赞啊，转码浪费了，可是不转还是没钱，唉，人生好难 |
|
|
发帖数: 1 | 8 目前发现两大问题：
1. GOGC，关闭Garbage Collection，性能提高20%，无语了，golang不是吹牛GC比JVM
G1强很多么？NGINX不用GC不是照样可以写程序么？
2. 滥用FUTEX，从strace上看，一个HTTP GET引发众多threads拼抢，thundering herd
problem，跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex，众多
goroutines给本来就很脆弱的futex加重负担。
各位大侠，我没学过golang，只花了几天测测http性能，就发现这两个问题，这应该是
设计失误吧？
[pid 29063] <... epoll_wait resumed> [{EPOLLIN|EPOLLOUT, {u32=4228357504,
u64=140170486062464}}], 128, -1) = 1
[pid 29063] futex(0x147c010, FUTEX_WAKE, 1) = 1
[pid 29063] read(6,
[pid 290... 阅读全帖 |
|
|
T********i
发帖数: 2416 | 10 pid 29010 貌似是GC thread。否则没法解释20us醒一次。
GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
比20%要大。
当然我可以用空间换时间。但是那是customize allocators。 |
|
g****t
发帖数: 31659 | 11 牛。GC你统计过longest pause什么的吗？
gc作者之一在这里
https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8
: 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b i))
: // scanobject scans the object starting at b, adding pointers to
gcw.
: // b must point to the beginning of a heap object or an oblet.
: // scanobject consults the GC bitmap for the pointer mask and
the
: // spans for the size of the object.
: //
: //go:nowritebarrier
: func scanobject(b uintptr, gc... 阅读全帖 |
|
g****t
发帖数: 31659 | 12 可预测性很重要。jvm最早时候我记得老死机吧？
c的话比较复杂，各种编译器各种优化什么的。
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
也很高
。一般
: 比20%要大。
: 当然我可以用空间换时间。但是那是customize allocators。
|
|
s********k
发帖数: 6180 | 13 赞干货
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了
JVM
herd |
|
d***a
发帖数: 13752 | 14 如果用golang的syscall包，可以用SO_REUSEPORT吧。OS要支持SO_REUSEPORT。
这个比较对golang不太公平。golang可以做很多事情，nginx专长做web server。 |
|
s********k
发帖数: 6180 | 15 所以说就是golang的这个包并没有做event based loop，还是直接狂开goroutine，所
以肯定比不过专门针对epoll做的IO密集型nginx？ |
|
s********k
发帖数: 6180 | 16 golfing 里面那个http package最好？ |
|
发帖数: 1 | 17 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 | 18 内存设计得好，就不需要自动GC。内存泄露可以用工具各种测试，反而JVM GC的bug不
好弄，也不好优化。
Cassandra为了躲避GC，特地用JNI搞了offheap objects，malloc也换成jemalloc，这
不就是Cpp么？
JVM GC效率也是问题，G1比CMS慢好多，Shenandoah比G1更慢。。。
关于20%问题，对于软件工程师可能不算什么，对于硬件CPU，10%以上就可以决定跑分
输赢。 |
|
发帖数: 1 | 19 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
都这么做了
只有亚麻和阿里是奇葩。 |
|
s********k
发帖数: 6180 | 20 这些大公司里面，CPP，java,golang都用的（当然软软加上C#），CPP是好，但是真是
顶级人才满足不了人民群众日益增长需求，要精通太难了。
做大规模项目
human is always the least scalable in your system |
|
|
发帖数: 1 | 22 謝謝，我也找到這些了，但他們都是非標準、野生的SO_REUSEPORT庫，我本身也不是搞
golang的，只能報告裡面寫，目前標準golang不支持，未來1.11有可能支持了 |
|
w**z
发帖数: 8232 | 23 绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA 99.
99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
去别的node
：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为 |
|
|
|
s********k
发帖数: 6180 | 26 赞资料
现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
。搞定这个绝对大包不愁啊
magagop 你底层系统经验这么好，绝对应该搞搞这个 |
|
|
y*j
发帖数: 3139 | 28 关于Golang, 我感觉是CPP的一个简化版，但是砍得太猛了，也许留下stack 上的自动
变量会好一些。至少减轻GC的压力。
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百
度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
|
|
发帖数: 1 | 29 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。 |
|
|
|
发帖数: 1 | 32 这里面讲了，为什么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 | 33 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。 |
|
y*j
发帖数: 3139 | 34 把GC完全关掉，时间一长，非耗尽内存空间不可。
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
还能非
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
|
|
b*******s
发帖数: 5216 | 35 golang + docker may be the best practice |
|
y*j
发帖数: 3139 | 36 Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。
: 俺一直都说，C#是最好的语言。。。。
|
|
发帖数: 1 | 37 CSharp在Linux、非x86架构下有性能很好的编译器和库么？
听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
要。 |
|
发帖数: 1 | 38 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。 |
|
y*j
发帖数: 3139 | 39 我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
化。
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
|
|
d***a
发帖数: 13752 | 40 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。 |
|
s********k
发帖数: 6180 | 41 用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
stream好用啊 |
|
s********k
发帖数: 6180 | 42 page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？
害。 |
|
s********k
发帖数: 6180 | 43 如果本来就是在VM上面再加pod上运行container，这个NUMA的作用还会很大吗？因为没
法控制底层的OS，golang也很难做好scheduler把？
miss |
|
s********k
发帖数: 6180 | 44 我觉得你是不是可以换个方法实验
你目前的实验室基于一个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 | 45 看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
害。
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
更厉害。
|
|
d***a
发帖数: 13752 | 46 从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。 |
|
d***a
发帖数: 13752 | 47 是的，不过如果把GC关掉长时间运行下去，page fault会增加的。
miss |
|
s********k
发帖数: 6180 | 48 哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个 |
|
发帖数: 1 | 49 .NET Core 2目前只支持Windows下的arm64，等Linux下也有arm64再開始轉吧。
Mono支持Linux的arm64，但性能應該不行（跟gcc 7.2比） |
|
发帖数: 1 | 50 我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
docker和k8s對非x86的支持也不是很好。
虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
VM
http |
|
