コミケ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 はまだ開発の初期段階で実用は難しそうですが、便利そうではあるのでこの先どういうふうに開発が進むのかなぁと興味を持ちました。
ISUCON3に会社の方と3人でチームを作って参加しました。結果は... 予選敗退！ スコアは初期状態のGoで測ったものが最終スコアです...
今年初参加で、全く予習をしていなかったので勘所もなにもつかめず、まずWebアプリケーションがいくつか転がっていることを認識。言語は議論の末皆がやったことのある Perl に決定。 Perl の会社に務めているのに私だけ Perl がろくに書けません。
作戦は、まずコードを読んでボトルネックになっていそうなところを修正しようとして、コード分析から始めました。具体的には以下の様な点があがりました。
それで、作戦としては基本的にはコンテンツから静的ファイルを作成して nginx の rewrite でがんばろうという話になりました。
初期段階で「このアーキテクチャで行こう」となったものは次のような感じです。
いま考えると少し大掛かりすぎるわりには全体をカバーできていないアーキテクチャでした。
私の担当はworkerだったので、Queueからfetchして静的ファイルを生成するところを作成しだしました。 RabbitMQ との接続には Net::RabbitFoot を使いました。まずはトップページだけ... と思ってやって、ボチボチ出来かけたところで...
のようなところで悩み、うまく行かなくなって「ごめん、やっぱり無理...」と断念しました。
その後はいろんなページをmemcachedでキャッシュする方向に進みましたが、なかなか思うように成果が出ず時間切れで終了しました。
罠というのは、たとえば memcached が 11212 で上がっている問題がありますが、これは自分でmemcachedの設定を書き換えていて、「あれー、反映されない！」となっているのに気付かず、 stats とった時の値がおかしいのに気づかず... というので、自分の設定ミスばかり疑っていました。また、「DOMを変更しないこと」とあったので、スタイルシートの指定にトップページがあるのは気づいていましたが、変更できない... と諦めていました。
memcached 作戦はそこそこ動いて、testでスコア5000ぐらいまで行ったのですが「testは通るけどこの場合にうまくいかない」みたいなケースを見つけてしまいやり直して泥沼にハマってしまいました。多少FAILしても積極的にbenchmarkをとる作戦のほうがよかったと思います。
でも最大の失敗は、コードを中途半端に読んでボトルネックを「推測」するだけに終わり、最初からプロファイリングしたりシステムメトリックスを取得してチューニングに挑まなかったことだと思います。こんなですが会社ではチューニングもやってます...
次回があるとしたら、すぐにgangliaを入れれるようにしておいて基本的な数値は常に見ながらやるようにしようかなぁ、と思いました。あとNYTProfのようなツールの使い方をもっと覚えないといけませんね。
あと一人一インスタンスだったのでChefで構築しようとして途中で諦めてさらに時間をロスしていました。
くやしいです...
nginxでは変数をセットするときにsetディレクティブを使います。例えば
set $script ""; set $path_info $uri;
というようにです。ところで、このsetディレクティブはngx_http_rewrite_moduleに属します。 つまり、rewrite と組み合わせて
location /download/ {
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break;
set $script "";
set $path_info $uri;
fastcgi_pass unix:/tmp/fastcgi.sock;
}
なんていうことをしていると、rewriteが発動してbreakされた瞬間にrewriteモジュールの評価が終わってしまい、setされません。
location /download/ {
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3;
set $script "";
set $path_info $uri;
break;
fastcgi_pass unix:/tmp/fastcgi.sock;
}
というふうに、breakする場所をsetの後にする必要があります。
ハマりました。
iPhone 5s/5c が発表されましたね！
まだ各キャリアでどの周波数をサポートするという話がないので、iPhone のスペック表から突き合わせてみました。また、ドコモはどのモデルを発売するか公式情報がありませんが、おそらくA1533(GSM)だと仮定して話を進めますドコモもA1453でした。
各キャリアの周波数割り当てはWikipediaのLTE記事他を参考にしました。
| Band | Docomo | KDDI | Softbank |
|---|---|---|---|
| 1 (2100MHz) | 10MHz*2 | 20MHz*2 | 10MHz*2 |
| 3 (1800MHz) | 20MHz*2(東名阪) | 10MHz*2(emobile) | |
| 8 (900MHz) | 10MHz*2(2014年夏以降) | ||
| 18 (800MHz) | 10MHz*2 | ||
| 19 (800MHz) | 10MHz*2 |
Docomo, KDDI が保有する 1.5GHz帯には対応しません。
以上からまとめてみますと...
ドコモは東名阪バンドの1800MHz帯が使用可能なので、特に周波数の逼迫する首都圏で高速通信が可能と推測。 800MHz帯はサービス開始間もないのでエリアはまだ狭そう。
KDDIは田中社長ご自慢の800MHz帯に対応したので、エリアの問題はおそらくクリアし、3キャリアで一番広くなりそう。ただし800MHz帯+1500MHz帯+2100MHz帯全体のエリアは公表しているけれど、800MHz帯+2100MHz帯のみのエリアは公表されていない。2100MHz帯の20MHzはまだ数局という感じなので、実質15MHzでのサービス。2100MHz帯での品質は皆様ご存知の通り。 VoLTE はまだ使えないので通話中のデータ通信はできないまま。
ソフトバンクは相変わらず厳しい。イーモバイルの1800MHz帯が今後も使えるとしても相変わらず逼迫したまま。特にプラチナバンドと呼ばれる900MHz帯でのサービスが来年夏以降なのが厳しい。2100MHz帯のみの比較ではKDDIよりも良いようですが、800MHz帯が加わった時にどうなるかは未知数。
現在KDDIでiPhone 5を使っているユーザーは、iPhone 5sに乗り換えると使える周波数が増えます。現在ソフトバンクでiPhone 5を使っているユーザーは、iPhone 5sに乗り換えても使える周波数は今のところ変わりません。
カタログスペックのみの比較なので、実際の通信速度や品質にはもちろんキャリアの基地局整備状況によります。ドコモは特にiPhone初めてなので、そこらへんも含めて注目です。
UUID:トランザクション番号例えば"40bbcf9b-e556-45b0-bdb3-e528f0041652"で実行された123番目のトランザクションは
40bbcf9b-e556-45b0-bdb3-e528f0041652:123という感じになります。
40bbcf9b-e556-45b0-bdb3-e528f0041652:1-20:22-1021という感じで、 : でつなげて記録されます。
SET @@SESSION.GTID_NEXT= 'a8679745-1864-11e3-a1ec-28924a2bea1c:14'という行が現れます。これは、次に実行するトランザクションのIDを指定しています。
# at 2621 #130908 21:05:04 server id 10 end_log_pos 2669 CRC32 0x20b2bc89 GTID [commit=yes] SET @@SESSION.GTID_NEXT= 'a8679745-1864-11e3-a1ec-28924a2bea1c:14'/*!*/; # at 2669 #130908 21:05:04 server id 10 end_log_pos 2737 CRC32 0x5e5fa3bb Query thread_id=10 exec_time=0 error_code=0 SET TIMESTAMP=1378641904/*!*/; BEGIN /*!*/; # at 2737 #130908 21:05:04 server id 10 end_log_pos 2785 CRC32 0x757ca2c9 Table_map: `yuryu`.`test` mapped to number 70 # at 2785 #130908 21:05:04 server id 10 end_log_pos 2829 CRC32 0x4e043fe7 Write_rows: table id 70 flags: STMT_END_F BINLOG ' 8GcsUhMKAAAAMAAAAOEKAAAAAEYAAAAAAAEABXl1cnl1AAR0ZXN0AAEIAADJonx1 8GcsUh4KAAAALAAAAA0LAAAAAEYAAAAAAAEAAgAB//4RAAAAAAAAAOc/BE4= '/*!*/; # at 2829 #130908 21:05:04 server id 10 end_log_pos 2860 CRC32 0x3fbac367 Xid = 226 COMMIT/*!*/;つまり、バイナリログがスレーブに転送されて実行されるのは
/etc/sysconfig/memcached-server1
/etc/sysconfig/memcached-server2
.
.
.
/etc/sysconfig/memcached-serverN
というふうに必要なだけサーバーを並べます。 server1 の部分は好きな名前が使えます。
service memcached startとすると、すべてのサーバーを起動します。
service memcached start server3とすると、指定したサーバーのみ起動します。 stop も同様です。 それぞれのファイルの中身は
PORT="11212" USER="memcached" MAXCONN="1024" CACHESIZE="64" OPTIONS=""という感じで指定します。
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Found a Gtid_log_event or Previous_gtids_log_event when @@GLOBAL.GTID_MODE = OFF.; the first event 'mysql-bin.000013' at 404, the last event read from './mysql-bin.000013' at 452, the last byte read from './mysql-bin.000013' at 452.' Last_SQL_Errno: 1778 Last_SQL_Error: Error 'Cannot execute statements with implicit commit inside a transaction when @@SESSION.GTID_NEXT != AUTOMATIC or @@SESSION.GTID_NEXT_LIST != NULL.' on query. Default database: ''. Query: 'FLUSH ERROR LOGS'
tar xzvf archive.tar.gz
tar xjvf archive.tar.bz2
tar xJvf archive.tar.xz
tar xvf archive.tar.gz
tar xvf archive.tar.bz2
tar xvf archive.tar.xz
tar xf archive.tar.gz
tar xf archive.tar.bz2
tar xf archive.tar.xz
Reading compressed archive is even simpler: you don't need to specify any additional options as GNU tar recognizes its format automatically.圧縮されたアーカイブを読むのはより簡単です。GNU tar が自動的に形式を認識するので、追加のオプションを指定する必要はありません。
-z, --gunzip, --gzip-z
(c mode only) Compress the resulting archive with gzip(1). In extract or list modes, this option is ignored. Note that, unlike other tar implementations, this implementation recognizes gzip compression automatically when reading archives.
cat original | command > original.compressed
| Software | time real | time user | compression ratio | compression ratio (single/parallel) | parallel overhead |
|---|---|---|---|---|---|
| lzo | 0.22 | 0.19 | 1.55 | ||
| lzo -9 | 4.91 | 4.93 | 1.25 | ||
| gzip -1 | 0.50 | 0.49 | 1.15 | ||
| gzip | 1.00 | 1.00 | 1.00 | ||
| bzip2 -1 | 4.41 | 4.46 | 0.86 | ||
| bzip2 | 5.87 | 5.94 | 0.79 | ||
| xz -1 | 1.96 | 1.98 | 0.94 | ||
| xz | 17.86 | 18.14 | 0.72 | ||
| pigz -1 | 0.10 | 0.77 | 1.15 | 1.00 | 1.56 |
| pigz | 0.20 | 1.55 | 1.00 | 1.00 | 1.55 |
| pbzip2 -1 | 0.95 | 7.60 | 0.86 | 1.00 | 1.70 |
| pbzip2 | 1.57 | 12.53 | 0.79 | 1.00 | 2.11 |
| pxz -1 | 0.46 | 3.61 | 0.96 | 1.03 | 1.83 |
| pxz | 4.11 | 28.35 | 0.73 | 1.01 | 1.56 |
10.234.130.1 host1301 10.234.130.2 host1302 10.234.130.3 host1303
| #hosts | hosts | dnsmasq |
|---|---|---|
| 2 | 1.516 | 4.8068 |
| 102 | 2.6598 | 4.9224 |
| 252 | 4.4474 | 4.9286 |
| 1002 | 13.2376 | 4.831 |
$ ./a.out 100000 host127183 Resolved 100000 times. Elapsed time = 0.740 seconds, 0.007 us per host.
3月14日に、SimCity をプレイしようとすると「アカウントのシムシティが有効になっていません。 Origin でシムシティを有効にしてください。」というメッセージが現れました。終了するをクリックするとゲームが終了し、全くプレイ出来ません。EA から返答がないので、再びフォームから問い合わせました。初SSD記念でベンチマーク取りました。
両方ともシステム入れて使ってたり、いろんなデータすでに置いている状態なので、理想状態よりは遅くなっているであろうことを申し添えておきます。
SSD: Plextor PX-256M5P
-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 Shizuku Edition x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 513.421 MB/s
Sequential Write : 446.646 MB/s
Random Read 512KB : 381.395 MB/s
Random Write 512KB : 427.883 MB/s
Random Read 4KB (QD=1) : 28.854 MB/s [ 7044.4 IOPS]
Random Write 4KB (QD=1) : 50.956 MB/s [ 12440.3 IOPS]
Random Read 4KB (QD=32) : 388.745 MB/s [ 94908.5 IOPS]
Random Write 4KB (QD=32) : 348.163 MB/s [ 85000.8 IOPS]
Test : 1000 MB [C: 24.1% (57.3/238.0 GB)] (x5)
Date : 2013/01/04 0:36:10
OS : Windows 8 [6.2 Build 9200] (x64)
HDD: 東芝 DT01ACA300BOX(3TB, 7200rpm)
-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 Shizuku Edition x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 174.792 MB/s
Sequential Write : 174.704 MB/s
Random Read 512KB : 48.242 MB/s
Random Write 512KB : 71.147 MB/s
Random Read 4KB (QD=1) : 0.554 MB/s [ 135.2 IOPS]
Random Write 4KB (QD=1) : 0.620 MB/s [ 151.4 IOPS]
Random Read 4KB (QD=32) : 1.516 MB/s [ 370.2 IOPS]
Random Write 4KB (QD=32) : 0.641 MB/s [ 156.5 IOPS]
Test : 1000 MB [D: 25.3% (707.1/2794.4 GB)] (x5)
Date : 2013/01/04 0:42:54
OS : Windows 8 [6.2 Build 9200] (x64)
文字通り桁が違います。システムドライブはもう SSD 以外考えられません。
コミケ83で Linux Kernel Updates を出します！(31日東X-58b)の事後報告です。
予想外に好評をいただき、50部持っていったのですが11時半ごろに完売してしまいました。「どうせ余るだろうから、ゆっくりいらしてください」と事前にアナウンスしていたので、午後にいらっしゃった方々、申し訳ありませんでした。
いただいたご意見の中に「Linux の変更点を最近追いかけているサイトがないので、まとめてもらえるなら実は需要あるんじゃない」というものがありました。実は KernelNewbies.org がすごくよくまとまっているので、そこを見ながら、自分が気になった新機能についてはまとめていく、なんてことが出来ればいいなぁと思います。
夏コミにも応募します。もし受かれば内容は若干古くなってしまいますが、同じ物を再販して持っていきます。そして、新しい本も出します。今度は調子に乗ってもう少し多めに持っていくつもりです。中身はまだ決定はしていませんが、Linux Virtual Server の中身と、スケジューラーの SMP 対応コードの解説なんかを考えてます。
なお、冬コミ本の中身のうち What's New in Linux 3.7? については、旬を過ぎるとおもしろくないのでBlogに掲載しました。買ってくださった方には少し恐縮ですが、もともとが Web に載っている情報なのでご容赦いただければと思います。
コミケ83でLinux Kernel Updatesという同人誌を出したのですが、予想外の好評をいただき11時半ごろに完売となってしまいました。
次の夏コミに受かれば再販する予定ですが、Kernel 3.7 のニュースは古くなってしまうので、こちらに掲載します。
Linux 3.7 に含まれる主な変更点を kernelnewbies.org の記事から翻訳しました。
x86 では一つのカーネルイメージが複数の PC 上で動作しますが、ARM は基本的にボードやプラットフォームごとにカスタムのカーネルを作成します。いわゆる組み込み文化です。ところがそのままだと Debian のような distributor が ARM 用の distribution を配布するのが大変なので、複数のプラットフォーム上で動作するカーネルイメージを作成可能にしました。 ただし、単に起動するだけといったレベルですので、実用的な使用には現時点ではボードごとの定義が必要です。
ARMv8 では 64bit コードの実行がサポートされましたので、Linux でも 64bit 版 ARM コードの生成をサポートしました。 x86 と異なり、 64bit ARM は 32bit ARM と全く互換性がないので、別のソースツリーで管理されることになりました。
fsync() の改善: fsync() はデータをディスクにフラッシュするシステムコールです。btrfs はこれまで fsync() が遅かったのでいくつかのアプリケーションでのボトルネックになっていましたが、これが改善されました。 SATA の遅いドライブでも2割～5割、Fusion IO や RAMディスクなどの高速なドライブでは最大7倍程度の性能改善になります。
ディレクトリあたりのハードリンク数上限の解除: Btrfs は従来ディレクトリ内にはハードリンクを20しか許しませんでしたが、今回のバージョンから6万5000個のハードリンクを作成できるようになりました。また、これに伴いディスク上の構造に拡張が加えられました(古いバージョンのカーネルとは互換性がありません)。
Hole punching: ファイルのある一定の領域を未割り当てな状態とする、FALLOC_FL_PUNCH_HOLE オプションをサポートしました。蛇足ですがこのパッチは fusion-io の方からポストされています。やはり SSD にとっては TRIM されているかどうかは重要な様子です。
chattr による ファイルごとの NOCOW 属性のサポート: btrfs ではデフォルトでは COW(copy-on-write) を使用しますが、従来は nodatacow マウントオプションにより COW を無効にすることができました。COW は負荷によっては性能が悪化します。この変更では、ファイル単位で COW を無効にすることができます。ただし、すでに内容があるファイルの属性を変更することはできず、空のファイルにのみ適用できます。すでに中身があるファイルを変更したい場合は、一度テンポラリファイルを作成して属性を変更し、中身をコピーする必要があります。また、COW を無効にすると、チェックサムも無効になります。
strace の代替として、新しい "perf trace" が perf profiling infrastructure に追加されました。従来 strace は ptrace() を使っていましたが、perf trace は Linux profiling infrastrcture を使用します。
まだ開発の初期バージョンでシステムコールのみ表示できますが、今後ページフォールト、task のライフタイムイベント、スケジューリングイベントなどをサポートする予定です。また、現在は live で表示することしか出来ませんが、 perf.data のようなファイルを出力して事後の解析ができるようになる予定です。
3.6 ではクライアント側での TCP Fast Open のみサポートされていましたが、3.7 でサーバー側のサポートも追加され、 Linux の TCP Fast Open サポートが完了しました。
CIFS ネットワークファイルシステムが SMB プロトコル version 2 をサポートしました。 SMB2 はよく使われている CIFS と SMB によるファイル共有の後継で、2006 に Windows Vista により導入されました。 SMBv2 は前のバージョンに比べて高い性能、セキュリティと多くの機能が提供されます。 ちなみに Samba 4.0 では SMB 2.1 がサポートされ、また Windows 8 からサポートされる SMB 3.0 のサーバー実装も進んでいます。需要がどれほどあるのか、少し不安なところもありますが、新しいプロトコルのサポートに期待です。
NFS v4.1 (RFC5661) は長い時間をかけてサポートされてきましたが、今回はじめて「実験的(experimental)」ラベルが取れました。
NFC v4.1 の主な機能は pNFS (parallel NFS) です。pNFS を用いると、ファイルシステムやファイルを複数のサーバーに分散して配置し、並列にアクセスすることが可能になります。
vxlan という、L2 ethernet over UDP のトンネリングプロトコルが Linux に追加されました。 vxlan はしばしば仮想化環境で仮想ネットワークをトンネリングするために使われます。
VXLAN プロトコルそのものは RFC ドラフトで、VLAN の数が 4096 に制限されていることを解決するためのトンネリングプロトコルです。 vxlan では識別子が 24bit に拡張されます。また、使用するUDPポートは一つです。他のほとんどのトンネリングプロトコルとは異なり、VXLAN は 1:1 だけではなく 1:n の接続もサポートしています。VXLAN デバイスは接続先のIPを自動識別してブリッジを自動構成することも可能ですし、または静的に転送設定を記述することもできます。 Open vSwitch のための VXLAN 実装もあります。
Intel SMAP (Supervisor Mode Access Prevention) は、将来の Intel プロセッサに導入されるセキュリティ拡張です。SMAP が有効になると、カーネルがユーザー空間のメモリにアクセスすることが禁止されます。いくつかの exploit の防止に役立ちます。
truncate / unlink が高速化されました。 あるベンチマークにおいて、60GB のファイルを rm する場合、従来 2.7秒かかっていたものが 0.6秒強まで短縮されています。
ディレクトリエントリのサイズを一定に制限することができるようになりました。
まとめると、今回の目玉は ARM アーキテクチャの改善ですが、btrfs や ext4 のパフォーマンス改善など、実際に役に立つ変更も多数含まれています。また、 TCP Fast Open のサーバーサイドサポートも含まれましたので、Web アプリケーションの高速化には 3.7 以降が必須になってくるでしょう。
Part of the above article is translated from http://kernelnewbies.org/Linux_3.7, CC-BY Linux Kernel Newbies