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使ってたらしいと聞いたので調べてみたら以下のページに当たりました。 rsyncの bwlimit
を指定するなんて方法もあったらしいです。当時は maxWriteMBPerSec
無かったみたいですし。
Solrでrsyncによるレプリケーション - skozawa's blog
参考URL
Index Replication - Apache Solr Reference Guide - Apache Software Foundation