出典について
この記事は、Stewart Smith氏のブログ記事「The sad state of MySQL and NUMA」(2015/07/08)を翻訳したものです。
2010年にまで遡ると、MySQL Bug 57241がレポートされ、"swap insanity"問題についての指摘がx86のシステム上ではより深刻になってきた。とりわけ、以後NUMAがより一般的になるに従ってである。
スワップの問題はあるNUMAノード上のメモリが枯渇し、他のノードとスワップせざるを得なくなるためである(Jeremy Cole氏の2010年のswap insanityに関するブログエントリも合わせて参照のこと)。この問題は64GBとデュアルクアッドコアのCPUが大きかった頃はたいした問題にならなかった。一方で、過去5年で大きなシステムはますます巨大化している。
システムを使いものになるようにするには2つの方法があった。
- カーネルブートパラメータでnuma=offとする(これは他の潜在的問題がありそう)
- mysqld_safeスクリプト内で"numactl -interleave all"とする(MariaDBでは現在ではオプションを指定すれば良いように実装されているが、MySQLはしていない、さもなくばこのバグはクローズされているだろう)
ともかく、このバグがオープンされてから約5年が経過しており、Twitter社のMySQLブランチでしばらくの間(数年?)あったパッチ、そして私が2014年の5月(1年以上前)にbug 72811に添付したOCA同意済みのパッチがあるにもかかわらず、我々は何のアクションもとっていない。
私のパッチではサーバ起動時に確保するリソース(バッファプールなど)に対してはノードをまたいで分散させ(interleaved)、随時確保する場合は通常はコネクション毎に確保するのでノードでローカルに確保するためうまく(実際のところは、より良く)機能する、というアプローチをとっている。
このようなパッチがなければ、または正しいnumactlのおまじないでmysqldを起動しない限りは、全てのメモリを1つのNUMAノードで扱うか(ハードウェアの全てのメモリを活用できない可能性がある)、swap insanityになるか、予想もしていない状況に陥るだろう。
我々はMySQLをよりNUMAを意識したものにし、バッファプールインスタンスをNUMA毎にするとかそのようなことができたはずだが、熱心に開発されているデータベースサーバでこのような阻害となる問題がアップストリームで対処されずに過去の7年強が(そのバグへのあるコメントにより)過ぎてしまい失望している。
さらにこれをよりうっとうしくしているのは、ある種の負荷下においては多数のmutexが競合することだ。これはMySQLをより少ないNUMAノード(メモリおよびCPU)と結びつけた結果、性能を向上させることになる(キャッシュラインがそんなに移動する必要がない)ということを結果的に意味することになりうる。これはswap insanityとは異なる問題だが、言及されるべきものである。
更新情報: 私のhttps://bugs.mysql.com/bug.php?id=72811の一部のパッチがマージされた！NUMA構成のマシンにおけるMySQLはずっと良くなった。これがデフォルトで有効化されることを願う。。。
