发帖数: 1 | 1 目前发现两大问题：
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... 阅读全帖 |
|
发帖数: 1 | 2 目前发现两大问题：
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... 阅读全帖 |
|
d***a
发帖数: 13752 | 3 我的两分钱如下： :-)
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 | 4 我的两分钱如下： :-)
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
futex调用。
我说的不一定对。
JVM
herd |
|
b*******i
发帖数: 14 | 5 主要是求稳, 分配很大的内存时候常常stuck在那里了.
觉得glibc的malloc比tcmalloc还稳定, 怀疑网上吹googleperf.
有经验的进来说说, thanks
tcmalloc_sample_paramter 和 tcmalloc_release_rate 怎么取? |
|
S*A
发帖数: 7142 | 6 因为我最近在 hack 这个 Pogoplug V4 mobile。我顺便帮
你看了以下。
我从 UBoot 上面去掉了 serial cosole。这个是 dmesg。
时钟初始化是在 12 妙开始, 并不是 Linux 真正启动了 12 妙。
所以走到 systemd 启动也才 3.5 秒钟。注意其中有 USB 硬盘
访问，因为那个 rootfs 是在 USB 上面。仔细看 demsg，去掉
USB 硬盘访问，去掉 SATA 寻找硬盘，去掉 Ethernet 寻找
Link 的时间，剩下初始化应该就在 2 秒钟以内了。这个 3.5
秒钟很多时间是在和 USB storage 的东西相关。你只要
rootfs 不在 USB flash 上面，这些都可以启动的时候不做。
所以 2 秒钟启动应该是可以的，不需要特别多定制。
基本上改改 kernel config 或者启动参数就可以了。
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ ... 阅读全帖 |
|
S*A
发帖数: 7142 | 7 因为我最近在 hack 这个 Pogoplug V4 mobile。我顺便帮
你看了以下。
我从 UBoot 上面去掉了 serial cosole。这个是 dmesg。
时钟初始化是在 12 妙开始, 并不是 Linux 真正启动了 12 妙。
所以走到 systemd 启动也才 3.5 秒钟。注意其中有 USB 硬盘
访问，因为那个 rootfs 是在 USB 上面。仔细看 demsg，去掉
USB 硬盘访问，去掉 SATA 寻找硬盘，去掉 Ethernet 寻找
Link 的时间，剩下初始化应该就在 2 秒钟以内了。这个 3.5
秒钟很多时间是在和 USB storage 的东西相关。你只要
rootfs 不在 USB flash 上面，这些都可以启动的时候不做。
所以 2 秒钟启动应该是可以的，不需要特别多定制。
基本上改改 kernel config 或者启动参数就可以了。
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ ... 阅读全帖 |
|
s********k
发帖数: 6180 | 8 赞干货
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了
JVM
herd |
|
发帖数: 1 | 9 感覺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 | 10 在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
... 阅读全帖 |
|
s********k
发帖数: 6180 | 11 赞干货
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了
JVM
herd |
|
发帖数: 1 | 12 感覺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 | 13 在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
... 阅读全帖 |
|
