Tetsuro IKEDA
ikdtt****@gmail*****
2006年 12月 8日 (金) 15:49:52 JST
池田です。 以前私がMySQL 5.0系+glibc2.3+Linux Kernel 2.6系で 負荷テストしたときには、特に落ちるというのはなかったですが。。。 当時のSennaのバージョンは0.7系だったと思います。 40万レコード/850MB、160万レコード/3.4GBのテーブルに対して、 wait無しで接続数1〜200弱まで変えながら参照系・更新系の 負荷テストをしていました。 initial_n_segmentsはデフォルトのままです。 本来はこれを多めに設定したほうが更新性能があがるようですが。 落ちる・止まる等の再現手順が分かれば、 教えてください。 あと、↓こんな感じのエラーメッセージをmysqldが出した場合には、 > mysqld got signal 10; > This could be because you hit a bug. > (...) > > key_buffer_size=33554432 > read_buffer_size=1044480 > max_used_connections=3 > max_connections=35 > threads_connected=1 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size) > *max_connections = 104307 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. 以下のURLを参考に、スタックトレースのシンボル名を解決した上で、 教えていただけると、何かわかるかもしれません。 http://dev.mysql.com/doc/refman/5.0/en/using-stack-trace.html
