fatal error "out of memory" sometimes (mostly around 3:00am if this helps) #7778
Labels
Comments
|
@Apollon77 What version of InfluxDB are you using? Also what kind of load is your system under? |
|
The link doesn't currently point to the stack trace. |
mark-rushakoff
added a commit
that referenced
this issue
Jan 13, 2017
This leak seems to have been introduced in 8aa224b, present in 1.1.0 and 1.1.1. When points were parsed from HTTP payloads, their tags and fields referred to subslices of the request body; if any tag set introduced a new series, then those tags then were stored in the in-memory series index objects, preventing the HTTP body from being garbage collected. If there were no new series in the payload, then the request body would be garbage collected as usual. Now, we clone the tags before we store them in the index. This is an imperfect fix because the Point still holds references to the original tags, and the Point's field iterator also refers to the payload buffer. However, the current write code path does not retain references to the Point or its fields; and this change will likely be obsoleted when TSI is introduced. This change likely fixes #7827, #7810, #7778, and perhaps others.
3 tasks
gunnaraasen
pushed a commit
that referenced
this issue
Feb 16, 2017
This leak seems to have been introduced in 8aa224b, present in 1.1.0 and 1.1.1. When points were parsed from HTTP payloads, their tags and fields referred to subslices of the request body; if any tag set introduced a new series, then those tags then were stored in the in-memory series index objects, preventing the HTTP body from being garbage collected. If there were no new series in the payload, then the request body would be garbage collected as usual. Now, we clone the tags before we store them in the index. This is an imperfect fix because the Point still holds references to the original tags, and the Point's field iterator also refers to the payload buffer. However, the current write code path does not retain references to the Point or its fields; and this change will likely be obsoleted when TSI is introduced. This change likely fixes #7827, #7810, #7778, and perhaps others.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I use most current Influxdb package on Ubuntu Xenial on ARMHF device (Cubietruck).
Now for the third time after working some days the influxd crashes at night (around 3am german winter time) with a fatal (see attachement) ... System has 2 GB memory and DB is around 1,3GB.
Influxdb automatically restarts itself.
Hope the stack trace helps
Uploading influxd-fatal.txt…
The text was updated successfully, but these errors were encountered: