{"action":"opened","issue":{"url":"https://api.github.com/repos/golang/go/issues/10064","labels_url":"https://api.github.com/repos/golang/go/issues/10064/labels{/name}","comments_url":"https://api.github.com/repos/golang/go/issues/10064/comments","events_url":"https://api.github.com/repos/golang/go/issues/10064/events","html_url":"https://github.com/golang/go/issues/10064","id":59605273,"number":10064,"title":"runtime: GC behavior in non-steady mode","user":{"login":"dvyukov","id":1095328,"avatar_url":"https://avatars.githubusercontent.com/u/1095328?v=3","gravatar_id":"","url":"https://api.github.com/users/dvyukov","html_url":"https://github.com/dvyukov","followers_url":"https://api.github.com/users/dvyukov/followers","following_url":"https://api.github.com/users/dvyukov/following{/other_user}","gists_url":"https://api.github.com/users/dvyukov/gists{/gist_id}","starred_url":"https://api.github.com/users/dvyukov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dvyukov/subscriptions","organizations_url":"https://api.github.com/users/dvyukov/orgs","repos_url":"https://api.github.com/users/dvyukov/repos","events_url":"https://api.github.com/users/dvyukov/events{/privacy}","received_events_url":"https://api.github.com/users/dvyukov/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-03-03T07:28:58Z","updated_at":"2015-03-03T07:28:58Z","closed_at":null,"body":"Currently GC allows heap to grow to 2x of live memory during the previous GC. This can play badly with spiky memory usage. Consider that in steady state program has live set X. GC will allow heap to grow to 2X and then collect it back to X, and so on. Now consider that there is a 1.5X spike in memory usage. If GC happens _after_ the spike (when live set is again X), then GC will collect X memory (garbage generated during the spike) and set heap limit to 2X as before. Now if GC happens to happen _during_ the spike (when live set is 1.5X), then GC will collect only 0.5X and set heap limit to 3X.\r\n\r\nBasically bad timing can increase maximum heap (RSS) by up to 2x.\r\n\r\nMemory-constrained environments, like browsers, pay a great deal of attention to this problem. The idea is to set smarter GC threshold when heap grows/shrinks.\r\n\r\nI did not work out a solution. But what I have in mind is: if heap grows, and especially if the next threshold (next_gc) will be larger than the current RSS (heap_sys - heap_released), then set next_gc to, say, heap_inuse * (1 + GOGC/100) * 0.75.\r\nSince heap cannot grow all the time, this throttling is only temporal.\r\n\r\n@rsc @RLH @aclements @randall77 "}}