Michael Hoffmann
Michael Hoffmann
I think the memcached thing is only cosmetic because the remote index cache is situated in a file called memcached.go
Redis cache should have a config option "max_async_buffer_size" which does feel related. Why blocks are not loading because of it is a mystery though.
We also face the same issue ( though sporadically ); I wonder if we just hit the redis cache too hard and because of network latency the buffer fills too...
The cache should be shared across different deployments; this is for sure a bug i think
Ah so we are using redis only for index cache thats why i dont see the bucket meta sync issues i think! For bucket cache we use groupcache which works...
That log is not problematic I think, does it log something else before it crashes?
Thank you for your interest! We have an official way to apply for this project under this link: https://mentorship.lfx.linuxfoundation.org/project/05b3d261-f874-4b8c-bd7e-c4fa83c979b4
It must be something other then the maxtime of the range request being messed with. That logging is the String representation of the endpoint ref and corresponds to the time...
The issue here was that the querier is not configured to point at query APIs but at store APIs ( we should guard against that better probably ); this leads...
We have: ``` bufPooled, err := r.block.chunkPool.Get(r.block.estimatedMaxChunkSize) if err == nil { buf = *bufPooled } else { buf = make([]byte, r.block.estimatedMaxChunkSize) } ``` and the crash happens here few...