Repository: kafka
Updated Branches:
  refs/heads/0.9.0 ca24692d1 -> a412d8a23


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 <[email protected]>

Reviewers: Grant Henke

Closes #603 from ijuma/java-version-recommendation


Project: http://git-wip-us.apache.org/repos/asf/kafka/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/a412d8a2
Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/a412d8a2
Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/a412d8a2

Branch: refs/heads/0.9.0
Commit: a412d8a23859928a35a371d21cb1cb585672796f
Parents: ca24692
Author: Ismael Juma <[email protected]>
Authored: Mon Nov 30 13:57:54 2015 -0800
Committer: Guozhang Wang <[email protected]>
Committed: Tue Dec 1 11:14:51 2015 -0800

----------------------------------------------------------------------
 docs/ops.html | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/kafka/blob/a412d8a2/docs/ops.html
----------------------------------------------------------------------
diff --git a/docs/ops.html b/docs/ops.html
index 2624527..623ab0f 100644
--- a/docs/ops.html
+++ b/docs/ops.html
@@ -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.
 

Reply via email to