Memory and JVM Tuning

Bu makale, native persistence veya external storage içeren ve içermeyen dağıtımlarla ilgili bellek ayarı için best-practice’leri içerir. Ignite, verileri ve indexleri Java Heap dışında depolasa da, Java Heap, uygulamalarınız tarafından yürütülen sorgular ve işlemler tarafından oluşturulan nesneleri depolamak için hala kullanılır. Bu nedenle, JVM ve çöp toplama (GC) ile ilgili optimizasyonlar için belirli öneriler dikkate alınmalıdır.

Tune Swappiness Setting

Bir işletim sistemi, genel RAM kullanımı belirli bir eşiğe ulaştığında sayfaları RAM'den diske değiştirmeye başlar. Swapping, Ignite cluster performansını etkileyebilir. Bunun olmasını önlemek için işletim sisteminin ayarını değiştirebilirsiniz. Unix için en iyi seçenek, vm.swappiness parametresini 10'a düşürmek veya native persistence etkinse 0'a ayarlamaktır;

sysctl -w vm.swappiness=0

Bu ayarın değeri, GC duraklamalarını da uzatabilir. Örneğin, GC logları low user time, high system time, long GC pause kayıtları gösteriyorsa, bunun nedeni Java heap sayfalarının içeri ve dışarı swap edilmesi olabilir. Bunu ele almak için yukarıdaki swappinessayarlarını kullanın.

Share RAM with OS and Apps

Tek bir makinenin RAM'i işletim sistemi, Ignite ve diğer uygulamalar arasında paylaşılır. Genel bir öneri olarak, bir Ignite cluster saf in-memory modda deploy edilirse(native persistence devre dışıdır), o zaman RAM kapasitesinin %90'ından fazlasını Ignite node’larına ayırmamalısınız.

Öte yandan, native persistence kullanılıyorsa, işletim sistemi, verileri diske en iyi şekilde eşitlemek için page cache için fazladan RAM gerektirir. Page cache devre dışı değilse, Ignite'a sunucu RAM'inin %70'inden fazlasını vermemelisiniz.

Yapılandırma örnekleri için bellek yapılandırmasına bakın.

Buna ek olarak, native persistence’ın kullanılması yüksek page cache kullanımına neden olabileceğinden, kswapd arka plan programı, arka planda page cache tarafından kullanılan page reclamation’a ayak uyduramayabilir. Sonuç olarak, bu, doğrudan page reclamation nedeniyle yüksek gecikmelere neden olabilir ve uzun GC duraklamalarına neden olabilir.

Linux'ta page memory reclamation’ın neden olduğu etkileri gidermek için /proc/sys/vm/extra_free_kbytes ile wmark_min ve wmark_low arasına fazladan bayt ekleyin;

sysctl -w vm.extra_free_kbytes=1240000

Page cache ayarları, yüksek gecikmeler ve uzun GC duraklamaları arasındaki ilişki hakkında daha fazla bilgi için bu kaynağa başvurun.

Java Heap and GC Tuning

Ignite, verileri kendi off-heap bellek bölgelerinde Java garbage collectorleri tarafından görülmez halde tutsa da Java Heap, uygulamalarınızın iş yükleri tarafından oluşturulan nesneler için kullanılmaya devam eder. Örneğin, bir Ignite cluster’ına karşı SQL sorguları çalıştırdığınızda, sorgular off-heap bellekte saklanan verilere ve indexlere erişirken, bu tür sorguların sonuç kümeleri, uygulamanız sonuç kümelerini okuyana kadar Java Heap'te tutulur. Bu nedenle, işlem hacmine ve türüne bağlı olarak, Java Heap hala yoğun bir şekilde kullanılabilir ve bu, iş yükleriniz için JVM ve GC ile ilgili ayarlamalar gerektirebilir.

Aşağıda bazı genel önerilere ve en iyi uygulamalara yer verilmiştir.

Generic GC Settings

Aşağıda, server node’larında Java Heap'i yoğun bir şekilde kullanabilen, dolayısıyla GC duraklamalarını tetikleyebilen uygulamalar için örnek JVM yapılandırma grupları bulunmaktadır.

JDK 1.8+ dağıtımları için G1 garbage collector kullanmalısınız. 10 GB heap, server node’larınız için fazlasıyla yeterliyse, aşağıdaki ayarlar iyi bir başlangıç noktasıdır:

-server
-Xms10g
-Xmx10g
-XX:+AlwaysPreTouch
-XX:+UseG1GC
-XX:+ScavengeBeforeFullGC
-XX:+DisableExplicitGC

G1 sizin için çalışmıyorsa, CMS collector kullanmayı ve aşağıdaki ayarlarla başlamayı düşünün. Örnek olarak 10 GB heap’in kullanıldığını ve kullanım durumunuz için daha küçük bir heap’in yeterli olabileceğini unutmayın:

-server
-Xms10g
-Xmx10g
-XX:+AlwaysPreTouch
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
-XX:+ScavengeBeforeFullGC
-XX:+CMSScavengeBeforeRemark
-XX:+DisableExplicitGC

Ignite persistence kullanıyorsanız, MaxDirectMemorySize JVM parametresini `walSegmentSize 4` olarak ayarlamanız önerilir. Varsayılan WAL ayarları ile bu değer 256MB'ye eşittir.*

Advanced Memory Tuning

Linux ve Unix ortamlarında, bir uygulamanın I/O nedeniyle uzun GC duraklamaları veya düşük performansla karşılaşması veya kernel’e özgü ayarlar nedeniyle belleğin yetersiz kalması mümkündür. Bu bölüm, uzun GC duraklamalarının üstesinden gelmek için kernel ayarlarının nasıl değiştirileceğine ilişkin bazı yönergeler sağlar.

⚠️ Aşağıda verilen tüm shell komutları RedHat 7'de test edilmiştir. Linux dağıtımınıza göre farklılık gösterebilirler. Kernel ayarlarını değiştirmeden önce, gerçekten bir sorununuz olduğunu doğrulamak için sistem istatistiklerini/loglarını kontrol ettiğinizden emin olun. Productionda Linux kernel düzeyinde değişiklik yapmadan önce BT departmanınıza danışın.

GC logları low user time, high system time, long GC pause gösteriyorsa, büyük olasılıkla bellek kısıtlamaları boş bir bellek alanının değiştirilmesini veya taranmasını tetikliyor.

• Swappiness ayarlarını kontrol edin ve düzenleyin.
• Başlangıçta JVM ayarlarına -XX:+AlwaysPreTouch ekleyin.
• NUMA zone-reclaim optimizasyonunu devre dışı bırakın.

  sysctl -w vm.zone_reclaim_mode=0
• RedHat dağıtımı kullanılıyorsa Transparent Huge Pages’i kapatın.

  echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
  echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

Advanced I/O Tuning

GC logları low user time, high system time, long GC pause gösteriyorsa, GC threadleri kernel alanında çeşitli I/O etkinlikleri tarafından bloke edilerek çok fazla zaman harcıyor olabilir. Örneğin, buna günlük commitleri, gzip veya log roll over prosedürleri neden olabilir.

Çözüm olarak, sayfa temizleme aralığını varsayılan 30 saniyeden 5 saniyeye değiştirmeyi deneyebilirsiniz:

sysctl -w vm.dirty_writeback_centisecs=500
sysctl -w vm.dirty_expire_centisecs=500