kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gwens...@apache.org
Subject svn commit: r1695598 - in /kafka/site: 08/ops.html 081/ops.html 082/ops.html 083/ops.html
Date Wed, 12 Aug 2015 18:55:12 GMT
Author: gwenshap
Date: Wed Aug 12 18:55:12 2015
New Revision: 1695598

URL: http://svn.apache.org/r1695598
Log:
KAFKA-2418: Typo on official KAFKA documentation. (by Edward Ribeiro)

Modified:
    kafka/site/08/ops.html
    kafka/site/081/ops.html
    kafka/site/082/ops.html
    kafka/site/083/ops.html

Modified: kafka/site/08/ops.html
URL: http://svn.apache.org/viewvc/kafka/site/08/ops.html?rev=1695598&r1=1695597&r2=1695598&view=diff
==============================================================================
--- kafka/site/08/ops.html (original)
+++ kafka/site/08/ops.html Wed Aug 12 18:55:12 2015
@@ -326,7 +326,7 @@ I/O segregation: if you do a lot of writ
 Application segregation: Unless you really understand the application patterns of other apps
that you want to install on the same box, it can be a good idea to run Zookeeper in isolation
(though this can be a balancing act with the capabilities of the hardware).
 Use care with virtualization: It can work, depending on your cluster layout and read/write
patterns and SLAs, but the tiny overheads introduced by the virtualization layer can add up
and throw off Zookeeper, as it can be very time sensitive
 <p>
-Zookeeper configuration and monitoring: It's java, make sure you give it 'enough' heap space
(We usually run them with 3-5G, but that's mostly due to the data set size we have here).
Unfortunately we don't have a good formula for it. As far as monitoring, both JMZ and the
4 letter commands are very useful, they do overlap in some cases (and in those cases we prefer
the 4 letter commands, they seem more predictable, or at the very least, they work better
with the LI monitoring infrastructure)
+Zookeeper configuration and monitoring: It's java, make sure you give it 'enough' heap space
(We usually run them with 3-5G, but that's mostly due to the data set size we have here).
Unfortunately we don't have a good formula for it. As far as monitoring, both JMX and the
4 letter words (4lw) commands are very useful, they do overlap in some cases (and in those
cases we prefer the 4 letter commands, they seem more predictable, or at the very least, they
work better with the LI monitoring infrastructure)
 Don't overbuild the cluster: large clusters, especially in a write heavy usage pattern, means
a lot of intracluster communication (quorums on the writes and subsequent cluster member updates),
but don't underbuild it (and risk swamping the cluster).
 <p>
 Try to run on a 3-5 node cluster: Zookeeper writes use quorums and inherently that means
having an odd number of machines in a cluster. Remember that a 5 node cluster will cause writes
to slow down compared to a 3 node cluster, but will allow more fault tolerance.

Modified: kafka/site/081/ops.html
URL: http://svn.apache.org/viewvc/kafka/site/081/ops.html?rev=1695598&r1=1695597&r2=1695598&view=diff
==============================================================================
--- kafka/site/081/ops.html (original)
+++ kafka/site/081/ops.html Wed Aug 12 18:55:12 2015
@@ -595,7 +595,7 @@ Operationally, we do the following for a
   <li>I/O segregation: if you do a lot of write type traffic you'll almost definitely
want the transaction logs on a different disk group than application logs and snapshots (the
write to the ZooKeeper service has a synchronous write to disk, which can be slow).</li>
   <li>Application segregation: Unless you really understand the application patterns
of other apps that you want to install on the same box, it can be a good idea to run ZooKeeper
in isolation (though this can be a balancing act with the capabilities of the hardware).</li>
   <li>Use care with virtualization: It can work, depending on your cluster layout and
read/write patterns and SLAs, but the tiny overheads introduced by the virtualization layer
can add up and throw off ZooKeeper, as it can be very time sensitive</li>
-  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMZ and
the 4 letter commands are very useful, they do overlap in some cases (and in those cases we
prefer the 4 letter commands, they seem more predictable, or at the very least, they work
better with the LI monitoring infrastructure)</li>
+  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMX and
the 4 letter words (4lw) are very useful, they do overlap in some cases (and in those cases
we prefer the 4 letter commands, they seem more predictable, or at the very least, they work
better with the LI monitoring infrastructure)</li>
   <li>Don't overbuild the cluster: large clusters, especially in a write heavy usage
pattern, means a lot of intracluster communication (quorums on the writes and subsequent cluster
member updates), but don't underbuild it (and risk swamping the cluster).</li>
   <li>Try to run on a 3-5 node cluster: ZooKeeper writes use quorums and inherently
that means having an odd number of machines in a cluster. Remember that a 5 node cluster will
cause writes to slow down compared to a 3 node cluster, but will allow more fault tolerance.</li>
 </ul>

Modified: kafka/site/082/ops.html
URL: http://svn.apache.org/viewvc/kafka/site/082/ops.html?rev=1695598&r1=1695597&r2=1695598&view=diff
==============================================================================
--- kafka/site/082/ops.html (original)
+++ kafka/site/082/ops.html Wed Aug 12 18:55:12 2015
@@ -853,7 +853,7 @@ Operationally, we do the following for a
   <li>I/O segregation: if you do a lot of write type traffic you'll almost definitely
want the transaction logs on a different disk group than application logs and snapshots (the
write to the ZooKeeper service has a synchronous write to disk, which can be slow).</li>
   <li>Application segregation: Unless you really understand the application patterns
of other apps that you want to install on the same box, it can be a good idea to run ZooKeeper
in isolation (though this can be a balancing act with the capabilities of the hardware).</li>
   <li>Use care with virtualization: It can work, depending on your cluster layout and
read/write patterns and SLAs, but the tiny overheads introduced by the virtualization layer
can add up and throw off ZooKeeper, as it can be very time sensitive</li>
-  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMZ and
the 4 letter commands are very useful, they do overlap in some cases (and in those cases we
prefer the 4 letter commands, they seem more predictable, or at the very least, they work
better with the LI monitoring infrastructure)</li>
+  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMX and
the 4 letter words (4lw) commands are very useful, they do overlap in some cases (and in those
cases we prefer the 4 letter commands, they seem more predictable, or at the very least, they
work better with the LI monitoring infrastructure)</li>
   <li>Don't overbuild the cluster: large clusters, especially in a write heavy usage
pattern, means a lot of intracluster communication (quorums on the writes and subsequent cluster
member updates), but don't underbuild it (and risk swamping the cluster).</li>
   <li>Try to run on a 3-5 node cluster: ZooKeeper writes use quorums and inherently
that means having an odd number of machines in a cluster. Remember that a 5 node cluster will
cause writes to slow down compared to a 3 node cluster, but will allow more fault tolerance.</li>
 </ul>

Modified: kafka/site/083/ops.html
URL: http://svn.apache.org/viewvc/kafka/site/083/ops.html?rev=1695598&r1=1695597&r2=1695598&view=diff
==============================================================================
--- kafka/site/083/ops.html (original)
+++ kafka/site/083/ops.html Wed Aug 12 18:55:12 2015
@@ -852,7 +852,7 @@ Operationally, we do the following for a
   <li>I/O segregation: if you do a lot of write type traffic you'll almost definitely
want the transaction logs on a different disk group than application logs and snapshots (the
write to the ZooKeeper service has a synchronous write to disk, which can be slow).</li>
   <li>Application segregation: Unless you really understand the application patterns
of other apps that you want to install on the same box, it can be a good idea to run ZooKeeper
in isolation (though this can be a balancing act with the capabilities of the hardware).</li>
   <li>Use care with virtualization: It can work, depending on your cluster layout and
read/write patterns and SLAs, but the tiny overheads introduced by the virtualization layer
can add up and throw off ZooKeeper, as it can be very time sensitive</li>
-  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMZ and
the 4 letter commands are very useful, they do overlap in some cases (and in those cases we
prefer the 4 letter commands, they seem more predictable, or at the very least, they work
better with the LI monitoring infrastructure)</li>
+  <li>ZooKeeper configuration and monitoring: It's java, make sure you give it 'enough'
heap space (We usually run them with 3-5G, but that's mostly due to the data set size we have
here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMX and
the 4 letter words (4lw) commands are very useful, they do overlap in some cases (and in those
cases we prefer the 4 letter commands, they seem more predictable, or at the very least, they
work better with the LI monitoring infrastructure)</li>
   <li>Don't overbuild the cluster: large clusters, especially in a write heavy usage
pattern, means a lot of intracluster communication (quorums on the writes and subsequent cluster
member updates), but don't underbuild it (and risk swamping the cluster).</li>
   <li>Try to run on a 3-5 node cluster: ZooKeeper writes use quorums and inherently
that means having an odd number of machines in a cluster. Remember that a 5 node cluster will
cause writes to slow down compared to a 3 node cluster, but will allow more fault tolerance.</li>
 </ul>



Mime
View raw message