調整Java資源

調整Java虛擬機（JVM）可以提高性能減少內存消耗。

本頁面的主題：

關於垃圾收集
選擇一個Java垃圾收集器
將G1設置爲Java垃圾收集器
確定堆大小
Cassandra如何使用內存 - 請先閱讀以便更好地理解本主題中的設置和建議。
調整其他Cassandra服務的JVM參數
其他JMX選項

關於垃圾收集

垃圾收集是Java從內存中刪除不再需要的數據的過程。爲了獲得最佳性能，選擇正確的垃圾收集器和堆大小設置非常重要。

你一定要最小化的一種情況是垃圾收集暫停，也稱爲“停止世界”事件。當內存區域已滿並且JVM需要騰出空間繼續時，會發生暫停。在暫停期間，所有操作都暫停。由於暫停會影響網絡，因此節點可能會顯示爲集羣中的其他節點。另外，任何Select和Insert語句都會等待，這會增加讀取和寫入延遲。應該避免任何一秒以上的停頓，或者一秒鐘內多次暫停，這會增加大部分的秒數。問題的根本原因是存儲在內存中的數據的速度超過了數據可以被刪除的速度。有關特定的症狀和原因，請參閱垃圾回收暫停。

選擇一個Java垃圾收集器

對於Cassandra 3.0及更高版本，使用Concurrent-Mark-Sweep（CMS）或G1垃圾收集器取決於以下因素：

1.建議在以下情況下使用G1：

堆大小從14 GB到64 GB。
G1對於較大的堆執行效果要好於CMS，因爲它首先掃描包含大多數垃圾對象的堆的區域，並在堆棧中進行壓縮，而CMS在執行垃圾回收時會停止應用程序。
工作負載是可變的，也就是說，集羣一直在執行不同的進程。
爲了將來考慮，CMS將在Java 9中被棄用。
G1更容易配置。
G1是自我調節。

2.在以下情況下推薦使用CMS：

您有時間和專業知識來手動調整和測試垃圾回收。
請注意，爲堆分配更多的內存可能會導致性能下降，因爲垃圾收集工具增加了堆內存中Cassandra元數據的數量。
堆大小不超過14 GB。
工作負載是固定的，也就是說，集羣始終執行相同的過程。
環境需要儘可能低的延遲。由於分析，G1會導致一些延遲。

注：有關配置CMS的幫助，請聯繫DataStax服務團隊。

將G1設置爲Java垃圾收集器

打開jvm.options。
註釋掉該-Xmn800M行。
註釋掉### CMS Settings部分中的所有行。
取消註釋部分中的相關G1設置### G1 Settings ：

## Use the Hotspot garbage-first collector.
-XX:+UseG1GC

## Have the JVM do less remembered set work during STW, instead
## preferring concurrent GC. Reduces p99.9 latency.
#-XX:G1RSetUpdatingPauseTimePercent=5

注意：使用G1時，只需要設置MAX_HEAP_SIZE。

確定堆大小

您可能會試圖設置Java堆來佔用計算機的大部分RAM。但是，這會干擾操作系統頁面緩存的操作。操作系統爲經常訪問的數據維護OS頁面緩存，並將這些數據保存在內存中。正確地調整OS頁面緩存通常會比增加Cassandra行緩存帶來更好的性能。

Cassandra根據以下公式自動計算最大堆大小（MAX_HEAP_SIZE）：

max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)

對於生產用途，您可能希望使用以下準則調整環境的堆大小：

堆大小通常在系統內存的¼和½之間。
不要把所有的內存堆放在堆上，因爲它也用於離堆緩存和文件系統緩存。
調整GC時始終啓用GC記錄。
逐漸調整設置並測試每個增量更改。
啓用GC的並行處理，特別是在使用DSE搜索時。
Cassandra的GCInspector類記錄有關任何垃圾收集的時間超過200毫秒的信息。垃圾收集頻繁發生並需要一定的時間（秒）才能完成，這表明JVM上的垃圾收集壓力過大。除了調整垃圾收集選項之外，其他的補救措施還包括添加節點以及降低緩存大小。
對於使用G1的節點，Cassandra社區建議儘可能大的MAX_HEAP_SIZE，最大爲64 GB。

注意： 有關更多調整技巧，請參閱Secret HotSpot選項，以改善大堆中的GC暫停。

MAX_HEAP_SIZE
建議的最大堆大小取決於使用哪個GC：

硬件設置	推薦MAX_HEAP_SIZE
舊計算機	通常8 GB
適用於新型計算機（8+核心）的CMS，最高可達256 GB RAM	沒有更多的14 GB
G1用於更新的計算機（8+核心），最高可達256 GB RAM	14 GB到64 GB

爲您的環境確定最佳堆大小的最簡單方法是：

將jvm.options文件中的最大堆大小設置爲單個節點上的高任意值。例如，使用G1時：

-Xms48G
-Xmx48G

將min（-Xms）和max（-Xmx）堆大小設置爲相同的值，以避免在調整大小期間停止GC世界的暫停，並在啓動時鎖定內存中的堆，以防止其中的任何內容被換出。

啓用GC日誌記錄。
檢查日誌以查看該節點使用的堆，並使用該值設置羣集中的堆大小：

注意：此方法會降低測試節點的性能，但通常不會顯着降低羣集性能。

HEAP_NEWSIZE

對於CMS，您可能還需要調整HEAP_NEWSIZE。此設置確定分配給newer objects或young generation的堆內存量。Cassandra計算此屬性的默認值（以MB爲單位）：

內核數的100倍
¼MAX_HEAP_SIZE
作爲一個起點，將HEAP_NEWSIZE設置爲每個物理CPU核心100 MB。例如，對於一個現代的8核心+機器：

-Xmn800M

較大的HEAP_NEWSIZE會導致更長的GC暫停時間。對於較小的HEAP_NEWSIZE，GC暫停較短，但通常較expensive。

Cassandra如何使用內存

Cassandra在JVM堆中執行以下主要操作：

爲了執行讀取，Cassandra在堆內存中維護以下組件：
- Bloom filters（布隆過濾器）
- Partition summary（分區摘要）
- Partition key cache（分區鍵緩存）
- Compression offsets（壓縮偏移）
- SSTable index summary（SSTable索引摘要）
Cassandra收集副本read或anti-entropy repair，並比較堆內存中的副本。
寫入Cassandra的數據首先存儲在堆內存的memtables中。Memtables被刷新到磁盤上的SSTables。

注意：這些元數據駐留在內存中，並且與總數據成正比。一些組件與總內存大小成比例的增長。

爲了提高性能，Cassandra也使用堆外存儲器，如下所示：

頁面緩存。當讀取磁盤上的文件時，Cassandra使用額外的內存作爲頁面緩存。
布隆過濾器和壓縮偏移映射位於堆外。
Cassandra可以將緩存的rows存儲在Java堆外的本機內存中。這減少了JVM堆的需求，這有助於將堆大小保持在JVM垃圾回收性能的最佳位置。

調整其他Cassandra服務的JVM參數

Solr：一些Solr用戶報告說，增加堆棧大小可以提高Tomcat的性能。
要增加堆棧大小，請取消註釋並修改cassandra-env.sh文件中的默認設置。
另外，減少memtable空間爲Solr緩存騰出空間可以提高性能。通過更改cassandra.yaml文件中的memtable_heap_space_in_mb和memtable_offheap_space_in_mb屬性來修改memtable空間。

# Per-thread stack size.
JVM_OPTS="$JVM_OPTS -Xss256k"

MapReduce：由於MapReduce在JVM之外運行，對JVM的更改不會直接影響Analytics / Hadoop操作。

其他JMX選項

Cassandra通過Java Management Extensions（JMX）公開統計和管理操作。JConsole和nodetool是符合JMX的管理工具。

通過在cassandra-env.sh中編輯這些屬性來配置Cassandra進行JMX管理。

com.sun.management.jmxremote.port：設置Cassandra從JMX連接偵聽的端口。
com.sun.management.jmxremote.ssl：爲JMX啓用或禁用SSL。
com.sun.management.jmxremote.authenticate：啓用或禁用JMX的遠程認證。
-Djava.rmi.server.hostname：設置JMX應該用來連接的接口主機名或IP。如果連接有問題，請取消註釋並設置。

注意：默認情況下，您可以使用端口7199上的JMX與Cassandra進行交互，而無需進行身份驗證。

調整Java資源