What performance tuning options are available in NiFi and what are common bottleneck patterns?

NiFi performance tuning operates at several levels: JVM heap, thread pool sizes, repository configuration, and per-processor settings.

JVM Heap (bootstrap.conf): The java.arg.2=-Xms and java.arg.3=-Xmx settings control heap. NiFi's content repository keeps content on disk, so heap is primarily consumed by FlowFile attributes (in memory), in-flight processing, and Lucene indexes in the provenance repository. Typical production deployments use 4–16 GB. Insufficient heap causes frequent GC pauses and OutOfMemoryErrors.

Content Repository Partitioning: Splitting the content repository across multiple physical disks increases I/O parallelism, often the primary bottleneck for high-throughput flows.

Common bottleneck patterns:

• Single processor bottleneck: One slow processor with a growing upstream queue. Solution: increase concurrent tasks on that processor.
• Provenance repository lag: Slow provenance writes causing processor stalls. Solution: use WriteAheadProvenanceRepository instead of PersistentProvenanceRepository, or reduce provenance event detail.
• Back-pressure chain: All processors paused because the terminal writer (PutS3Object, PutDatabaseRecord) is slow. Solution: scale the terminal processor or add a MergeContent batch before it.
• Small FlowFile overhead: Millions of tiny FlowFiles causing high FlowFile repository overhead. Solution: use MergeContent to batch before terminal writes.