LIMILIC

ギルドラ確率厨のメモです。

• りみりく
• プレビュー、jottitみたいにリアルタイムで出来るといい。

• 馬柱2chから。

• セイクリッドVSタッチミー
• えおりん＆サトノ⇒ハンデ次第
• 新潟巧者サンベガ状態どうなのか
• キングリー新潟外回りどうか
  • つか札幌記念出とけよ。

use Plack::App::CGIBin;
use Plack::Builder;
my $cgibin = Plack::App::CGIBin->new(
    root => "/usr/local/nagios/sbin",
    exec_cb => sub { my $file = shift; $file =~ m!\.cgi$! and -x $file },
)->to_app;
my $static = Plack::App::File->new(root => "/usr/local/nagios/share")->to_app;

builder {
    enable 'ReverseProxy';
    enable sub {
        my $apps = shift;
        sub {
            my $env = shift;
            $env->{REMOTE_USER} = 'xxxxx';
            $env->{PATH_INFO} .= 'index.html'
                if $env->{PATH_INFO} =~ m!^/nagios/([^\.]+/)*$!;
            $apps->($env);
        };
    };
    mount '/nagios/cgi-bin' => $cgibin,
    mount '/nagios' => $static,
}

試したのはubuntu 10.04にて

$ apt-get install libmysqld-dev
$ mysql_config --libs --include --plugindir
-Wl,-Bsymbolic-functions -rdynamic -L/usr/lib/mysql -lmysqlclient
-I/usr/include/mysql
/usr/lib/mysql/plugin
$ cd /tmp
$ wget http://q4m.kazuhooku.com/dist/q4m-0.9.5.tar.gz
$ sudo apt-get source mysql-server
$ ls -1
mysql-dfsg-5.1-5.1.41
q4m-0.9.5.tar.gz
$ tar zxf q4m-0.9.5.tar.gz
$ cd q4m-0.9.5
$ CPPFLAGS="-I/usr/include/mysql" CFLAGS="-L/usr/lib/mysql" ./configure \
--with-mysql=/tmp/mysql-dfsg-5.1-5.1.41 \
--prefix=/usr
$ make
$ cp src/.libs/libqueue_engine.so /usr/lib/mysql/plugin
$ cat support-files/install.sql| mysql

MySQLのソースはビルドしなくても入るっぽい

「サーバが死んだ（運用屋さん）」「サーバが落ちた（プログラマさん）」 「サーバが飛んだ（ハード屋さん）」「サーバ壊れた（機器管理の事務員さん）」「サーバ動かない（ユーザさん）」と言う法則を目の当たりにしておりまする。様々

http://twitter.com/itimasan/status/91334502445613057

つまり、

• 「サーバが死んだ」=> サーバを擬人化
• 「サーバが落ちた」=> サーバを隷属化
• 「サーバが飛んだ」=> 電気的、物理的に飛んだ
• 「サーバが壊れた」=> 理由はあまり関係ない
• 「サーバ動かない」=> サーバを使う側から見た現象

ということなのか

statusカラムとインデックスについて。

CREATE TABLE entries (
    id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
    body VARCHAR(255),
    category TINYINT NOT NULL,
    status TINYINT NOT NULL,
    created_at DATETIME NOT NULL,
    INDEX(status)
) ENGINE=InnoDB

ここに、98%の確率でstatus=1、残り2%はstatus=0となるようにデータを5000行入れて検索する
テストはMySQL 5.5でやってます。

mysql> explain SELECT * FROM entries  WHERE status=1;
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | entries | ALL  | status        | NULL | NULL    | NULL | 5187 | Using where |
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

これは、インデックスを使っても絞り込めないので、テーブルスキャンとなる。

LIMITをつけると、インデックスを使う

mysql> explain SELECT * FROM entries  WHERE status=1 ORDER BY id DESC LIMIT 100;
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key    | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
|  1 | SIMPLE      | entries | range | status        | status | 1       | NULL | 4899 | Using where |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

rowsが4899件とインデックスでは絞り込めていないようにみえるが、statusインデックスを後ろから100件読むだけで済むので効率は良い。実際ROW OPERATIONは100行になる。

つぎに、statusカラムではなく、FORCE INDEX(PRIMARY) を使う。

mysql> explain SELECT * FROM entries FORCE INDEX(PRIMARY)  WHERE status=1 ORDER BY id DESC LIMIT 100;
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | entries | index | NULL          | PRIMARY | 4       | NULL |  100 | Using where |
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
1 row in set (0.00 sec)

rowsは下がるが、ROW OPERATIONは100+2(status=0を飛ばす分)のようだ。はてしてこれは上と比べてどの程度非効率なのかどうかが、よくわからない

データの論理削除のためにstatusカラムを用いることはあるとよく思うんだけど、検索条件に合わせてインデックスにstatusを追加していくのがよいか、ソート条件だけインデックスしてstatusのフィルタリングはMySQLに任せるか、アプリケーションのロジックでやるのも含めてどの手段がいいんだろうな

statusのある／なし分インデックスを追加するのはないと思うので、後者の2つがいいのかなと個人的には思う

nginxで http://example.com//foo/bar にきたリクエストを /foo/bar にredirectする

location / {
  if ( $request_uri ~ ^// ) {
    set $doubleslash "R";
  }
  if ( $request_method = GET ) {
    set $doubleslash "${doubleslash}M";
  }
  if ( $doubleslash = RM ) {
     rewrite ^/(.+)$ /$1 redirect;
  }
}

nginxのifは複数の条件をいれたり、nestしたりできないので大変

参考 http://rosslawley.co.uk/2010/01/nginx-how-to-multiple-if-statements.html