Two issues are fixed here, that lead to the same problem:
1. If `newSampleRing` is called with an unknown ValueType including
ValueNone, we have initialized the interface buffer (`iBuf`).
However, we would still use a specialized buffer for the first
sample, opportunistically assuming that we might still not
encounter mixed samples and we should go down the more efficient
road.
2. If the `sampleRing` is `reset`, we leave all buffers alone,
including `iBuf`, which is generally fine, but not for `iBuf`, see
below.
In both cases, `iBuf` already contains values, but we will fill one of
the specialized buffers first. Once we then actually encounter mixed
samples, the content of the specialized buffer is copied into `iBuf`
using `append`. That's by itself the right idea because `iBuf` might
be `nil`, and even if not, it might or might not have the right
capacity. However, this approach assumes that `iBuf` is empty, or more
precisely has a length of zero.
This commit makes sure that `iBuf` does not get needlessly initialized
in `newSampleRing` and that it is emptied upon `reset`.
A test case is added to demonstrate both issues above.
Signed-off-by: beorn7 <beorn@grafana.com>
* Remove NewPossibleNonCounterInfo until it can be made more efficient, and avoid creating empty annotations as much as possible
Signed-off-by: Jeanette Tan <jeanette.tan@grafana.com>
* Bump prometheus common to v0.44.0
Signed-off-by: Yannick te Kulve <738464+YannickTeKulve@users.noreply.github.com>
* Fix golang_protobuf_extensions sum
Signed-off-by: Yannick te Kulve <738464+YannickTeKulve@users.noreply.github.com>
* Remove unused deps
Signed-off-by: Yannick te Kulve <738464+YannickTeKulve@users.noreply.github.com>
---------
Signed-off-by: Yannick te Kulve <738464+YannickTeKulve@users.noreply.github.com>
When Prometheus restarts it creates every series read in from the WAL,
but many of those series will be finished, and never receive any more
samples. By defering allocation of the txRing slice to when it is first
needed, we save 32 bytes per stale series.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Broken by https://github.com/prometheus/prometheus/pull/12738. We have to update both global variables (as GlobalConfig is not a pointer here).
DefaultConfig is used when no global: section is provided, whereas DefaultGlobalConfig is used when it's provided and for individual scrape configs.
Reported on #prometheus-dev (thanks to @beorn7): https://cloud-native.slack.com/archives/C01AUBA4PFE/p1697733267205649
Tested manually, it would be nice to add test at some point (quick fix for now).
Signed-off-by: bwplotka <bwplotka@gmail.com>
In proto3, this doesn't change anything. However, since the
`CreatedTimestamp` field is generated as a pointer
(`*types.Timestamp`), we are still able to detect the unset state.
(This is in contrast to the `timestamp_ms` field, which is a plain
int64, for which we cannot enforce generation as a pointer, see
comment updated in the previous commit for future actions.)
Signed-off-by: beorn7 <beorn@grafana.com>
When reading the WAL this method is called with buffers from a pool, on
multiple goroutines. Pre-allocating sufficient size avoids slow growth
and many reallocations in `append`.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
