root
/
kafka
mirror of https://github.com/apache/kafka.git
1
0
Fork 0
Code Issues Actions 2 Packages Projects Releases Wiki Activity

MINOR: Update "Java Version" section 

Use the latest information from LinkedIn and mention that the latest
released version is recommended from a security perspective.

Author: Ismael Juma <ismael@juma.me.uk>

Reviewers: Grant Henke

Closes #603 from ijuma/java-version-recommendation
This commit is contained in:
Ismael Juma 2015-11-30 13:57:54 -08:00 committed by Guozhang Wang
parent ea971397c8
commit a35334908d
1 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/ops.html
View File

@ -390,19 +390,22 @@ producer.purgatory.purge.interval.requests=100
Our client configuration varies a fair amount between different use cases.
<h3><a id="java" href="#java">Java Version</a></h3>
We're currently running JDK 1.7 u51, and we've switched over to the G1 collector. If you do this (and we highly recommend it), make sure you're on u51. We tried out u21 in testing, but we had a number of problems with the GC implementation in that version.
Our tuning looks like this:
From a security perspective, we recommend you use the latest released version of JDK 1.8 as older freely available versions have disclosed security vulnerabilities.
LinkedIn is currently running JDK 1.8 u5 (looking to upgrade to a newer version) with the G1 collector. If you decide to use the G1 collector (the current default) and you are still on JDK 1.7, make sure you are on u51 or newer. LinkedIn tried out u21 in testing, but they had a number of problems with the GC implementation in that version.
LinkedIn's tuning looks like this:
<pre>
-Xms4g -Xmx4g -XX:PermSize=48m -XX:MaxPermSize=48m -XX:+UseG1GC
-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M
</pre>
For reference, here are the stats on one of LinkedIn's busiest clusters (at peak):
- 15 brokers
- 15.5k partitions (replication factor 2)
- 400k messages/sec in
- 70 MB/sec inbound, 400 MB/sec+ outbound
- 60 brokers
- 50k partitions (replication factor 2)
- 800k messages/sec in
- 300 MB/sec inbound, 1 GB/sec+ outbound
The tuning looks fairly aggressive, but all of the brokers in that cluster have a 90% GC pause time of about 21ms, and they're doing less than 1 young GC per second.