Does this still happen if you remove the struct tags? IIRC they're stored as strings. Note that the wiki example has a struct with no tags.

(This is more of a question but I'm leaving this open in case it turns out to be a GC regression).

@ALTree thanks for the reply. I will try to remove struct tags and check once again.
Meanwhile I have a new question: maybe it is due to map size?
The graph above is from production environment where map contains ~16.2KK elements.
On staging environment map contains ~6.5KK elements and we have GC max time about 10ms.

UPD: well, we actually also had max time on staging about 1s but this morning it suddenly dropped down to 500ms and then to 10-20 ms.

Struct tags shouldn't make any difference; a struct tag is a string constant that only appears once per type, not once per value.

But, yes, maps always require scanning. I think the wiki page is trying to say that the data stored in the map is not scanned by the GC, and that is true. But the map data structure contains internal pointers, and those have to be scanned.

Closing this issue because it seems to be a question rather than a bug report. Please comment if you disagree. In general you can get better and faster answers to questions on a forum rather than on the issue tracker; see https://golang.org/wiki/Questions. Thanks.

@ianlancetaylor to be honest, if you are right then that wiki page is quite misleading, since when I read:

For example, the following map won't visibly affect GC time:

type Key [64]byte // SHA-512 hash
type Value struct {
	Name      [32]byte
	Balance   uint64
	Timestamp int64
}
m := make(map[Key]Value, 1e8)

I conclude that the map itself won't be scanned... otherwise I don't see how a sentence like "the following map won't visibly affect GC time" before a 1e8 elements map could be true.

How are you measuring "Go GC duration max"?

You are right that the map itself should not be scanned during GC. But the space it uses does contribute to the live data size. That affects the heap target size. So if there's a map like this that is a significant fraction of your live data, then it will cause your heap to be larger, GC to run less frequently, and GC to take longer when it does run.

@aclements @mknyszek

@randall77 we use Grafana & Prometheus for service monitoring.
Prometheus provides go_gc_duration_seconds metric.
And then we display it as graph in Grafana go_gc_duration_seconds{quantile="1"}.

The application is very simple. Actually it's just in-memory cache over DB.
On startup we scan whole table in DB and create map[int64]ItemPricing as a cache.
Then on some interval we scan once again, create a new map, and replace old map with a new one. Old map is expected to be garbage collected as single object but it seems like there is scanning maps though.