Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go HeapAlloc slowing increasing #5144

Closed
otoolep opened this issue Dec 16, 2015 · 9 comments
Closed

Go HeapAlloc slowing increasing #5144

otoolep opened this issue Dec 16, 2015 · 9 comments
Labels

Comments

@otoolep
Copy link
Contributor

otoolep commented Dec 16, 2015

During 500K EPS write load of the TSM engine, internal metrics show the HeapAlloc profile slowly increasing. There was also query load on the system during this time, but not that significant.

See attached graph. This was with a6cdb52

@otoolep
Copy link
Contributor Author

otoolep commented Dec 16, 2015

heap

@otoolep
Copy link
Contributor Author

otoolep commented Dec 16, 2015

cc @jwilder @pauldix @mjdesa

@mjdesa -- we need to get the Go runtime stats into Grafana for our test beds. Telegraf has an outstanding PR by @mark-rushakoff that will help.

@otoolep
Copy link
Contributor Author

otoolep commented Dec 16, 2015

37K queries had been executed in total on this node.

@jwilder
Copy link
Contributor

jwilder commented Dec 16, 2015

Would be good to run a test w/ b1 or bz1 to see if we see the same profile.

@desa
Copy link
Contributor

desa commented Dec 16, 2015

Added a task to track go runtime stats into Grafana to Tracker.

@pauldix
Copy link
Member

pauldix commented Dec 16, 2015

Any chance the heap growth is tied to the growing number of tsm files? All of those indexes are kept on the heap.

Would be good to run a test at this scale (5M unique series posted every 10s) without queries and see if the heap growth changes.

@otoolep
Copy link
Contributor Author

otoolep commented Dec 16, 2015

Yeah, @pauldix -- that sounds feasible. Heap usage growth was pretty slow, we just noticed it and so I thought we should capture it. It the write load was taken off, perhaps it would flatline.

@mark-rushakoff
Copy link
Contributor

The PR that @otoolep mentioned is influxdata/telegraf#449. Not merged yet but I think we're close. It should work fine now if you need it and you're willing to build telegraf from that branch.

@jwilder
Copy link
Contributor

jwilder commented Jan 21, 2016

Tests run #4977 indicate this issue is resolved.

@jwilder jwilder closed this as completed Jan 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants