mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-11-21 14:44:00 +00:00
lib/leveledbytebufferpool: do not pool byte slices bigger than 2^18 bytes
Previously byte slices up to 2^20 bytes (e.g. 1Mb) were cached because of a typo in the commit c14dafce43
.
This could result in increased memory usage when vmagent scrapes many regular targets, which expose
relatively small number of metrics (e.g. up to a few thousand per target) and a few large targets such as kube-state-metrics,
which expose more than 10 thousand metrics. This is common case for Kubernetes monitoring.
While at it, remove pools for very small byte slices, since they are rarely used during scraping.
This commit is contained in:
parent
baee43f7a4
commit
1c094d928c
1 changed files with 7 additions and 7 deletions
|
@ -9,15 +9,15 @@ import (
|
|||
|
||||
// pools contains pools for byte slices of various capacities.
|
||||
//
|
||||
// pools[0] is for capacities from 0 to 8
|
||||
// pools[1] is for capacities from 9 to 16
|
||||
// pools[2] is for capacities from 17 to 32
|
||||
// pools[0] is for capacities from 0 to 64
|
||||
// pools[1] is for capacities from 65 to 128
|
||||
// pools[2] is for capacities from 129 to 256
|
||||
// ...
|
||||
// pools[n] is for capacities from 2^(n+2)+1 to 2^(n+3)
|
||||
// pools[n] is for capacities from 2^(n+5)+1 to 2^(n+6)
|
||||
//
|
||||
// Limit the maximum capacity to 2^18, since there are no performance benefits
|
||||
// in caching byte slices with bigger capacities.
|
||||
var pools [17]sync.Pool
|
||||
var pools [12]sync.Pool
|
||||
|
||||
// Get returns byte buffer with the given capacity.
|
||||
func Get(capacity int) *bytesutil.ByteBuffer {
|
||||
|
@ -51,10 +51,10 @@ func getPoolIDAndCapacity(size int) (int, int) {
|
|||
if size < 0 {
|
||||
size = 0
|
||||
}
|
||||
size >>= 3
|
||||
size >>= 6
|
||||
id := bits.Len(uint(size))
|
||||
if id >= len(pools) {
|
||||
id = len(pools) - 1
|
||||
}
|
||||
return id, (1 << (id + 3))
|
||||
return id, (1 << (id + 6))
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue