anchor.diff:  Setting the same value for initial (`-Xms`) and maximum (`-Xmx`) heap sizes avoids the JVM having to allocate memory after startup, at the cost of possibly allocating more heap than is really needed.
   
   IMPORTANT: Containers performing lots of disk I/O, such as Kafka broker containers, require available memory for use as an operating system page cache.
  -On such containers, the requested memory should be significantly higher than the memory used by the JVM.
  +For such containers, the requested memory should be significantly higher than the memory used by the JVM.
   
   .-XX option
   
  
positive.code:   trustedCertificates: []
  ----
  
  For information on configuring TLS client authentication, see xref:type-KafkaClientAuthenticationTls-reference[`KafkaClientAuthenticationTls` schema reference].
  
  [id='con-common-configuration-resources-{context}']
  === `resources`
  
negative.code: 
  You can specify the following options in your configuration:
  
  `-Xms`:: Minimum initial allocation heap size when the JVM starts
  `-Xmx`:: Maximum heap size
  `-XX`:: Advanced runtime options for the JVM
  `javaSystemProperties`:: Additional system properties
  `gcLoggingEnabled`:: xref:con-common-configuration-garbage-collection-{context}[Enables garbage collector logging]
  
  NOTE: The units accepted by JVM settings, such as `-Xmx` and `-Xms`, are the same units accepted by the JDK `java` binary in the corresponding image.
  Therefore, `1g` or `1G` means 1,073,741,824 bytes, and `Gi` is not a valid unit suffix.
  This is different from the units used for xref:con-common-configuration-resources-reference[memory requests and limits], which follow the Kubernetes convention where `1G` means 1,000,000,000 bytes, and `1Gi` means 1,073,741,824 bytes.
  
  .`-Xms` and `-Xmx` options
  
  Specify heap configuration for your components using the `-Xms` option to set an initial heap size and the `-Xmx` option to set a maximum heap size.
  
  If you don't specify heap configuration, but configure memory request or limit, the Cluster Operator imposes default heap sizes automatically.
  
  The Cluster Operator sets maximum and minimum heap values based on a percentage allocation of available memory in the node.
  
  The following table shows the default heap values.
  
  .Default heap settings for components
  [cols="4,2,2",options="header"]
  |===
  
  |Component
  |Percent of available memory allocated to the heap
  |Maximum limit
  
  |Kafka
  |50%
  |5 GB
  
  |ZooKeeper
  |75%
  |2 GB
  
  |Kafka Connect
  |75%
  |None
  
  |MirrorMaker 2.0
  |75%
  |None
  
  |MirrorMaker
  |75%
  |None
  
  |Cruise Control
  |75%
  |None
  
  |Kafka Bridge
  |50%
  |31 Gi
  
  |===
  
  Heap configuration values should make the best use of a container's xref:con-common-configuration-resources-reference[memory request] without exceeding it.
  
  * If a memory request or limit is specified, a JVM's minimum and maximum memory is set to a value corresponding to the limit.
  * If a memory request or limit is not specified, a JVM's minimum memory is set to `128M`.
  The JVM's maximum memory is not defined to allow the memory to increase as needed. This is ideal for single node environments in test and development.
  
  Total JVM memory usage can be a lot more than the maximum heap size.
  
  Setting an appropriate memory request can prevent the following:
  
  * Kubernetes killing a container if there is pressure on memory from other pods running on the node.
  * Kubernetes scheduling a container to a node with insufficient memory.
  If `-Xms` is set to `-Xmx`, the container will crash immediately; if not, the container will crash at a later time.
  
  In this example, the JVM uses 2 GiB (=2,147,483,648 bytes) for its heap.
  Its total memory usage is approximately 8GiB.
  