@GAVINHSU first, don’t rely on restarts your heap is pinned because Xms = Xmx, so the JVM won’t shrink; set Xms lower than Xmx and leave 30–40% RAM for OS/Kafka (on 24 GB, keep heap ~8–12 GB; if you can, move the box to 32–48 GB and set heap 16–24 GB). Use a dedicated background node (no web users) and scale out: add another background node or raise threads to match CPU, but only if your Kafka topic has at least that many partitions across all nodes. Keep queue items small enqueue just IDs/keys, fetch data inside the processor, and clear pages after each item to avoid fat clipboards. Don’t push 150k in one blast; throttle in chunks (1–5k per burst) or use a Data Flow with parallelism and commit settings for bulk runs. Stick with G1 GC (Java 11), turn on GC logs, and cap off-heap to avoid hidden memory use (for example, -XX:MaxDirectMemorySize=1g). Monitor Admin Studio for QP lag, thread utilization, and Old Gen pressure; tune thread count and batch size so you’re not over-pulling. If embedded Kafka becomes a bottleneck, move to external Kafka (MSK/Confluent) and right-size partitions and consumer max.poll.records. If memory still climbs after these changes, profile for large pages/caches and open a Pega SR to check for a leak in your processing step.