SkyWalking 性能優化

OAP優化

skywalking寫入ES的操作是使用了ES的批量寫入接口，我們要做的是調整相關參數盡量降低ES索引的寫入頻率。

參數調整主要是針對skywalking的配置檔案

application.yml

，相關參數如下：

storage:
  elasticsearch:
    bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:4000} # Execute the bulk every 2000 requests
    bulkSize: ${SW_STORAGE_ES_BULK_SIZE:40} # flush the bulk every 20mb
    flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:30} # flush the bulk every 10 seconds whatever the number of requests
    concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:4} # the number of concurrent requests
    metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:8000}      

• 調整bulkActions預設2000次請求批量寫入一次改到4000次；

• bulkSize批量重新整理從20M一次到40M一次；

• flushInterval每10秒重新整理一次堆改為每30秒重新整理；

• concurrentRequests查詢的最大數量由5000改為8000。

參考網址：

https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html

ES優化

JVM參數調整

此部分主要是針對es的配置檔案jvm.options

• 配置修改

根據伺服器配置調整JVM參數，需要設定-Xmn參數指定新生代的大小，-Xmn的值可以設定成-Xmx的3/8左右：

-Xms6g
-Xmx6g
-Xmn2g      

• 解釋說明

這裡說明一下為什麼要顯式指定-Xmn的大小。在剛開始我也沒設定-Xmn參數，但是通過觀察gc日志發現ES一直在頻繁進行Young GC,達到1秒一次。而且新生代大小小于理論配置大小。

gc日志：

[2019-12-23T03:24:11.002+0000][1][gc,heap      ] GC(269053) ParNew: 419674K->11981K(460096K)
[2019-12-23T03:24:11.002+0000][1][gc,heap      ] GC(269053) CMS: 1646907K->1646907K(2634560K)
[2019-12-23T03:24:11.002+0000][1][gc,metaspace ] GC(269053) Metaspace: 86889K->86889K(1130496K)      

當時設定的-Xmx 和 -Xms為3g，如果按照預設配置-XX:NewRatis=2那麼新生代應該有1g左右，但是實際上隻有460M，為了減少Young gc的頻率需要顯式使用-Xmn指定新生代大小。

大家可以參考博文

CMS GC 預設新生代是多大？

，很好的解釋了為什麼CMS垃圾回收時預設新生代的大小不是根據-XX:NewRatis=2計算而得。

索引參數優化

給ES配置高性能寫模式主要是修改es配置檔案elasticsearch.yml中的index相關配置，主要修改如下幾個參數

"index.merge.scheduler.max_thread_count" : "1",
 "index.refresh_interval" : "30s",
 "index.translog.durability" : "async",
 "index.translog.sync_interval" : "120s"      

https://www.elastic.co/guide/en/elasticsearch/reference/6.8/tune-for-indexing-speed.html

結語

本篇主要是針對skywalking單機版優化，由于skywalking對es的操作非常多，如果單機版es扛不住的話還是最好還是使用skywalking的叢集模式。