# Puts causing memory issues

**URL:** <https://discuss.aerospike.com/t/puts-causing-memory-issues/9884>\
**Category:** Java Client\
**Tags:** java, client\
**Created:** [November 29, 2022, 10:16pm UTC](https://discuss.aerospike.com/t/puts-causing-memory-issues/9884 "2022-11-29T22:16:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![int64max](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/int64max/32/1735_2.png) [@int64max](https://discuss.aerospike.com/u/int64max)\
**Post date:** [November 29, 2022, 10:16pm UTC](https://discuss.aerospike.com/t/puts-causing-memory-issues/9884/1 "2022-11-29T22:16:22Z")

</div>

I have a single Aerospike client, created with the following configuration:

```auto
      ClientPolicy rwPolicy = new ClientPolicy();
      rwPolicy.maxConnsPerNode = 300;
      rwPolicy.maxSocketIdle = 0;
      rwPolicy.minConnsPerNode = 15;

```

I use 8 threads in the event loops.

I have a scenario where I need to do a lot of “put” operations (50k-500k) in short burst. I’m simply invoking `client.put` in a for loop. Some of these writes can happen in parallel too.

After some writes (10k-50k), my program crashes with out-of-memory error. Note that I don’t receive a Java OutOfMemoryException. Instead, Kubernetes kills my container with OOM error (137 exit code). So this likely means native memory usage is exceeding limits. I’ve left a couple of GBs for native memory, but still run into this issue.

Have others run into this issue too? Do we need to throttle the writes? We have an Aerospike Enterprise and Managed Service license if that matters.

Any help will be appreciated. Thanks.

---

<div class="post-metadata">

**Author:** ![Brian](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/brian/32/2211_2.png) [@Brian](https://discuss.aerospike.com/u/Brian)\
**Post date:** [November 29, 2022, 11:14pm UTC](https://discuss.aerospike.com/t/puts-causing-memory-issues/9884/2 "2022-11-29T23:14:55Z")

</div>

Yes, the puts should be throttled. By default, async put operations are immediately executed by an event loop. 500k put transactions executed immediately is likely to exceed maxConnsPerNode or cause the async delay queue to grow too large, depending on your event loop configuration.

[EventPolicy](https://github.com/aerospike/aerospike-client-java/blob/master/client/src/com/aerospike/client/async/EventPolicy.java) should be set in your case. maxCommandsInProcess should be set to max number of transactions that can consistently be run concurrently on your machine. maxCommandsInQueue should be set to some value that does not cause out-of-memory errors when the async delay queue is full.

---

<div class="post-metadata">

**Author:** ![neelp](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/neelp/32/1369_2.png) [@neelp](https://discuss.aerospike.com/u/neelp)\
**Post date:** [December 2, 2022, 5:09pm UTC](https://discuss.aerospike.com/t/puts-causing-memory-issues/9884/3 "2022-12-02T17:09:17Z")

</div>

Just to add to Brian’s suggestions: Have you considered [batch operations](https://developer.aerospike.com/blog/batch-operations-in-aerospike)? Assuming batching is possible, they can provide better resource utilization and better throughput.

---

<div class="post-metadata">

**Author:** ![int64max](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/int64max/32/1735_2.png) [@int64max](https://discuss.aerospike.com/u/int64max)\
**Post date:** [December 8, 2022, 2:17pm UTC](https://discuss.aerospike.com/t/puts-causing-memory-issues/9884/4 "2022-12-08T14:17:01Z")

</div>

Thanks Brian and neelp. I played around with the EventPolicy like Brian suggested. I also upgraded the Aerospike version. These seem to have helped with the situation.

We’re currently doing asynchronous single requests, though due to pattern of client requests, this sometimes hits 50k-500k requests in parallel. Reading up on batch operations, it does seem like they’ll help. When we implemented our solution, batch ops weren’t supported.

I’ll keep an eye on the jobs, and if they memory usage goes crazy again, I’ll migrate the code to use batch requests.