株式会社インフィニットループ PHPとスマホアプリ開発を行う札幌のシステム会社

技術ブログ

  1. トップ>
  2. 技術ブログ>
  3. Linuxの記事一覧

2015年06月23日 (火)

著者 : 

boot2docker を使って Windows で docker を体験する

docker というと Linux の世界の出来事のようなイメージがありますが、Windows でも boot2docker というソフトをインストールする事で docker の世界を体験することが出来ます。そんな docker の面白い世界の入り口を紹介して行きたいと思います。

インストール編

  1. VirutalBox インストール
    64ビットの VirutalBox を Windows にインストールします。VT-x が使えるプロセッサで 64 ビット Windows のマシンが必要です。 今となっては敷居高くないと思いますが、持ってない人はごめんなさい。ノートPCで Windoes 8 64bit を使っているのに VirtualBox で仮想サーバー作ったら 32 bit のサーバーしか作れない!という方は BIOS 設定の方をご確認してみてください。エントリーレベルのノートPCですと、たまに AMD の SVM (AMD-V) や Intel の VT-x が BIOS で OFF になっているケースがあります。
  2. Git for Windows https://msysgit.github.io/ のインストール
    cygwin をインストールし既に Windows を Linux 風サーバーとして使っている方もそのまま msysgit を追加でインストール可能です。ここまでの2つはboot2dockerに必要なソフトですが、単独でそれぞれの用途に使えるものですので、事前にインストールして簡単な操作には慣れておくことが望ましいです。
  3. boot2docker http://boot2docker.io/ インストール
    サイトからダウンロードしてインストールし、最初に boot2dockerのアイコンをクリックします。すると VirtualBox のゲストである docker ホストマシンに ssh で入ることになります。この画面が出れば完了です。
                            ##        .
                  ## ## ##       ==
               ## ## ## ##      ===
           /""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
           \______ o          __/
             \    \        __/
              \____\______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.5.0, build master : a66bce5 - Tue Feb 10 23:31:27 UTC 2015
Docker version 1.5.0, build a8a31ef
docker@boot2docker:~$

(続きを読む…)

2015年05月14日 (木)

著者 : 

Ubuntu 15.04とLXDではじめるコンテナ型仮想化

こんにちは、mizuno_asです。
2015年4月23日、UbuntuチームはUbuntu 15.04 Vivid Vervetをリリースしました。このリリースから、UniverseリポジトリにコンテナハイパーバイザーであるLinux Container Daemon(LXD)が含まれるようになりました。それではさっそくUbuntu 15.04とLXD 0.7を使って、お手軽なコンテナ環境の構築を試してみましょう。


Photo by Philippe PutCC BY 2.0

(続きを読む…)

2013年08月20日 (火)

著者 : 

これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編)

こんにちは nob です。
前編 これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編) の記事から1年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を(システム編)としてお届けいたします!

今回の(システム編)で紹介するツボは 4 つです。(クエリ編)のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。

  • (ツボ1)Load Average < (1 + (cpu数-1)/3) 
  • (ツボ2)Checkpoint Age が水平線になったら要注意
  • (ツボ3)MyISAM は無いよね監視
  • (ツボ4)万能選手スローログ

なお前編と同様この記事では監視ツールとして CactiPercona MySQL Monitoring Template for Cacti (前編で紹介した better-cacti-templates の後継プロジェクト)を前提にしていますが、Munin やコマンドラインの mysql など、他のツールでも見るべき点は同じですので応用してください。

(ツボ1)Load Average < (1 + (cpu数-1)/3) 

右側の式は後ほど説明するとして、Load Average 監視って当たり前?ですよね。でも実際には Load Average にもいろいろなケースがあります。

  • Disk I/O が増えた場合に Linux カーネルのフラッシュのプロセスが CPU を使ったり、あるいはコンテキストスイッチでLA増加
  • アクセスしているテーブルのデータが殆どバッファープールに乗っている場合には相対的に I/O 負荷が低くなるため、クエリが増えた場合にその分ロック機構で使われるスピンロックなどの排他制御やソート処理で LA 増加
  • インデックスが使われず広範囲に読み込みスキャンするようなクエリを誤ってリリースしたような場合にも LA増加
  • クラウドのインスタンスがホスト側の障害で不良だった場合にも、アクセス数は変わって無いのに LA増加

などがあります。このように CPU, Disk I/O, クエリ負荷、クラウドの不良インスタンスまで、あらゆる状況を総合的に把握出来るのがやっぱり CPU のビジーで、その代表的なグラフが  Load Average です。

load_average_example

このグラフはあるシステムの2日間の Load Average のグラフです。左のグラフの 13:00 付近から Load Average が急上昇しました。これは新しく使われ初めたある機能により、実行回数も多いクエリのジョインやソートの行数が急に増加したため Load Average が上昇したものです。探索行数が多いと I/O が増加するイメージがありますが、実際には OS のキャッシュや MySQL のバッファプールに乗るため I/O は増えずに CPU だけ負荷が増える事があります。この場合も Load Average の上昇で兆候を発見し、まだ問題ない程度のうちに原因クエリを特定し改善することで、夜のピーク時間帯には通常ピーク値(青線)に戻す事が出来ました。

このように監視項目として有効な Load Average ですが、さてしきい値はいくつにしたらよいでしょうか? Linux カーネルのマルチコアでは

  • キャッシュのヒット率やメモリ一貫性維持のオーバーヘッドを考慮し、プロセッサのコアはある程度偏らせて使う
  • プロセス起動時は空いているコアを選択するが、MySQL はプロセス起動はあまり発生しないのでこの分散の恩恵は受けない
  • かなり負荷が高くなるとプロセスを動かしたままコアを移動するマイグレーションがおきるが、滅多に発生しない

という CPU を偏って使う特徴があるので、ググってよく出てくる 「Load Average < CPU数」は適正値にはなりません。とは言えしきい値も必要です。そこで、完全な経験則だけで理論の裏付けはありませんが、MySQL のインスタンスの Load Average のしきい値を出しました。

  • MySQL では Load Average  <  (1 + (cpu数 -1) /3)

です!よくある8コアのマシンですと、LA < 3.3 までが適正値です。ハイ言っちゃいました!

(ツボ2)Checkpoint Age が水平線になったら要注意

Redis や MySQL Cluster など多くのデータ永続化インメモリDBはデータはメモリ上で、HDDのシーケンシャル書き込みは速いのでログはディスク上で、という構造になっています。InnoDB もデータをメモリ上だけに持てるサイズがあり、このサイズまではインメモリDBと同じようにログだけディスクに書いた状態で動作します。このメモリ上に持ったままでよいサイズというのが  innodb_log_file_size です。そしてまだディスクにフラッシュされていないデータのサイズが Checkpoint Age になります。漢のコンピュータ道 でも128M程度までというアドバイスがありますが、一方で、ログファイルサイズを大きくすることで、高い性能を引き出そうというチューニング手法もあります。

Checkpoing Age が成長すると緩やかにディスクへのランダム書き込み(チェックポイント)が始まります。チェックポイントと、シーケンシャルなログ書き込みの量のバランスが取れていれば、 Checkpoint Age もバランスが取れ、上がったり下がったりしつつアクセス量と同じようなグラフの形になります。

checkpoing_age_low

使用ディスクが RAID などでシーケンシャル書き込みがランダム書き込みに比べてかなり速い場合は、ログの書き込みの方が多くなりCheckpoing Age が成長します。そして一定の割合(バージョンによる。90%等)を超えると今度は強いチェックポイントが始まります。この強いランダム書き込みとログのシーケンシャル書き込みでバランスが採れていれば、Checkpoing Age は高止まりした波グラフ(下のグラフの青い部分)になります。全力でディスクを使っている状態です。

checkpoint_age_middle

ここからさらにログ書き込み量が上回りCheckpoint Age が上限に達すると、全てのトランザクションを停止してチェックポイントを行うようになります。そして Checkpoint Age が下がりトランザクションが再開されますが、更新が多いのでまたすぐ上限に達します。この動作を繰り返し続けるので Checkpoint Age は下のグラフの様に上限値でほぼ水平線になります。このグラフの形でも全トランザクション停止時間が1秒未満など微視的であれば、上の例と同じく全力運転状態と言えます。

checkpoint_age_high

一方、高速動作を狙って innodb_log_file_size を〜GBというようにバッファプール並みに大きくしてると、全トランザクションをブロックして書き込む量も多くなりますので、停止時間が数分間にも達し大きな問題となる事があります。こうしたトランザクション停止時間は Checkpoint Age のグラフでは読み取ることが難しいですから、Checkpoing Age が水平線になったらトランザクション全停止が発生していないかアプリのログなどで確認するようにしましょう。

ドリコムさんで体験された「ちゅどる」もこの現象になります。(ソーシャルゲーム スケールアウトの歴史 p81 参照)またPercona の Adaptive Checkpointing  はこの「ちゅどる」にならないようにチェックポイントの強さを自動的に調節する機構です。

(ツボ3)MyISAM は無いよね監視

現在は MySQL = InnoDB といっても過言ではないと思います。MyISAM のテーブルは作成していません。それなのに突然 MyISAM Indexes のグラフが急上昇することがあります。大抵はシステムも高負荷になっています。

myisam_indexes

これはジョインやソートのために MySQL 内部に作成されるテンポラリテーブルが、メモリ上には乗り切らず MyISAM テーブルとして作成され使用されている為発生します。MyISAM Indexes のグラフを監視して、発見したら

  • max_heap_table_size  と tmp_table_size をさらに大きな値に変更してメモリから溢れない様にする
  • クエリを見直してテンポラリテーブルの使用量を下げる

などの対応が必要です。

(ツボ4)万能選手スローログ

MySQL パフォーマンスチューニングや監視で、もっとも有効なのがスローログです。理由は単純明快で、あらゆるDBの問題は「遅い」という症状につながるからです。そんな万能選手のスローログですが、完全無欠ではなく注意すべき点が2点あります。

  1. 完了したクエリだけが記録される。デッドロックなどロールバックされたクエリは完了していないため記録されません。記録されているスローログは被害を受け遅延したクエリで、原因となった加害者のクエリが最終的にはロールバックされ記録されていないというケースもあります。あくまでも完了したクエリなんだという前提で読みましょう。
  2. クエリが原因だと先入観を持たない。あるクエリの実行時間が想定以上に長い場合、ついそのクエリの書き方に注意が向きがちですが、先入観を持たずに調査しましょう。例をあげますと、 SELECT MASTER_POS_WAIT(logname, position, 2) という、本来2秒で応答すべきスレーブのマスター追いつき確認関数 MASTER_POS_WAIT の実行に何十秒もかかっていて、 実はインスタンス自体がハングアップしていたのが原因でクエリも MySQL も原因では無かった、というケースなどがあります。

最後に

MySQL パフォーマンス監視のツボ(システム編)としてサーバー運用管理での経験を共有させて頂きました。是非ご活用ください!

2012年10月18日 (木)

著者 : 

980円のUSB温度計を使ってLinuxから室温を計測する

社内見える化委員会のmatsuiです。

最近は少しマシになりましたが、部屋が暑いということで、適切な温度計測を行うため、Linuxマシンから温度測定をできる仕掛けを作ってみました。

使ったUSB温度計はこちら。Amazonで980円です。

Amazon USB温度計! USB thermometer
 
 

セットアップ

付属のCDには、Windows用のドライバしか入っていませんので、とりあえず捨てましょう。

セットアップにはこちらのページを参考にさせていただきました。
→ matoken’s wiki. Linux/Device/サンコーレアモノショップ_USB温度計_AKIBA58

環境はUbuntu12.04LTSで試しましたが、ここに書いてあることそのままで大丈夫です。
ありがたいです。
 
 
USBを指すと普通に認識します。

$ dmesg | grep TEMP
[    1.795200] input: RDing TEMPer1V1.2 as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input4
[    1.804362] generic-usb 0003:0C45:7401.0001: input,hidraw0: USB HID v1.10 Keyboard [RDing TEMPer1V1.2] on usb-0000:00:1d.0-2/input0
[    1.822847] generic-usb 0003:0C45:7401.0002: hiddev0,hidraw1: USB HID v1.10 Device [RDing TEMPer1V1.2] on usb-0000:00:1d.0-2/input1

 
 
必要なパッケージをインストールします。

$ sudo apt-get install build-essential libusb-0.1-4 libusb-dev git

 
 
温度測定コマンドのソースコードはgithubで公開されているようです。
→ github bitplane / temper

githubからチェックアウトします。

$ git clone https://github.com/bitplane/temper.git

 
 
日本人向けにソースコードを修正します。
上の参考ページそのままです。

$ vi temper.c

44行目の utc = gmtime(&t); を utc = localtime(&t); に
47行目の strftime(dt, 80, “%d-%b-%Y %H:%M”, utc); を strftime(dt, 80, “%Y-%m-%d %H:%M:%S”, utc); に
 
 
diffで書くとこんな感じ

$ diff temper.c.org temper.c
44c44
< utc = gmtime(&t);
---
> utc = localtime(&t);
47c47
< strftime(dt, 80, "%d-%b-%Y %H:%M", utc);
---
> strftime(dt, 80, "%Y-%m-%d %H:%M:%S", utc);

 
 
makeして出来たバイナリを/usr/local/binあたりに設置します。
今回は一般ユーザからも利用したかったので「chmod u+s」しています。

$ make
$ sudo mv temper /usr/local/bin/
$ sudo chmod u+s /usr/local/bin/temper

 
 

使ってみる

実行するとこんな感じです。日付と温度がカンマ区切りで出力されます。

$ temper
2012-10-15 22:01:48,27.825012

 
 
あとはこれを適当なアプリケーションから利用してやればOKです。
弊社ではマザーゆっくりという自作SkypeBotに、温度をしゃべらせる機能をつけて使っています。


 
 
また温度のグラフをcactiに出しています。

<?php
exec("/usr/local/bin/temper", $output);
list($dummy, $temper) = explode(',', $output[0]);
echo round($temper, 1);

こんなスクリプトで取得して、cactiでグラフにしています。


 
 
安いお値段で楽しめますので、興味のある方は試してみてはいかがでしょうか。
 

お古のノートPCをサーバにしています。

2012年03月08日 (木)

著者 : 

これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編)

こんにちは、インフラ担当新人の nob です。

サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか?その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。

これだけ見れば大丈夫! クエリ編 3つのつぼと5つのグラフ

  • (その1)監視ツールが何を見ているのか知る
  • (その2)監視のキモ、グラフ3点セット (Questions, Lock Waits と Transaction Handler)
  • (その3)グラフでチェックする SQL チューニング ( Select Type と Handler)

シンプルでお勧め、サーバー監視グラフ化ツール Cacti

運用しているサーバーには、単純なネットワークの死活監視から始まってシステム全体の性能を監視するまで、様々なサーバー監視のインフラが必要となります。有名どころでは Nagios, Zabbix, Hinemos などがありますが、今回使っているのは Cacti http://www.cacti.net/ というサーバーパフォーマンスグラフ化ツールです。監視項目のグラフ表示の他、しきい値を超えるとメール通知する基本機能も備えています。またテンプレートを自作し好みの項目をグラフにすることも出来ますし、自作テンプレートはネットからも入手出来ます。機能がシンプルですので、インフラ・エンジニアの別の仕事(運用の自動化とか)に浮気することなく、MySQL のパフォーマンスに集中出来るのもよい所です。

私が MySQL のための Cacti テンプレートとして使ったのは better-cacti-templates です。導入については ググれカス http://ggrks.org/の記事 cactiの導入とApacheとかMySQLとかのtemplateの導入 などを参考にしてください。

(その1)監視ツールが何を見ているのか知る

グラフのデータを活用するには、データの意味、つまりデータをどうやって採集しているのか 知る事が重要です。better-cacti-templates が採集している MySQL データは、SHOW STATUS コマンドで表示される MySQL の統計情報の項目と、SHOW ENGINE INNODB STATUS コマンドで表示される文章を元にしたオリジナルな項目、の2本だてで構成されています。Cacti のグラフの意味を知るのは

  1. SHOW STATUS の項目に同じ名前の項目があるか、あれば MySQL リファレンスマニュアルで意味を調べる
  2. SHOW STATUS に無い場合は、それはテンプレートの独自項目なので、テンプレートのスクリプトを解読する

という手順になります。better-cacti-templates の場合はテンプレートのソースの scripts/ss_get_mysql_stats.php を見ると独自項目の内容の詳細がわかります。今回の記事で取り上げなかった Cacti のデータ項目が気になった方は、ぜひソースの解読に挑戦してみて下さい。

(その2)監視のキモ、グラフ3点セット (Questions, Lock Waits と Transaction Handler)

まず最初はパフォーマンス監視のキモであるグラフの3点セットです。チューニングというより監視が目的の場合の重要なグラフがこの3つです。まずは Questions から見ていきます。

SQL の種類のグラフ MySQL Command Counters

このグラフはどういう種類の SQL 文が実行されたかまとめたものです。単位はインターバル(デフォルト5分)毎の回数ですが  m はミリ、つまり1/1000 回です。例えば 100 m  というのはその5分間で発生した回数が 0.1 回ということで、50分で1回発生した、という事を示しています。

Com は Command の略で Com Select / Delete / Insert / Update / Replace はその名前のとおりの SQL の実行回数です。 Com xxx Multi と付いているのは複数テーブルを一括して Update するMySQL 独特の構文です。ここで注目すべきは Questions です。MySQLリファレンスマニュアルには簡素に「MySQL への問い合わせ回数」と記述されています。なんでもカウントしますが、ここだけに計上されるのは SET などの補助的なコマンドと、エラー応答です。SET が急に増えることはありませんので、上のグラフの点線部のように増加した場合は、何かエラーが増加しています。

エラー内容の調査にはアプリケーション側での調査が必要ですが、 とりあえず Questions だけが増加して来たら、何かの悪い兆候と思ってください。

ロック待ち時間を見るのに最適 InnoDB Current Lock Waits

監視3点セットの2点目はこのグラフです。データの項目は Innodb Lock Wait Secs ですが、この値は SHOW ENGINE INNODB STATUS で表示されるトランザクション情報のうち、”TRX HAS BEEN WAITING n SEC FOR THIS LOCK TO BE GRANTED” の n をシステムのトランザクション全部で合計したものです。ここでいうロックは行ロックやテーブルロックの区別はありませんが、パフォーマンスからみればロック待ちの時間はゼロが良く、この値が増加しているのも悪い兆候です。

上のグラフでは、ちょうど Questions と同じ時間帯で Lock Waits も上昇しています。表示中の  k はキロ、1000 です。2つ合わせるとエラーが増加してロックの待ち時間も増えている、となります。MySQL だと真っ先に疑われるのはデッドロックですが、この例では INNODB STATUS を見ても記録されていませんでした。さてどうしたものか?そこで生きてくるのが次の3点目のグラフです。

トランザクション状況を一瞥する MySQL Transaction Handler

このグラフは項目の名前どおりにコミット数とロールバック数をグラフにしたものです。グラフ点線部にそれまで無かったロールバックが記録されていたことがわかります。

デッドロックではなくても何かのエラーでトランザクションが アボートされるとロールバックが発生します。「元のクエリのロック時間」+「更新を巻き戻す時間」+「再実行時間」、、、、という具合に無駄に処理が増え、ロックの競合確率やロック待ちも増加し、レスポンスが悪くなります。

というように以上3点のグラフを見ればクエリで異常が発生していないかどうか監視できます。

(その3)グラフでチェックする SQL チューニング ( Select Type と Handler)

MySQL ではスローログを活用してプロファイリングするのが有効です。ところがデータ量が少ないシステム開発中にはクエリは高速に動いてしまい、スローログには記録されません。そこでさらに log_queries_not_using_indexes をセットして、インデックスを使っていないクエリ、インデックスを使っていても全件検索しているクエリを全て記録し、そこをチューニングします。ところが、小さいテーブルを SELECT * FROM Table しているものとか、全件コピーするために INSERT INTO .. SELECT … をやっているものとか、わかってて全件検索しているクエリも記録されるので件数がかなり多く負荷になります。そのため log_queries_not_using_indexes は本番稼働時には外されることも多いです。

さて、開発も最終段階でスローログの設定も本番と同じにしたとします。データが少ない今はスローログには何もひっかかりませんが、もしインデックス張り忘れなどのチューニング忘れのクエリが残っていれば、データの増加後に速度が低下して初めて気がつくことになります。クエリ全部に EXPLAIN を実行して検査するというのも現実的ではありません。問題が発生してからではなく、発生する前に未然に対応することは出来ないでしょうか? そんなときに活躍するのがサーバー監視のグラフです。

SELECT の使い方を知る My SQL Select Types

クエリのチューニングはほぼイコール SELECT のタイプ、ということに尽きます。個別のクエリに対して EXPLAIN をすることでどのような実行計画を使っているのか知る事が出来ますが、このグラフを見ることでシステム単位でどういうタイプのものが実行されているのか、その全体像を知ることが出来ます。

Select Scan はテーブル(またはインデックスでも)の先頭行から全件検索(スキャン)をした回数です。Select Range は WHERE などの指定によって範囲が限定された探索を行った回数です。SQL のチューニングとして、「 SELECT にはインデックスを使用して探索行数や行ロックの範囲を少なくしよう」というのが一般的ですが、意図的に全件取り出す必要性もありますから、スキャンはゼロにはなりません。それでも Select Range  >>>  Select Scan というのがが望ましい状態です。上のグラフ例では反対に Select Scan が多くなっています。インデックスを使う余地のあるクエリが相当数あることがわかります。

もう一つのチューニングとして「JOIN はインデックスで行う」というものがあります。これがちゃんと守られているかどうかはインデックスのないカラムで JOIN すると記録される Select Full Join と範囲指定の効果はあるがやはりインデックスは使わず JOIN した時の Select Full Range Join (青の点線部)をみるとわかります。上のグラフでは 139 ミリ回という小さい値ですが、ここはゼロであることを目指しているので、見えた瞬間お!誰だ!という具合に気がづくことが出来ます。

クエリの I/O 動作を知ることが出来るグラフ  MySQL Handlers

Handler というのは MySQL のストレージエンジンのインターフェースで、その種類を見ることで InnoDB がファイル I/O 、ディスク I/O に近いローレベルでどういう仕事をしているのか見ることが出来ます。

Write, Update, Delete は名前のとおりの動作なので割愛して、ポイントとなるのは以下の Read 系の操作です。

  • Handler Read First テーブルやインデックスの全件検索(スキャン)の際には、まず最初に先頭レコードの取得を行います。その回数が Read First です。
  • Handler Read Key インデックスを使ってさらに範囲指定の効果が効いている場合、キー値に基づいてジャンプして行を読み取る操作を行います。その回数です。
  • Handler Read Next キー値に基づいて行を特定した後、後続の行を読んだ回数です。
  • Handler Read Prev 内容としては Next  と同様で、キー値でポイントを決めた後、その前の行を取得する操作です。
  • Handler Read Rnd InnoDB でプライマリキーの値を指定して1行データを読み込む場合、ディスクへのアクセス方法がシーケンシャルアクセスではなくランダムアクセスということで、MySQL の世界では歴史的に Random Read という用語が使われています。この Handler Read Rnd はプライマリキーを指定してピンポイントに1行読み込んだ回数になります。
  • Handler Read Rnd Next Read Rnd によってポイントを決めた後、引き続き連続して行を読み取った回数になります。単純なスキャン操作をしていることになるのであまり嬉しくない回数です。

Handlerr Read First は全件検索あたり1回しか計上されないので読み取り回数と比べると小さくてグラフでは見えませんが、数字を見ることで全件検索の回数の傾向がつかめます。同様に Handler Read Rnd と Handler Read Rnd Next を見ることで、全件検索によって読み込んだ行数がわかります。

上の2つのグラフを総合すると「全件検索する Select の割合が多いが読み込んだ行数の割合は少なかった」ということがわかります。このことから、チューニングされていないクエリがかなりあるものの、この段階ではあまり影響が出ておらず、今後データ量が増加すると影響が出るかもしれない、ということまで知ることが出来ます。

最後に

以上3つのツボ5つのグラフを見るだけで、実行されている SQL の挙動をつかみパフォーマンスチューニングへと活かすことが出来ますので、みなさんも是非ご活用ください!

次回後編は これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編) を予定しています。ご期待ください!

ーーーー

インフィニットループではプログラミングやインフラが好き、というエンジニアを募集しています。詳しくは募集ページ http://www.infiniteloop.co.jp/recruitment/ まで

2011年11月12日 (土)

著者 : 

【社内勉強会レポート】1時間でざっくり教えるサーバ運営超入門

matsuiです。

インフィニットループでは、毎週金曜日に社内勉強会を行っています。
今週は「1時間でざっくり教えるサーバ運営超入門」というネタでした。

「勉強用として自宅サーバとしてLinuxのインストールは行ったのだけれど、外部に公開するのがよくわからなくて怖い」
という話を社内でよく耳にするので、そのあたりの人を対象にしてみました。

スライド資料もアップしましたので、よろしければご覧ください。

※口頭での補足ありきの資料のため、スライド単体で見ると足りない点もあるかもしれませんがご了承ください。

いろいろなテクニックはあると思いますが、初心者にとっての大原則は次の3つだと思っています。

  • 何はともあれyum update、yum以外のパッケージやソースからのインストールは上達してから
  • 不要なサービスは止める
  • ファイアウォールが重要、利便性と安全性は裏表なので可能な限りIPアドレスは絞る

他にもアタックはどのように来るのかや、バナーの隠し方、サービスの停止後は再起動しろなど、細かいところを口頭で伝えたのですが、どうしても1時間では時間が足りないですね。

また機会があれば続編をやりたいと思います。

  • このブログについて

    このブログは、札幌市・仙台市の「株式会社インフィニットループ」が運営する技術ブログです。
    お仕事で使えるITネタを社員たちが発信します!

    最新の記事