コミケ85に「低級はっかーズ」として出展します。3日目(火曜日)西せ18aです。
今回の新刊は "Linux Kernel Updates 2013.12" です。価格は300円です。内容は
TCP/IPチューニング特集は主にsysctlのパラメータを解説しています。自称日本語で一番詳しい解説になっています！
表紙は毎度おなじみきのとなおとさんに描いていただきました。
前回までの既刊2冊も持っていきます。こちらも一冊300円です。よろしくお願いします！
この記事はMySQL Casual Advent Calendar 2013の16日目の記事です。
MySQLのマスタ冗長化のいち手段としてMHAというものがあります。マスタが落ちた時に自動的にスレーブに切り替えてくれます。詳しいアーキテクチャは公式ページやそこから辿れるスライドに詳しいのでそちらを参照していただくとして、ここではカジュアルに導入の時に詰まった店を挙げます。
幾つかはバグらしきものも含まれているので、後ほど公式にレポートしようと思います。
MySQLのパスワードに一部の記号が入っていると認証が通りませんでした。コードを見るとエスケープして戻して、MySQL向けのエスケープしたりシェル向けのエスケープをしたりと入り組んでいたので、どこかで対応が崩れているのかと思いましたが他にもこの種の問題はありそうなのでとりあえず記号を使わないパスワードに変更して乗り切りました。
MHAのスクリプトはすべてshebangが "#!/usr/bin/env perl" になっています。make installしても変わりません。ところで、#!/usr/bin/envはイマイチという噂もありますが、これperlbrewと相性が極端に悪くって、システムperlのパッケージを入れてもperlbrewのほうが実行されてライブラリが見つからなかったり逆にperlbrewに入れたのにシステムperlのほうが実行されたりして危ないのです。今回はすべてperlbrewの方に統一することにしました。
たぶんmake installする際に書き換えるのが正解だと思います。
MySQL 5.6の新機能でmaster-infoやrelay-log-infoがテーブルに入れれるようになりましたが、これがMHAではうまく動きませんでした。コードを見ると一見サポートしてそうに見えるのですが、マスタはrelay-log-infoが無いのにrelay-log-infoをSELECTして、見つからないのでエラーで止まります。ファイルの場合はちゃんと動くのですけどね。というわけで今回はファイルで使うことにしました。
これはMySQLに常に付きまとう問題ですしもはや仕様なのですが、例えばpurge_relay_logsを動かそうとするとオプション引数にパスワードを平分で書く必要があります。crontabをちゃんと一定のユーザーに設定すれば見られる危険は少ないですが、気持ち悪いですね。
failoverするときに使うサンプルスクリプトが付属していますが、これから参照されているSSHのオプション定数がちょっとおかしいです。
our $SSH_OPT_CHECK = "-o StrictHostKeyChecking=no -o PasswordAuthentication=no -o BatchMode=yes -o ConnectTimeout=VAR_CONNECT_TIMEOUT";
VAR_CONNECT_TIMEOUT って謎の定数らしきものが使われていて、sshがinvalid time valueと言って死にます。ちょっとハマりました。
MHAはthree tier以上のレプリケーションも限定的にサポートしているのですが、これは一番上のマスタを登録する必要があります。新しいマスタスレーブのペアを既存のマスタにぶら下げて切り替えるという時に、既存のマスタへ新しいマスタからレプリケーションが走っていると、MHAがその既存のマスタに飛んでいって「Master %s:%d from which slave %s replicates is not defined in the configuration file!」というエラーメッセージとともに死にます。ので、新しいセットにMHAを入れてから切り替えようということはできません。
切り替えてからMHAを起動すればいいだけなのですが、どうしようか少し悩みました。
MHAは最近failoverした時刻を .failover.complete というファイルで管理していて、最近failoverしたばっかりでもう一度failoverしようとすると、「Current time is too early to do failover again.」というエラーで止まります。毎回手動でファイルを削除する必要があって少し面倒でした。
問題点ばかり列挙しましたが、MHAは実績のある限られたマスタ冗長化ツールです。一度導入してしまえば安眠できると思います。これからパッチやバグレポートを書きます...
明日はYuya Takeyamaさんです。
AWS EC2に新しいc3世代のインスタンスタイプが追加されたのですが、値段あたりの処理性能がいまいちわからなかったのでHeavy Reserved Instanceを1年使う計算で比べてみました。比較対象は c1.xlarge, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge, cc2.8xlargeです。3年でもあんまり変わらないと思います。リージョンはバージニアです。
というわけで値段あたりのCPUパワーが一番いいのはcc2.8xlargeでした。c3世代はSSD搭載なので、SSDほしい時は選択肢が変わってくると思いますが、単純にCPUだけほしい、という時はcc2.8xlargeが良さそうです。c3世代より2割ぐらい安い計算になりました。
備忘録的な記事で雑なまとめですがこのへんで。
MySQL Performance Blogにtcmalloc/jemallocを使うとパフォーマンスが良くなるという記事があるので、気になって手元の環境でも計測してみました。
| CPU | Intel Xeon CPU E5-2620 x 2 |
|---|---|
| OS | CentOS 6.4 64bit |
| MySQL | MySQL 5.6.14 |
| sysbench | Sysbench 0.4.12 |
| jemalloc | jemalloc 3.4.1 |
| tcmalloc | gperftools 2.1 |
MySQLのmax_connectionsは2048に設定しました。innodb_file_formatはBarracudaで、Buffer poolは56GBを確保し、buffer pool instanceは32に設定しました。
sysbench の OLTP テストを下記のようなコマンドで走らせました。
for t in 16 32 64 128 256 512 1024; do sysbench --test=oltp --oltp-table-size=1000000 --mysql-user=benchuser --mysql-password=benchuser --db-driver=mysql --num-threads=$t --max-requests=200000 --oltp-read-only run; done for t in 16 32 64 128 256 512 1024; do sysbench --test=oltp --oltp-table-size=1000000 --mysql-user=benchuser --mysql-password=benchuser --db-driver=mysql --num-threads=$t --max-requests=200000 run; done
jemalloc の nodirty というのは "MALLOC_CONF=lg_dirty_mult:-1" という環境変数をセットしたものです。これは3.2以降性能がベンチマークによっては劣化することがあるというので気になって測りました。
tcmalloc + large page は、my.cnf に large-page を付けてMySQLを起動したものです。read/writeは取り忘れたのでreadのみです。
なお試行回数は1回で、ベンチマークを2回走らせた2回目の値です(平均とか取ってません)。測定のたびにmysqlを再起動し、cleanup/prepareを実施しました。
allocatorの差し替えは/etc/init.d/mysqlにexport LD_PRELOAD=...を記述する方法を取りました。ロードされていることは/proc/{pid}/mapsを見て確認しました。
read/writeに関しては、測定のばらつきが大きく、実行するたびに2割程度は差が出る結果になりましたのであまり信頼の高い結果ではありません。jemallocはスレッド数が1024の場合にのみ、glibc mallocより22%程度高速という結果になりました。tcmallocは16-32スレッドの場合は最大2割遅く、64スレッド以上では1割程度高速でした。
readは比較的安定した結果が出ました。jemallocはglibc mallocと比較し5%程度遅くなりました。tcmallocはglibc mallocと同等または高速で、最大3%程度の差が出ました。
tcmallocでlarge-pageを有効にしても有意な差は見られませんでした。これは今回のデータサイズが小さく、TLBサイズが変わってもヒット率が変わらなかった可能性があります。
MySQL Performance blogに掲載されていたような、256スレッド以上ではglibcが遅くなるという現象は見られませんでした。また、jemallocがtcmalloc/glibc mallocとくらべて低速であるという結果になりました。これは設定によるのか、ベンチマークの種類によるのかはわかりませんが、必ずしもjemallocやtcmallocに差し替えることによってMySQLの性能が向上するとは言えない結果になりました。ただしtcmallocはglibc mallocより遅いことはなかったので、差し替えることによってデメリットはメモリの消費量が増える以外は生じないので、メモリに余裕があるのであれば検討してもよいかと思いました。
元のblogでは64スレッドを超えると1万transactions/secを超えているのに対し、こちらではたかだか5000スレッドしか出てません。向こうは32スレッドあるのでこちらより性能が良いのですが、それでも少し性能が低い気がします。ですので、何か設定がまずいのか、それともallocatorが実は差し替わっていない可能性も残っています。
transactions/secだけではなく、CPU使用率やレイテンシにも着目するべきですが、それは今後の課題とします。
Linux女子部主催のFedora最新技術情報＆Systemd勉強会に参加してきました。
講師は藤田稜さん
Fedora最新技術情報といいつつRHEL7のお話でした。いくつか気になった点をピックアップします。
RHEL7ではxfsをデフォルトファイルシステムにしたいそうですが、まだ安定性やメモリ消費量に難があり、技術的な観点から決定はしていないそうです。
「RHEL 4, 5, 6 の初期出荷でファイルシステムの破損バグを仕込んだ実績があるので、今からxfsに切り替えたら絶対何か踏む」という声も。
今までファイアウォールはiptablesを使っていましたが、標準でfirewalldを使うように変更します。従来のiptablesとは排他利用になります。戻すことはできますが、基本的にはfirewalld推奨とのこと。設定を読み込み直すときにreloadしてもセッションが切れなくなっているそうです。
またそれに伴いNetworkManagerが必須となるようで、今まで殺していた人はうまく付き合ってくださいとのことでした。
OpenLMIという管理系機能の共通インタフェースがあるそうなんですが、それがRHEL 7.0GAには入るんじゃないかということ。従来例えばファイルシステムだけ取っても fdisk, gparted, lvm, mkfs など様々なコマンドがバラバラにあったものが、整理され統合されるんだとか。
その他は、systemd入りますよ(後述)、Linux Containerのフルサポート、pNFSのクライアントサポート、実はSELinux enforcedでしかQAしてないので、permissive/disabledはテストしていませんというお話などが聞けました。
大きくはやはり管理系の仕組みがsystemd, OpenLMI, firewalld, NetworkManagerというものに置き換わるのが大きな変更点のようです。「カーネルランドは同じだけどユーザーランドは違うOSと言っても良いほどの変更」と言われていました。
講師は中井悦司さん
今回のお話のスライドはslideshareにアップロードされていて、時間の都合で省略されたところも含めて詳しく解説されています。ここで細かい話を書いても実際スライドのほうが詳しいので、私が疑問に思った点や補足を中心に記述します。
従来は SysV Init が /sbin/init に存在して最初にpid=1として起動していましたが、代わりに/usr/bin/systemdが起動します。今までは単なるシェルスクリプトが/etc/inittabに定義された順に実行されていたので、シリアルにしか実行できず性能も悪かったものが、systemdではそれぞれのタスクを細かくunitという単位に定義して依存関係と前後関係に基づいて並列的に実行し、起動速度を高速化します。
systemdを作ったのはレナートさんで、彼のblogにどうしてsystemdを作ったのかが載っているので、英語ですがぜひ読んでみてくださいとのこと。systemd の大きな目的は4つあって、
です。
SystemdではRequire/WantedByという依存関係と、Before/Afterという前後関係にもとづいてunitの実行順が決定されます。ここで依存関係というのは単に必要だということを記述するだけで、実際にはその中では平行にunitが実行されていきます。そのため、例えばhttpdが起動する前にDNSが起動しておいてほしい、というようなことはすべて前後関係として記述するようです。
init だとクラッシュした時の再起動がないので、よくアプリケーションサービスなどを supervisord や daemontools を使って別に起動させていた方も多いと思いますが、基本的には systemd がこれらも含めてすべて見るようにするのが理想的ということです。cgroupを使ってプロセスツリー全体のリソースも管理でき、ログ管理機能もあるのでsystemd管理下に置くほうがシステム全体として整合性も取れるような印象です。
また従来はdaemonizeすることが多かったところsystemdではdaemontoolsのようにforegroundで実行するのが基本的なスタイルになるようです。Typeを変えればforkするデーモンにも対応可能です。
systemctl status (unit名)すると、関連するプロセスの一覧やログの抜粋が表示される。
systemctl list-units すると、現在有効なunitの一覧が表示され、起動に失敗しているものもひと目でわかる。
systemctl list-dependencies (unit名) すると、依存関係がツリー状に表示される。
作者のレナートさんがドキュメント魔らしく、manページが大変充実しているので、困っても困らなくてもmanページを読めば良いとのことでした。
systemdという巨大な仕様のものを入れることにRed Hat社内でも議論があったそうですが、結局のところ SysV Init がイケてないし置き換えることは必要で、より良いデーモン管理のため導入することにしたそうです。話を聞くと使う分にはちゃんと動きそう、だけども何でもsystemdにやらせるのは「Unixぽくない」と感じます。
浸透のためにはDebianやGentooもsystemdに移る必要があると思うし、もし今後initが複数使われるのであればソフト作者はsystemd用、upstart用というふうにわけて起動スクリプトを用意しなければいけなくなるかもしれません。そういうのは望ましくないので、なんとか一本化してほしいなぁと思いました。
著者の中井悦司さんから「独習Linux専科」サーバ構築/運用/管理
初心者のかたで、これからLinuxを初めて使おうという方には非常におすすめできる本です。インストールの仕方から基本的なコマンドライン操作、システムの概念が解説されています。そして最後にはSamba, PostgreSQL, Ruby on Railsのサーバーを構築する手順まで書かれています。特にWindowsから入ると馴染みのないパッケージ管理(yum/rpm)やシェルの文法などには多くの紙面が割かれています。
最近はインターネットを検索すると多くの入門記事を見つけることができますが、それでもOSの入門書籍は役に立つと思います。ネットで検索するとディストリビューションが微妙に違ったり、バージョンが微妙に違ったりで「自分の環境に適用出来るか？」を考えなければなりませんが、この本は非常に網羅的に書かれていますので順序立てて学習することができます。
さらに、Fedora 17という比較的最近の2012年5月にリリースされたOSに準拠していることも特徴です。実はネット上の記事の多くはこのバージョンに追いつけていません。Fedoraは最近になって、プロセス管理がinitからsystemdに変更になりましたが、その新しい方法を説明しているのは非常に限られています。もし仕事でLinuxを使うならば、Red Hat Enterprise Linux や CentOS などを使う可能性がありますが、次のバージョン 7 では同じくsystemdが採用されるので、その予習にもなります。
Red Hat系Linuxを学習する最初の一冊としておすすめです。
少しLinuxを知っている人がこの本を読んだ場合は、知識の網羅性の確認になると思います。
前述のとおりsystemdの解説はネット上にもほとんどありません。Systemd入門(1) - Unitの概念を理解するというのが日本語で書かれた数少ない記事ですが、実はこの記事を書いた方がこの本の著者です。systemdの解説は7ページほどしかありませんので、あくまで他の記事と合わせて、になります。
他にもSELiunx, setuid/setgid/sticky ビット、find -mtime の -2, 2, +2 の違いなど中級者が「少し自信がないかも」というような内容もカバーされてます。意外とググりながら勉強していく方式だと、自分が直面した課題以外は見過ごされがちなので、そういう方にも使っていただけると思います。逆に今上げたキーワードはわかってるよ、というレベルの方には物足りないと思います。
また、50ページ程度がSamba, PostgreSQL, Railsのインストールと設定に割かれているので、OSのインストールは出来たけれどこのあたりをやったことがないよーという人にも役に立つと思います。
10月9日に秋葉原で開催されたMariaDB / MySQL コミュニティイベント in Tokyoに参加してきました。最近話題の MariaDB、いったいどんな感じだろう？という情報収集に出かけました。
SkySQLはMySQLとMariaDBのサポートを提供している会社。MariaDBの開発にもコミットしているが、MariaDBの運営自体は MariaDB Foundation によって行われている。これはまた買収されることを防ぐため。
ドメインは
となっている。
顧客満足度は高いと考えている。93%のサブスクリプション更新率を誇る。
MariaDBの誕生から44ヶ月で、もうすぐ10.0がリリースされる予定。特徴は
バージョン 10.0 は MySQL 5.5 ベース。これは Oracle MySQL 5.6 がリリースされた時に Oracle が過去のコミット履歴をリファクタリングして一部消してしまったため。機能は独自実装を含め、5.6 のスーパーセットを目指している。
私が個人的にいいなと思った機能は
あたりです。MySQL でも使えるのかは調べてないので、MySQLでもサポートしていたらご指摘ください...
クライアントライブラリはLGPL版が用意されている。ただしプロトコルは現在のところ互換性があるので、LGPLでなくても良いのであれば無理に移行する必要はないとのこと。
その他、MariaDB Galera Cluster や TokuDB のサポートという言葉が飛んでいて、このあたり知らないので今度調べてみようと思います。
サポートはリリース後5年間提供していて、これは各distributionがMariaDBに移行した理由の一つだと考えている。
MariaDB をモニタリング、設定、プロビジョンするためのツール群で、シェルスクリプトとPHP、Javaを組み合わせて実装されている。オープンソースで提供される。現在はまだ開発中。
GUIを使っても良いし、RESTful APIを使って既存のツールと組み合わせて利用することも可能。
興味深いと思ったのはスレーブの追加やバックアップもAPIからできるようになっていると言っていたところです。Xtra Backupと組み合わせて使ったりするのか、それとも似たような機能が独自で実装されるのか、そのあたり気になりました。
MySQL Proxy のような、クライアントとサーバーの間に挟むプロキシを開発中。C言語で、Event-basedで開発しているので高い性能を出せる。従来のプロキシより高機能なものを目指している様子。
開発はまだ初期段階で、10月22日にgithubで公開予定なので、フィードバックをくださいとのこと。
OracleがMySQLのプロプライエタリライセンスを持っている以上、すべてをGPLで提供するしかないのでどの程度ビジネスが上手くいってるのかなぁと気になって、「いいことばっかりのように思うけど、フリーランチは無いはずで、何を利用者に求めてるの？」と聞いてみました。そしたら「まずはOSSとして開発が進み、フィードバックやパッチがもらえること。もちろんサブスクリプションを買ってもらえるとうれしい」とのことでした。今日聞いただけの話ですが、開発自体はかなりオープンに進めているようで好印象でした。商用版を使っているかどうかで、Oracle MySQLとMariaDBを比較した時の印象は大きく変わるんじゃないかなぁと思います。
テストケースをつけてリリースしていることも強調していました。Oracle MySQL 5.6.14 にはテストケースがひとつも追加されずリリースされたことを引き合いに、オープンソースとしてはMariaDBのほうが参画しやすいのではないか、また、バグトラッカーも一本化していると言っていました。なるほど、普通のオープンソースの開発にかなり近いようです。また、Perconaとは密な協力関係でやっていると言っていました。
今のところRDBMSといえばMySQLという感じですが、PostgreSQLもかなり進化しているし、MariaDBも評価され始めているようなので、一度フラットにいろいろ調べてみるのが良いのかなぁ、と思いました。
「今MySQL 5.6を使ってるんですけど」という話をしたら「MariaDB 10.0が来春に出る予定なので、それまで評価を進めてもらって、その時に移行するかどうか検討するのが良いのではないか」とのことでした。
MaxScale や MariaDB Manager はまだ開発の初期段階で実用は難しそうですが、便利そうではあるのでこの先どういうふうに開発が進むのかなぁと興味を持ちました。
