Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
4年弱前投稿 修正あり

MySQLとNUMAの悲しい現状(Stewart Smith氏のブログより)

"swap insanity"と呼ばれる事象はMySQLがNUMAアーキテクチャで発生する問題として良くしられており、バグがレポートされたのは2010年に遡る。本Stewart Smith氏の記事ではMySQLとNUMAの問題について述べ、これを改良するパッチについても紹介されている。

原文
The sad state of MySQL and NUMA | Ramblings (English)
翻訳依頼者
B5aa4f809000b9147289650532e83932
翻訳者
B5aa4f809000b9147289650532e83932 taka-h
原著者への翻訳報告
未報告


出典について

この記事は、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つの方法があった。

  1. カーネルブートパラメータでnuma=offとする(これは他の潜在的問題がありそう)
  2. 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はずっと良くなった。これがデフォルトで有効化されることを願う。。。

次の記事
【挑戦者求む!】The MySQL 5.7のオプティマイザ チャレンジ
前の記事
InfluxDB専用の可視化フレームワーク「Chronograf」(InfluxDB Blogより)

Feed small 記事フィード

新着記事Twitterアカウント

新着翻訳リクエストTwitterアカウント