Tuning options for 2.2 differ from those of previous Logstash instances. See this blog post section, which includes:
There are three configurable options in the pipeline,
--pipeline-workers,--pipeline-batch-size, and--pipeline-batch-delay. The--pipeline-workersor-wparameter determines how many threads to run for filter and output processing. If you find that events are backing up, or that the CPU is not saturated, consider increasing the value of this parameter to make better use of available processing power. Good results can even be found increasing this number past the number of available processors as these threads may spend significant time in an I/O wait state when writing to external systems. Legal values for this parameter are positive integers.
Also, with 2.2 the retry logic has been improved.
Elasticsearch Output Enhancements
Bundled with Logstash 2.2 is the newest version of the Elasticsearch output, designed to work optimally with the NG pipeline, while remaining backward compatible with older 2.x Logstash releases. This version has a vastly simplified and more correct algorithm around retry handling. In this new release each batch going through the NG pipeline blocks until all operations that do not produce unrecoverable errors succeed. This means that network connectivity errors,
429s, and503s are retried indefinitely now. Previously, the plugin retried these a limited number of times, but we’ve decided to err on the side of data preservation here. Additionally,409conflict handling is now only retryable via theretry_on_conflictparameter.
Which protocol are you using to connect to Elasticsearch? We tend to discourage large batch sizes as the retries (if they happen) can cause larger delays with larger batches. A 429 also indicates too many connections to your cluster. Are you round-robining your output to sufficiently spread the indexing load?