transactions: add info about preventing OOM

Apply suggestions from code review

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

Author: paulohtb6

modules/develop/pages/transactions.adoc

@@ -270,6 +270,27 @@ Redpanda’s default configuration supports exactly-once processing. To preserve
 
 To help avoid common pitfalls and optimize performance, consider the following when configuring transactional workloads in Redpanda:
 
+=== Tune producer ID limits
+
+For production environments with heavy producer usage, consider using xref:reference:properties/cluster-properties.adoc#max_concurrent_producer_ids[`max_concurrent_producer_ids`] to prevent out-of-memory (OOM) crashes. The default unlimited value can lead to unbounded memory growth, especially with transactions or idempotent producers.
+
+Calculate an appropriate value based on your expected concurrent producers:
+
+* **Lower bound**: `kafka_connections_max` ÷ `number_of_shards` (based on the assumption that each producer connects to only one shard)
+* **Upper bound**: `topic_partitions_per_shard` × `kafka_connections_max` (based on the assumption that producers connect to all shards)  
+* **Recommended starting point**: Use a value between these upper and lower bounds, considering your application's produce patterns
+
+Applications with wide fan-out patterns (producers writing to many partitions across multiple shards) require values closer to the upper bound.
+
+Monitor these metrics to determine if the limit is being reached:
+
+* xref:reference:internal-metrics-reference.adoc#vectorized_cluster_producer_state_manager_evicted_producers[`vectorized_cluster_producer_state_manager_evicted_producers`]: Number of evicted producers (should be 0 in steady state)
+* xref:reference:internal-metrics-reference.adoc#vectorized_cluster_producer_state_manager_producer_manager_total_active_producers[`vectorized_cluster_producer_state_manager_producer_manager_total_active_producers`]: Current number of active producers per shard
+
+If `evicted_producers` > 0, the shard is exceeding the configured limit. For applications with long-running transactions, ensure xref:reference:properties/cluster-properties.adoc#transactional_id_expiration_ms[`transactional_id_expiration_ms`] accommodates your typical transaction lifetime to avoid premature producer ID expiration.
+
+=== Configure transaction timeouts and limits
+
 * If a consumer is configured to use the read_committed isolation level, it can only process successfully committed transactions. As a result, an ongoing transaction with a large timeout that becomes stuck could prevent the consumer from processing other committed transactions.
 +
 To avoid this, don't set the transaction timeout client setting (`transaction.timeout.ms` in the Kafka Java client implementation) to a value that is too high. The longer the timeout, the longer consumers may be blocked. 

modules/reference/partials/properties/cluster-properties.adoc

@@ -12375,7 +12375,9 @@ endif::[]
 
 === max_concurrent_producer_ids
 
-Maximum number of active producer sessions per shard. Each shard tracks producer IDs using an LRU (Least Recently Used) eviction policy. When the configured limit is exceeded, the least recently used producer IDs are evicted from the cache. IMPORTANT: The default value is unlimited, which can lead to unbounded memory growth and out-of-memory (OOM) crashes in production environments with heavy producer usage, especially when using transactions or idempotent producers. It is strongly recommended to set a reasonable limit in production deployments.
+Maximum number of active producer sessions per shard. Each shard tracks producer IDs using an LRU (Least Recently Used) eviction policy. When the configured limit is exceeded, the least recently used producer IDs are evicted from the cache. 
+
+IMPORTANT: The default value is unlimited, which can lead to unbounded memory growth and out-of-memory (OOM) crashes in production environments with heavy producer usage, especially when using transactions or idempotent producers. It is strongly recommended to set a reasonable limit in production deployments.
 
 [cols="1s,2a"]
 |===
@@ -12420,6 +12422,8 @@ endif::[]
 
 * xref:reference:properties/cluster-properties.adoc#transactional_id_expiration_ms[transactional_id_expiration_ms]
 
+* xref:manage:monitoring.adoc[Monitor Redpanda]
+
 |===
 
 
@@ -19095,7 +19099,9 @@ endif::[]
 
 === transactional_id_expiration_ms
 
-Expiration time of producer IDs. Measured starting from the time of the last write until now for a given ID. Producer IDs are automatically removed from memory when they expire, which helps manage memory usage. However, this natural cleanup may not be sufficient for workloads with high producer churn rates. For applications with long-running transactions, ensure this value accommodates your typical transaction lifetime to avoid premature producer ID expiration.
+Expiration time of producer IDs. Measured starting from the time of the last write until now for a given ID. 
+
+Producer IDs are automatically removed from memory when they expire, which helps manage memory usage. However, this natural cleanup may not be sufficient for workloads with high producer churn rates. For applications with long-running transactions, ensure this value accommodates your typical transaction lifetime to avoid premature producer ID expiration.
 
 [cols="1s,2a"]
 |===
@@ -19141,7 +19147,7 @@ endif::[]
 |
 * xref:develop:transactions.adoc#tune-producer-id-limits[Tune producer ID limits]
 
-* xref:reference:properties/cluster-properties.adoc#max_concurrent_producer_ids[max_concurrent_producer_ids]
+* xref:reference:properties/cluster-properties.adoc#max_concurrent_producer_ids[`max_concurrent_producer_ids`]
 
 |===