Solrのレプリケーション帯域幅を制御してI/Oパフォーマンスを制御する

Solrのレプリケーションが原因で、EC2のSolrサーバが定期的にIOボトルネックのパフォーマンス劣化起こしてたので、対応としてレプリケーション帯域幅を制御できるパラメータ( maxWriteMBPerSec )を使ったのでメモ。

経緯

最初はI/Oボトルネック解消のためにEBS複数連ねてRAID0でIOPS増やしたりしたのですが改善せず。 もう少し調べるとIOPSではなくEC2とEBS間の帯域制限にひっかかっていたことが判明しました。

Amazon EBS 最適化インスタンス - Amazon Elastic Compute Cloud

Solrのレプリケーションでコアのサイズが大きいとインデックスファイルが一気に書き込まれて、制限ギリギリまで帯域幅を使ってしまうことが原因でした。

帯域幅の制限を上げるためにはインスタンスタイプを上げる必要ありますが、それはお金がかかるし、レプリケーションのスピード落としてもいいからI/Oスパイク避ける方法として maxWriteMBPerSec パラメータが使えます。

設定

設定方法は以下のドキュメント書いてあります。

Index Replication - Apache Solr Reference Guide - Apache Software Foundation

こんな感じです。

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="master">
    <str name="replicateAfter">optimize</str>
    <str name="backupAfter">optimize</str>
    <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
    <str name="commitReserveDuration">00:00:10</str>
  </lst>
  <int name="maxNumberOfBackups">2</int>
  <lst name="invariants">
    <str name="maxWriteMBPerSec">16</str>
  </lst>
</requestHandler>

効果

グラフはSARで1秒間隔の値を取得したものです。想定通りスパイクしてたI/Oがならされました。

補足

後で見て気付きましたが、今新しくSolr入れるとサンプル設定ファイルにデフォルトで入ってるんですね。

ちなみに、昔はrsync使ってたらしいと聞いたので調べてみたら以下のページに当たりました。 rsyncbwlimit を指定するなんて方法もあったらしいです。当時は maxWriteMBPerSec 無かったみたいですし。

Solrでrsyncによるレプリケーション - skozawa's blog

参考URL

Index Replication - Apache Solr Reference Guide - Apache Software Foundation