FAQ

On 2013/01/04 06:04:59, dvyukov wrote:
On 2013/01/03 23:55:50, sougou wrote:
Reran vtocc benchmars, around 10M queries using 100 clients.

Run 1: go version currently used on production 0a3866d6cc6b (Sep
24):
qps: 5832 StackSys: 86MB

Run 2: go @tip d0d76b7fb219 (Jan 3):
qps: 5543 StackSys: 77MB

Run 3: Using CL 6997052:
qps: 5673 StackSys: 3MB

Run 4: Using CL 7029044:
qps: 5699 StackSys: 15MB

Conclusion: Marginal difference in performance between the two CLs.
The older
CL
uses less memory. Maybe it will be more pronounced if you passed
large objects
by value to functions?
The runtime @tip is slower than the one from September, an unrelated
observation.

This is just a summary. I can send you more detailed stats and pprof
captures
if
needed.
Can you please test with varying values for
StackCacheSize/StackCacheBatch in
src/pkg/runtime/runtime.h?
Currently they are set to 128/32. The CL/6997052 is using 16/8. I am inclined
towards 32/16 for now (my synthetic tests show still minimal memory
consumption
and good performance). Another possible point is 64/32.
Or perhaps it's already fine?
15 vs 79-80MB is a good win already. More importantly StackSys must not
grow over time now, it's bounded by 512kb per thread (while currently it
slowly grows to infinity).

Well, actually not that slowly. I've run the following funny test --
each line is StackSys *increase*.

Current behavior:
$ go test -run=StackMem -v
-cpu=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
2>&1 | grep "for stack mem"
stack_test.go:1569: Consumed 106MB for stack mem
stack_test.go:1569: Consumed 48MB for stack mem
stack_test.go:1569: Consumed 52MB for stack mem
stack_test.go:1569: Consumed 71MB for stack mem
stack_test.go:1569: Consumed 71MB for stack mem
stack_test.go:1569: Consumed 53MB for stack mem
stack_test.go:1569: Consumed 35MB for stack mem
stack_test.go:1569: Consumed 27MB for stack mem
stack_test.go:1569: Consumed 39MB for stack mem
stack_test.go:1569: Consumed 43MB for stack mem
stack_test.go:1569: Consumed 49MB for stack mem
stack_test.go:1569: Consumed 54MB for stack mem
stack_test.go:1569: Consumed 44MB for stack mem
stack_test.go:1569: Consumed 35MB for stack mem
stack_test.go:1569: Consumed 41MB for stack mem
stack_test.go:1569: Consumed 32MB for stack mem
stack_test.go:1569: Consumed 27MB for stack mem
stack_test.go:1569: Consumed 20MB for stack mem
stack_test.go:1569: Consumed 36MB for stack mem
stack_test.go:1569: Consumed 33MB for stack mem
stack_test.go:1569: Consumed 31MB for stack mem
stack_test.go:1569: Consumed 45MB for stack mem
stack_test.go:1569: Consumed 40MB for stack mem
stack_test.go:1569: Consumed 30MB for stack mem
stack_test.go:1569: Consumed 39MB for stack mem
stack_test.go:1569: Consumed 27MB for stack mem
stack_test.go:1569: Consumed 27MB for stack mem
stack_test.go:1569: Consumed 37MB for stack mem
stack_test.go:1569: Consumed 33MB for stack mem
stack_test.go:1569: Consumed 36MB for stack mem
stack_test.go:1569: Consumed 34MB for stack mem
stack_test.go:1569: Consumed 42MB for stack mem
stack_test.go:1569: Consumed 29MB for stack mem
stack_test.go:1569: Consumed 29MB for stack mem
stack_test.go:1569: Consumed 44MB for stack mem
stack_test.go:1569: Consumed 20MB for stack mem
stack_test.go:1569: Consumed 31MB for stack mem
stack_test.go:1569: Consumed 31MB for stack mem
stack_test.go:1569: Consumed 19MB for stack mem
stack_test.go:1569: Consumed 25MB for stack mem


New behavior:
$ go test -run=StackMem -v
-cpu=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
2>&1 | grep "for stack mem"
stack_test.go:1569: Consumed 13MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
stack_test.go:1569: Consumed 0MB for stack mem
...



Either somebody must come up with a good tuning methodology, or let's
commit it as-is and tune later.

https://codereview.appspot.com/7029044/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 12 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedJan 4, '13 at 1:17a
activeJan 4, '13 at 8:36p
posts12
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase