You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, everyone! I'm writing a c++ wrapper around your library, and after I've implemented some batch operations using aerospike_batch_read_async, I've noticed continuously increasing memory consumption of my application in production environment. Here is how it looks like:
It is heaptrack_gui visualization, and lowest rasing area is memory allocated by as_vector_increase_capacity (plateau on right side is because of very low rps at night). Also heaptrack was able to tell where allocations occure:
I'm sorry for screenshots, but profiling took about day, and log takes over 6GB.
It seems that sometimes uneven distribution of keys among nodes (in case of n_nodes >= 2) occurs, which leads to overflowing capacity of some as_batch_node.offsets (which are allocated on stack or heap, depending on n_keys value), which leads to implicit copying to the heap, and nobody takes care of that memory. I've made pull request and I'd be appreciate if you take a look at it. I currently run my application with patched library and it looks like problem has gone ;)
The text was updated successfully, but these errors were encountered:
Yes, as_batch_read_execute() will leak memory when the batch offsets vector exceeds it's initial capacity (like when batch size exceeds 5000). Your fix is correct. We will issue a new release after an unrelated issue is tracked down.
Hello, everyone! I'm writing a c++ wrapper around your library, and after I've implemented some batch operations using aerospike_batch_read_async, I've noticed continuously increasing memory consumption of my application in production environment. Here is how it looks like:
It is heaptrack_gui visualization, and lowest rasing area is memory allocated by as_vector_increase_capacity (plateau on right side is because of very low rps at night). Also heaptrack was able to tell where allocations occure:
I'm sorry for screenshots, but profiling took about day, and log takes over 6GB.
It seems that sometimes uneven distribution of keys among nodes (in case of n_nodes >= 2) occurs, which leads to overflowing capacity of some as_batch_node.offsets (which are allocated on stack or heap, depending on n_keys value), which leads to implicit copying to the heap, and nobody takes care of that memory. I've made pull request and I'd be appreciate if you take a look at it. I currently run my application with patched library and it looks like problem has gone ;)
The text was updated successfully, but these errors were encountered: