Closed dianasaur323 closed 7 years ago
I'll take a look today. Does anyone know PHP well enough to extract the reproduction into a series of SQL statements?
Update: I've figured out the PHP stuff. Still trying to reproduce the memory leak.
I was able to reproduce what looks like a memory leak when running digits-mixed.php
:
Haven't done any debugging to figure out what is going, but this is reproducible.
The above repro was on top of https://github.com/cockroachdb/cockroach/pull/14489 which exacerbates the problem, but it still seems to happen on master. The problem is in the construction of the cacheRequest
inserted into the timestamp cache. Specifically https://github.com/cockroachdb/cockroach/blob/master/pkg/storage/replica.go#L1595-L1610:
case *roachpb.ScanRequest:
resp := br.Responses[i].GetInner().(*roachpb.ScanResponse)
if ba.Header.MaxSpanRequestKeys != 0 &&
ba.Header.MaxSpanRequestKeys == int64(len(resp.Rows)) {
// If the scan requested a limited number of results and we hit the
// limit, truncate the span of keys to add to the timestamp cache
// to those that were returned.
//
// NB: We need to include any key read by the operation, even if
// not returned, in the span added to the timestamp cache in order
// to prevent phantom read anomalies. That means we can only
// perform this truncate if the scan requested a limited number of
// results and we hit that limit.
header.EndKey = resp.Rows[len(resp.Rows)-1].Key.Next()
}
cr.reads = append(cr.reads, header)
For a ScanRequest
, if we limited the scan then the cacheRequest
contains a span which holds on to the last row in the ScanResponse
(assuming Next
didn't make a copy of the key which is the common case). Note that the keys and the values in the ScanResponse
are allocated using a ByteAllocator
which reduces allocations but has the drawback that a larger chunk of memory will be pinned if any portion of the ByteAllocator
buffer is pinned.
There is a relatively straightforward change to make a copy of header.EndKey
, but I'd like to think about this over night before committing to that direction.
Making a copy here seems like the right move to me. I wonder if we could zero-fill ByteAllocator buffers when they should go out of scope to help detect cases like this. I don't think there's a good time to do that, though.
I wonder if we could zero-fill ByteAllocator buffers when they should go out of scope to help detect cases like this. I don't think there's a good time to do that, though.
Yeah, that would be good, but I don't see where to do it either.
Copying in issue encountered on forum. Response and triage needed.
Below are the steps to reproduce crashing the cluster 100% of the time with oom 5 Machines, m4.2xlarge (31GB mem each)
startup options: cockroach start --store=path=/data,size=256GB,attrs=ssd --log-dir /data/log --insecure
Machines run at ~2GB ram utilization during inserts. Ram usage explodes when running last example which is combination of selects and inserts, crashed most or all nodes. Irrecoverable, restarting the failed node crashes with OOM again.
Other minor details:
We are using dns roundrobin to hit all 5 nodes Version we are using:
==========begin oom message=============
==========end message=============