1.es
1. 性能優化的殺手鐗：Filesystem Cache
2. 數據預熱
3. 冷熱分離
4. ElasticSearch 中的關聯查詢
5. Document 模型設計
6. 分頁性能優化
https://mp.weixin.qq.com/s/kOVrM0lbzwnJ9qnaHjpuuw
- 倒排詞典的索引需要常駐內存，無法GC，需要監控data node上segment memory增長趨勢。
- 各類緩存，field cache, filter cache, indexing cache, bulk queue等等，要設置合理的大小，並且要應該根據最壞的情況來看heap是否夠用，也就是各類緩存全部佔滿的時候，還有heap空間可以分配給其他任務嗎？避免採用clear cache等“自欺欺人”的方式來釋放內存。
- 避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以採用scan & scroll api來實現。
- cluster stats駐留內存並無法水平擴展，超大規模集羣可以考慮分拆成多個集羣通過tribe node連接。
- 想知道heap夠不夠，必須結合實際應用場景，並對集羣的heap使用情況做持續的監控。
- 根據監控數據理解內存需求，合理配置各類circuit breaker，將內存溢出風險降低到最低。
原文：https://elasticsearch.cn/article/32
內存、索引、分片、routing、導入、refresh、segments等優化總結
原文：https://blog.csdn.net/qq_19364953/article/details/52161252
https://blog.csdn.net/chenxun_2010/article/details/78602795
參數調優實戰
https://blog.csdn.net/ZYC88888/article/details/83184473
2.JVM
java反射的軟引用SoftRefLRUPolicyMSPerMB配置爲0導致頻繁的GC，以及導致GC時間過長
我增加了如下兩個JVM啓動參數來觀察類的加載、卸載信息：-XX:TraceClassLoading -XX:TraceClassUnloading
確定Metaspace增長的元兇是這些類，那麼這些類
sun.reflect.GeneratedSerializationConstructorAccessorXXX
出於性能的考慮，JVM會在反射代碼執行一定次數後，通過動態生成一些類來將”反射調用”變爲“非反射調用”，以達到性能更好。而這些動態生成的類的實例是通過軟引用SoftReference來引用的。
我們知道，一個對象只有軟引用SoftReference，如果內存空間不足，就會回收這些對象的內存；如果內存空間足夠，垃圾回收器不會回收它。只要垃圾回收器沒有回收它，該對象就可以被使用。
當GC發生時，以下幾個因素影響SoftReference引用的對象是否被回收：
1. SoftReference對象實例多久未訪問，通過clock - timestamp得出對象大概有多久未訪問；
2. 內存空閒空間的大小；
3. SoftRefLRUPolicyMSPerMB常量值；
是否保留SoftReference引用對象的判斷參考表達式，true爲不回收，false爲回收：
clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB
說明：
* clock - timestamp：最後一次GC時間和SoftReference對象實例timestamp的屬性的差。就是這個SoftReference引用對象大概有多久未訪問過了
* freespace：JVMHeap中空閒空間大小，單位爲MB。
* SoftRefLRUPolicyMSPerMB：每1M空閒空間可保持的SoftReference對象生存的時長（單位ms）。這個參數就是一個常量，默認值1000，可以通過參數：-XX:SoftRefLRUPolicyMSPerMB進行設置。
查看了一下我們系統的JVM參數配置，發現我們把SoftRefLRUPolicyMSPerMB設置爲0了，這樣就導致軟引用對象很快就被回收了。進而導致需要頻繁重新生成這些動態類。
詳細文章：https://mp.weixin.qq.com/s/6getqxu1-GCo8hJJl8kG8A
https://mp.weixin.qq.com/s/5H6UHcP6kvR2X5hTj_SBjA?
3.避免redis訪問傾斜跟數據傾斜
hot key導致訪問傾斜：
1、可以client本地緩存，但是如何判斷hot key 以及本地內存的大小，還有本地緩存跟redis的一致性保證等問題需要解決
2、利用分片算法的特性，對key進行打散處理,
所以我們可以給hot key加上前綴或者後綴，把一個hotkey 的數量變成 redis 實例個數N的倍數M，從而由訪問一個 redis key 變成訪問 N * M 個redis key。
big key導致數據傾斜
對 big key 存儲的數據 （big value）進行拆分，變成value1，value2… valueN,
- 如果big value 是個大json 通過 mset 的方式，將這個 key 的內容打散到各個實例中，減小big key 對數據量傾斜造成的影響。
//存
mset key1, vlaue1, key2, vlaue2 ... keyN, valueN
//取
mget key1, key2 ... keyN
- 如果big value 是個大list，可以拆成將list拆成。= list_1， list_2, list3, listN
- 其他數據類型同理。
如果既是hot 又是 big，需要提前預判，進行其他策略結合處理。
更詳細參考https://segmentfault.com/a/1190000017387491