Senna 2.0の展望と、Tritonnで問題が発生している人向け情報

Senna

Senna 2.0βのリリースが見えてきました。
去年の夏に出すと言っていましたが、紆余曲折あっての現状です。


ライバルのTokyo Cabinet/Tokyo Dystopiaについては、
ストレージと全文検索インデックスを分割する方向性です。


今までのSennaはTokyo Dystopiaに近いものでしたが、
Senna 2.0では逆にHyper Estraierのほうに近づく感じになっています。
それぞれ特色が出て面白いですねー。
今回は転置インデックス部分にもかなり手が入っているので、
Senna/Lucene/Tokyo Dystopiaのパフォーマンス比較もやってみたいと思います。
（とはいえ、パフォーマンス比較はそれぞれのライブラリに精通しないと意味のある情報が出せないので、大変ではありますね…）


Senna 2.0 + MySQL 5.1用にプラガブルSennaストレージエンジンも開発中です。
後付バイナリインストールができるとかなり運用上楽ですしね。


Senna 2.0のテストについて、今回はクリアコードさんが協力くださっています。
テストには、クリアコードさんが作っているテストフレームワーク「Cutter」を使っています。
早めからバグが潰せていい感じです。


さて、将来の話はここまで。


現在Tritonn/Sennaを運用している方から、
「落ちるんだけど…」とツッコミいただくことがあります。
ツッコミが貰えて、すごく嬉しいですね。
使っていただいていることが分かりますし、
不具合を直す機会にもなります。


というわけで、Tritonn導入時の問題解決に役立つリストを書いてみました。
すぐ解決したいねん、という人は、住商情報システムのサポートサービスをどぞー

Tritonnが落ちるのですが

以下の項目を１つ１つチェックしてみてください。

最新版を使っていない

Tritonnの最新版をお使いください。
旧バージョンには、テンポラリテーブルが削除される場合に落ちる不具合などがあります。
最新版は、COUNT(*)と2indとの組み合わせでカウントがおかしい問題があるようですが、
そろそろ直した版を出すってid:mirさんが言ってたお！

Senna/Tritonnとも現在出ている最新版は安定版なので、
基本アップグレードしたほうが安定します。

  • [追記]

SHOW SENNA STATUSで落ちるのは、
TritonnとSennaのバージョン差異が原因です。
Tritonnで指定しているバージョンのSennaを使うことをオススメします。
（最新版では起こらないと思います）


Sennaの昔のバージョンは、
高負荷の場合に落ちつつしかもその後更新がロックする問題がありましたが、
その問題は現在修正されています。

自前でビルドしている

以前からTritonnをお使いいただいている方は、
自前でMySQLでパッチを当ててTritonnを導入されていると思います。


しかし、現在は自前ビルドはオススメしておりません。
配布されているバイナリを使うことをオススメいたします。

OSがi386である

amd64/em64t版のOSをお使いください。


SennaはmmapというAPIを多用しているので、
論理空間不足にかなり敏感です。
落ちなくするようにすることもやろうと思いますが、
論理空間不足での運用は、パフォーマンスがかなり落ちると思います。

  • [追記]32bit版OSでの制限についての詳細と回避策

概算で、Sennaのインデックスの数 * 256M > 2Gとなると危険水域です。


一時的にでもSennaのインデックスの数が上記を超えるとマズいです。
たとえば、別名テーブルを作成してからrenameする、というような運用だと、
インデックスの数が運用状態の２倍となります。


回避策としては、

  • INITIAL_N_SEGMENTSを減らす(上記の256Mは、INITIAL_N_SEGMENTSに比例します)
  • Sennaのインデックスの数を減らす
  • コンテンツ分割をする

などがあります。


MySQLのレプリケーション運用の場合には、
スレーブごとにインデックスを付与することができます。
それでインデックスを分割するというのが運用的に楽だと思います。
が、em64t対応CPUが普及し、em64t版OSも枯れてきた現状では、
em64t版OSに変えるのが将来的にはオススメできるでしょう。


インデックスの数が多く、コンテンツの量が多い場合には、
物理メモリも十分な量が必要です。
でも、まずは十分な論理空間の確保が先決です。

上記のどれにも当てはまらんぞコラ！

落ちたときに、mysqlのlogに

0809xx 5:xx:xx - mysqld got signal 11;

といったログが出ると思います。
そこに、

Stack range sanity check OK, backtrace follows:
0xdeadbeef
0xcafebabe
0x09286322

といった16進数値の羅列が出ていませんか？
Tritonnで配布しているバイナリを使っていれば、
この数値の羅列から、不具合の場所を大体特定することができます。


というわけで、この16新数値の羅列をTritonn-devやSenna-devメーリングリストなどに投げていただければ幸いです。
すでに多くの不具合は修正されているため、
残りの不具合についてはかなりのレアケースであることが考えられます。
よって、ツッコミをいただかないと、なかなか修正が出来なかったりするのです…


というわけでレッツツッコミ。４９４６。

CentOS 5.2でTritonnの最新版のrpmの導入に失敗します！

akiyan.comのブログを見て、導入方法を書かねば…と思い僕も実際試してみました。

しかし、Tritonnで配っているrpmを導入すると、

/etc/init.d/mysql start

が失敗するんですね。僕の手元の環境でも再現しました。
Tritonn作者であるid:mirさんにお伝えしておきました。


ちなみに、libmysqlclient.soが見つからない問題は、
mysql-devel的なパッケージをどこからか持ってくることによって解決することが出来ると思います。
が、これについてもtritonn側で配布してくれたら親切だとは思います。