Apache、Tomcatのチューニング

チューニング方法はメモリとインデックスしかない

・メモリ 32bit,64bit
64bitだとメモリの消費量が高いとされて実際高い
・PAE
32bitで4GiB以上のメモリを使う技術

Apache チューニング

1.HostnameLookups -> off
これがonだと、ログファイルにホスト名を出力するためDNSLookupしてしまう
2.無駄なログファイルを消す
ローテートする
3.無駄なモジュールをロードしない
4..htaccessを無効にする
※アクセスのたびにソンァイチェックをおこなうのでパフォーマンスが劣化する
※AllowOverride -> None
5.KeepAlive -> off
※HTTPはステートフルな接続のためリクエストのたびに接続切断が発生するためコストがかかる
※LBに格納されている場合あまり意味がない
6.MNM(Multi Proccessing Module)の選定
※preforkとworker
prefork 1リクエスト 1プロセス
-> mod_phpなどを使う場合はprework
worker 1リクエスト 1スレッド
-> マルチプロセス + マルチスレッド ハイブリッドモデル
-> プロセス数 * スレッド数 = Max Client
-> 1つのプロセスを立ち上げるよりも1つのスレッドを立ち上げる方が負荷が低い
7.無駄にプロセス起動、プロセスkillさせない
※以下の値を均等に保つ
※MaxRequestsPerChild 4000 を超えてもその対象のプロセスのみが終了->起動するだけ
StartServers 60
MinSpareServers 60
MaxSpareServers 60
MaxClients 60
※MPMがworkerの場合
ThreadsPerChild 25 × スレッド数 = MaxClients

ab

単純なストレスツール
#ab -n 1000 -c 100 http://192.168.0.50/ <=最後の／は必須

• n 数値 総リクエスト数
• c 数値 同時リクエスト数

Requests per second: 4270.68 [#/sec] (mean) <=1秒あたりのリクエスト回数
※スループットがこれ

tomcat

1.connectorの選択
※AJPかHTTP 汎用性の高いHTTPを使った方が無難
2.スレッドのパラメータ
maxThreads
minSpareTHreads
connentonTimeout
※基本はデフォルトで
3.不要なログを出さない
4.enableLookups -> off

vm

GCの利点
1.メモリリークを防ぐ
2.ダブルフリーを防ぐ
3.無効なポインタ参照を防ぐ

GCの欠点
1.FullGCの発生時にすべてのスレッドが停止する
2.GCが消費したメモリ量に対応して発生するため制御しづらい

GCの動き

• Xmx ヒープ領域全体
• Xmn NEW領域

ヒップ領域-> NEW領域,OLD領域
NEW領域-> Eden,Survivor
Survivor=> s0,s1

に分かれる

JVMのチューニングポイント

FullGCをなるべく発生させない
Scavenge GC

JConsole

※JMX(java management Extensions)を有効に

s0,s1がいっぱいだとEdenから直接OLDにいく
これだとFullGCでしか消せない
全体領域だけでなくNEWフィールドも増やす

起動パラメータに追加
CATALINA_OPTS="${CATALINA_OPTS}

• Dcom.sun.management.jmxremote=true
• Dcom.sun.management.jmxremote.port=3337
• Dcom.sun.management.jmxremote.authenticate=false
• Dcom.sun.management.jmxremote.ssl=false"

負荷分散

分散問い合わせの種類

1.ラウンドロビン
ただ単に順番に見に行っているだけ
単純な振り分けなのでCPUを使わないが、すべてのSlaveに完全なデータセットが必要
2.重み付けラウンドロビン
単純な振り分けだが、ハードウェアの性能に差がある場合などに有効。
これもすべてのSlaveに完全なデータセットが必要になる。
3.接続数最小
振り分け対象のサーバの中で一番現在の接続数が最小のものを選択してリクエストする。
リソース消費が少ないと思われるサーバを使用できるが、これもSlaveで完全なデータセットが必要であり、AP側でDBの接続数を聞きにいかなければいけない。

4.応答時間最短
定期的に各サーバへの応答時間をテスト用のリクエストで計測してその時間が最小のサーバに寄せていく振り方。
実際に計測した時間で重み付けされるので、性能の違うサーバが並んでいてもレスポンスが標準化される。
直近のテスト結果をストアしておく必要がある。

5.AP-DBサーバ固定
対応するAPサーバが処理するときに必要なデータのサブセットのみがDBサーバにあればいい。
対応するAPサーバ以外は対応するDBサーバを利用できないため、上位での分け方を行わないとリソース消費に偏りが出る。

6.リスト
問い合わせ対象のデータによってリストからw欄だサーバに問い合わせする振り方。
DBサーバはリストに対応するデータのサブセットだけもってればいい。
設計時になるべく一様になるキーを選ばないとリソースに偏りが出る。

7.レンジ
問い合わせ対象のデータによってレンジを求め、そのレンジに対応するサーバに問い合わせする振り方。

8.ハッシュ
問い合わせ対象からハッシュを求め、そのハッシュ値で選んだサーバに問い合わせする振り方。
DBサーバはハッシュに対応するデータのサブセットだけを持てばいい。
データのサブセットのみを持つと更新側にも同じルールの適用が必要。

分散KVS

NoSQL
格納データは単純さを求めた結果、PKと値という単純なデータ構造になってきた。

NoSQLの定義
1.キーと値
2.問い合わせにSQLのような重い解析を必要とする問い合わせ言語を必要としない
3.データは分散して配置され冗長性が高い
4.高負荷でもスループットが高い

相性がいいサービス
1.参照更新頻度が高い
2.データの更新参照に一時的に一貫性がなくてもいい
3.増え続ける大量のデータを格納したい
4.非正規化が容易

レプリケーションを利用した負荷分散

■スキーマ別レプリケーション
スキーマ別やテーブル別で分散する事ができる。
「Replicate_Do_DB」

my.cnf設定例
replicate-do-db = database1
replicate-do-db = database2
replicate-do-db = database1,database2

■テーブルごとの分散
「Replicate_Do_Table」
テーブルごとにSlaveサーバを分散する構成
※テーブルごとのレプリケーションとJOINは切っても切り離せない
物理的にJOINできない

my.cnf設定例
replicate-do-table=db_name.table_name

■ユーザーのIDをキーにしてテーブルの分割
ユーザーのIDを
キーにしてテーブルの分割を行い
レプリケーションで分散する
水平分割

■ストレージエンジンとレプリケーション
ストレージエンジンとレプリケーションを使った負荷軽減
MyISAMはトランザクションを使えない。
参照だけMyISAMを使う構成。
InnoDBも高速になってきたので、これはだんだんなくなった。
SELECTの発行回数が多い場合はSlaveサーバのストレージエンジンをMemoryエンジンにすることで速くなる。

alter table テーブル名 engine=memory;

■Masterサーバには不要なデータあるとき
MasterサーバのストレージエンジンをBLACKHOLEエンジンにすることで
MasterサーバのI/O負荷を軽減することが出来ます
BLACKHOLEエンジンはデータを保存・更新しないストレージエンジンになります
バイナリファイルのみ出力するので、Slaveに対してはデータが更新される。
http://blog.goo.ne.jp/sohgoh/e/44b19464bec097cb8063e42736639bcd

■Jdbcでのロード・バランシング
jdbc:mysql:loadbalance://host-1,host-2,...host-n/database?loadBalanceBlacklistTimeout=5000

jdbc:mysql:loadbalance://192.168.0.50:3306,192.168.0.50:3306/ensyu1
jdbc:mysql:loadbalance://192.168.0.50:3306,192.168.0.50:3306/ensyu1?loadBalanceBlacklistTimeout=5000

■はまりどころ
SLAVE START;

以降にreplicationされるのですが
これ以降のmasterへのupdateしか反映されません。

ですので、slave-master間の同一性を保つためには
replicationを開始する前に双方のデータベースの内容を同一にしておかなければなりません。

実行計画とレプリケーション

実行計画 EXPLAIN

クエリとスキーマの最適化を見極める。
http://dev.mysql.com/doc/refman/5.1/ja/explain.html

※show slave status \G でテーブルがみやすくなる

mysql> explain select * from emp;

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

ALL

NULL

NULL

NULL

NULL

50346

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.10 sec)

1.id
SELECT識別子。クエリ内におけるこの SELECTの順序番号

2.select_type
だいたいこれ-> SIMPLE 単純なSELECT (UNIONやサブクエリを使用しない)。
simple
primary
union
union result
※↑これら意外がでたら疑う。

unionクエリの場合これになる↓
mysql> explain select * from emp union select * from emp;

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1	PRIMARY	emp	ALL	NULL	NULL	NULL	NULL	50346
2	UNION	emp	ALL	NULL	NULL	NULL	NULL	50346
NULL	UNION RESULT		ALL	NULL	NULL	NULL	NULL	NULL

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

3 rows in set (0.00 sec)

3.table
結果を得るために参照するテーブル。

4.type
各結合型を最適なものから順に紹介する。
1.「const」 OK PK、UNIQUEインデックスでの等価検索
2.「ref」 OK UNIQUEじゃないインデックスを使用検索時
3.「range」 微妙 インデックスを使用した範囲検索時
4.「index」 微妙 index内でのフルスキャン
5.「ALL」 アウト 全表操作している。

■constになる場合
mysql> explain select * from emp where empid = '1';

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

const

PRIMARY

PRIMARY

4

const

1

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.00 sec)

テーブルに、一致するレコードが最大で 1 つあり、クエリの開始時に読み取られる。レコードが 1 つしかないため、このレコードのカラムの値はオプティマイザによって定数と見なされる。constテーブルは、1 回しか読み取られないため、非常に高速である。
この場合、typeはconstになる

■rangeになる場合
インデックスを使用して、一定の範囲にあるレコードのみが取り出される。

mysql> explain select * from emp where empid > '1';

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

range

PRIMARY,test_idx

PRIMARY

4

NULL

25294

Using where

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.01 sec)

■refになる場合
mysql> explain select deptid, count(*) from emp where hiredate = '1900/04/01';

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

ref

test_idx

test_idx

4

const

2423

Using where; Using index

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.00 sec)

ユニークじゃないインデックスで検索時

■ALLになる場合
インデックスを削除した。
フルテーブルスキャンが実行される。
不適切。

■※注意関数を使うとインデックスを使わない

mysql> explain select deptid, count(*) from emp where cast(hiredate as date) = '1900/04/01' group by deptid;

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

index

NULL

test_idx

8

NULL

50000

Using where; Using index; Using temporary; Using filesort

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.00 sec)

インデックスを使ってGROUP BYを解決できない場合には、テンポラリテーブルを使ってクエリを解決する。

mysql> explain select * from emp;

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1

SIMPLE

emp

ALL

NULL

NULL

NULL

NULL

50346

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

1 row in set (0.00 sec)

5.possible_keys
このテーブル内のレコードの検索に MySQL で使用可能なインデックスを示す。
where句から読み取る。

6.key
keyカラムは、MySQL が実際に使用を決定したキー（インデックス）を示す。

7.key_len
MySQL が実際に使用を決定したキーの長さを示す。 keyが NULLの場合、この長さは NULLになる。

8.ref
検索条件で、keyと比較されている値やカラムの種類。定数が指定されている場合はconstと表示される。
すなわち、where empid = '1'; の用な場合はconst。

9.Extra
MySQL でどのようにクエリが解決されるかに関する追加情報が記載される。
クエリの実行速度をあげたい場合はmUsing filesortとUsing temporaryのExtra値に注目する。
そのクエリを実行するためにオプティマイザがどのような戦略を選択したかということを示すフィールドである。

■Using where
頻繁に出力される追加情報である。WHERE句に検索条件が指定されており、なおかつインデックスを見ただけではWHERE句の条件を全て適用することが出来ない場合に表示される。

■Using index
クエリがインデックスだけを用いて解決できることを示す。高速。
カバリングインデックスを利用している場合などに表示される。

■Using filesort
クイックソートでソートを行っていることを示す。

■Using index for group-by
MIN()/MAX()がGROUP BY句と併用されているとき、クエリがインデックスだけを用いて解決できることを示す。

■Using temporary
クエリの解決に MySQL で結果を保持するテンポラリテーブルの作成が必要であることを示す。これは一般に、GROUP BYを実行したカラムセットと異なるカラムセットに対して ORDER BYを実行した場合に発生する。

■カウント関数の利用
mysql> select count(*) from emp;

• • • • • • • • • • • +

count(*)

• • • • • • • • • • • +

50000

• • • • • • • • • • • +

1 row in set (0.02 sec)

MyISAMでのカウント関数。
MyISAMはinsertされたら集計しているので速い。
mysql> select count(*) from emp_copy;

• • • • • • • • • • • +

count(*)

• • • • • • • • • • • +

50000

• • • • • • • • • • • +

1 row in set (0.00 sec)

パラメーター

my.cnfの設定

innoDBに限る
※エンジンの確認
show table status \G;

※エンジンの変更
ALTER TABLE tbl1 ENGINE InnoDB;

1.innodb_buffer_pool_size
実メモリの8割ぐらい割り当てる。

innodb_buffer_pool_size	8388608
innodb_log_buffer_size	1048576

# vim /etc/my.cnf
innodb_buffer_pool_size=16M
innodb_log_file_size=10M

innodb_buffer_pool_size	16777216
innodb_log_buffer_size	1048576

2.innodb_log_file_size
ログのファイルサイズ。

3.innodb_log_buffer_size
メモリ上のバッファサイズ。

4.max_connections
とりあえず1000くらい設定しても大丈夫な値。

# vim /etc/my.cnf
max_connections=100000

5.slow_query_log,long_query_time
遅いクエリを出す。

# vim /etc/my.cnf

slow_query_log=ON
log_slow_queries = /var/lib/mysql/slow_query.log
long_query_time=0 閾値

# /etc/init.d/mysqld restart

6.クエリキャッシュ

確認
mysql> SHOW VARIABLES LIKE "%query_cache%";

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

Variable_name

Value

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

have_query_cache	YES
query_cache_limit	1048576
query_cache_min_res_unit	4096
query_cache_size	1048576
query_cache_type	ON
query_cache_wlock_invalidate	OFF

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

6 rows in set (0.00 sec)

レプリケーションを使った負荷分散

Master 更新系
Slave 参照系

Master が吐き出したログはバイナリログ
Slaveが吐き出したログはリレーログ

Masterが吐き出すバイナリログには何が入るか？
INSERT UPDATE DELETE 更新系
バイナリログ 2種類

• > SQL文 ステートメントベース SQL文
• > 値が記録される 行ベース 更新後の値 5.1.5から

■問い合わせ
1.ロードバランサ (L4ロードバランサ)

長所
AP側か分散しているDBにアクセスしていることを意識しなくていもいい。

短所
購入コスト。
複雑な振り分けができない。

2.APサーバ

長所
プログラム側で接続先を指定できる。

短所
振り分けについて設計しないとだめ。

MySQLのレプリケーション設定

マスターの設定
やること:

①設定ファイルにマスター設定を追加
# vim /etc/my.cnf
server-id=22 <-サーバ識別ID
log-bin=mysql-bin <-バイナリファイルの設定

②ユーザに権限を与える
GRANT REPLICATION SLAVE ON *.* TO 'ユーザ'@'相手のホスト' IDENTIFIED BY 'パスワード'; <-スレイブ権限追加
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.65' IDENTIFIED BY 'replpass';

③マスターの情報確認
SHOW MASTER STATUS;

④データベース作成
CREATE TABLE `pokemon_master` (
`id` BIGINT,
`name` VARCHAR(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;

INSERT INTO `pokemon_master`(`id`,`name`) VALUES(2,"awamura");

スレーブ側

server-id = 18 (←ユニークな適当な数字へ変更)

また以下を設定ファイル内のどこかに追記(ある場合はそのままでOK)
log-bin = mysql-bin

CHANGE MASTER TO
MASTER_HOST='マスターのIPアドレス',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=189;

SHOW SLAVE STATUS\G

チューニングのはなし②

データストア

HDDというデバイス->ボトルネックになるのはシークタイム

シーク ・・・ HDDがディスクを読み出すためにヘッドを動かす処理
シークタイム ・・・ それにかかる時間

シーケンシャルアクセスするときとランダムアクセスでも、だいぶ変わるらしい。
ディスクアクセスは結局遅い！

RDBMS

RDBMSはデータストアとしては鉄板。
ACID特性をもつデータストシステムとしては未だに健在。
しかし、大規模データを扱わなければいけない中でそろそろRDBMSではパフォーマンスを出せなくなってきた。

• > 分散KVSへの流れ

有償RDBMS

Oracleの誕生

• >ライセンスが馬鹿高いのでスケールアウトしてもコストが低いOSSという流れ。

・スケールアップ
単体マシンの処理能力を上げること。
しかし、性能をあげるには限界がある。

・スケールアウト
要求される、処理量に応じてマシンを増やすこと。
マシンを増やすことで処理能力を増やす。

データベースのチューニングについてできることは2つしかない
「インデックス」と「メモリ」

MySQL

MySQLに出来ることは、Olacleに比べて少ない。
インデックスの仕組み
・複合インデックス
・セカンダリインデックス
・PKはクラスタインデックス

インデックス

・MySQLで作成可能なインデックス構造はB-Treeインデックス
・Hashインデックス

B-Treeインデックス

なにも指定しないとMySQLではB-Treeインデックスになる。

メリット
・レンジスキャンに向いてる 幅を指定するとき便利
・ORDER BY句にインデックス列がすべて含まれる場合はソート済みになっているのでソート処理がおこなわれないで済む 重いから

デメリット
更新時にホットスポットが出来やすい

※InnoDBではクラスタインデックスになる
リーフノードにテーブルレコードが含まれる

Hashインデックス

インデックス対象カラムにHash関数をかけて、求められたHash値を利用して格納場所を指定する

メリット
等価検索ではB-Treeの方が速い

デメリット
レンジスキャンはできない

セカンダリインデックス

一つのテーブルには0個以上のインデックスを付与することが出来る。
プライマリーキーでないインデックスも付与することが出来るが参照のパフォーマンス派落ちる

複合インデックス

複数のカラムにまたがってインデックスをつけたものを複合インデックスと言う。
インデックスの付与順がすごく大事。

「グループid,ユーザid」と「ユーザid,グループid」という順番につけられたインデックスは別物である。

「グループid,ユーザid」はグループidでソートされてから、ユーザidでソートする。
「ユーザid,グループid」はユーザidでソートされてから、グループidでソートする。

原則、なるべく絞り込める方を前にする

インデックス作成の注意

1.カーディナリティの低いデータはインデックスをつけない
flgのようなtrue,falseの2値データしかないものはインデックスをつけても意味がない

2.インデックスを後からつけるのは負荷が高い

3.全表操作が必要になるので作成時に負荷があがる
降順インデックスはサポートされていない

キャッシュ

バッファキャッシュ
SELECTされたデータやインデックスをメモリ上にキャッシュする機能
ディスク参照をスキップする

# mysql (databasename) -u root
mysql > SHOW VARIABLES LIKE "innodb_%_size";

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

Variable_name

Value

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

innodb_additional_mem_pool_size	1048576
innodb_buffer_pool_size	8388608
innodb_log_buffer_size	1048576
innodb_log_file_size	5242880

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • +

4 rows in set (0.00 sec)

innodb_buffer_pool_size はデフォルトで8Mしか設定されていないのであげる。

インメモリストレージエンジン

MEMORYストレージエンジン
ディスクアクセスの部分をメモリで行う。

データの抽出

クエリキャッシュ
SQLの解析処理は重いので、そこをスキップすることが出来る

インデックス参照の掟

一つのデーブルにつき一つのインデックスしか参照されない
複合インデックスの場合、順序も重要
(A,B)という複合インデックスの場合、SELECTでBだけ等価条件をもつものはインデックスを使わない

カバリングインデックス

クエリで使用するすべての列を含む。
検索条件WHEREで使っている列もSELECT userid のように表示に使うものもすべて含んだインデックス。

LIKE検索は前方一致のみに使う

LIKE '%test' <-これは後方一致なのでインデックスが使用されない

JOINは禁止

大規模データの場合、非正規化を行ったり、AP側で処理させた方が速いケースがある

チューニングのはなし

ウェブ性能チューニング①

WEB３層システム

クライアントサーバシステムにおいて、大きく3段階に分けてそれぞれに担当するシステムを分割させたアーキテクチャのこと。

・プレゼンテーション層
-> ブラウザに表示させる。HTTPリクエストを処理する
・アプリケーション層
-> ビジネスロジックを受け持つ。
・データベース層
-> データベースを管理する。

最近流行のワード

・リバースプロキシ
特定のサーバの代理として、そのサーバへの要求を中継するプロキシサーバ。
・CDN
コンテンツデリバリネットワーク
webコンテンツを配信するために最適化されたネットワークのこと。
akamai
・Kyoto Tycoon
NoSQL。キャッシュサーバ。
永続化可能。
TokyoTyrantの開発者と同じ。

ACID特性

トランザクション処理に求められる特性。

・A (atomicity 原子性)
変更はすべて実行されるかすべて実行されないかのどちらかでないといけない
・C (consistency 整合性)
変更処理のあとでデータの整合性がとれていて矛盾がないこと
・I (isolation 独立性)
ひとかたまりの変更処理は、他の変更処理と独立していて、並列実行された場合も結果は同じになること
・D (durability 永続性)
変更処理はユーザに通知された時点で永続化されることを保証する。

性能評価指標

・レスポンスタイム
リクエストを出してから最初の反応があるまでの時間
・ターンアラウンドタイム
リクエストに対する応答が完全に終了するまでの時間
・スループット
単位時間あたりの処理量
サイトの処理能力を表す
・リソース指標
CPU、メモリ、HDD、ネットワーク流量などの指標
・SLA
ServiceLevelAgreement レスポンスタイムやスループットの指標を決める

Apache Jmeter

性能測定ツール
Webサーバに対して負荷をかけたり、JDBCを経由してデータベースサーバに負荷をかけたりして、各種の測定を行うツールです。

Jmeter 使い方

jmeter/bin
jmeter.bat を実行

プロキシを使ったキャプチャ
ワークベンチから

スレッドグループ
スレッド数 ->複合的な接続をシミュレートする
Ramp-Up期間 -> していたスレッドをすべて立ち上げるのに何秒かかるか
ループ回数 -> スレッドを何ループさせるか
スケジューラ -> テストを定時実行させたい場合

ロジックコントローラー
一度だけ実行させるコントローラ
ループコントローラ
ランダム順序コントローラ
インタリーブコントローラ
シンプルコントローラ
Ifコントローラ
ForEachコントローラ

設定エレメント
CSV date set config
HTTP クッキーマネージャ
HTTPヘッダマネージャ
JDBC Connection Configraton

タイマ
定数タイマ
一様乱数タイマ
ガウス乱数タイマ

サンプラー
HTTPリクエスト
JDBCリクエスト

リスナー
統計レポート
結果を表で表示
結果をツリーで表示 Response headerがみれる
グラフ表示 スループットがみれる

一台では十分なテストが出来ない場合

jmeter-serverコマンド
GUIを実行しているクライアントからの要求でリモート実行させることが出来る

環境構築

CentOS の ダウンロード
http://www.centos.org/modules/tinycontent/index.php?id=32

言語 Japanese
キーボード ja106
installation method 「FTP」
IPv6のオプションは外す 「スペース」キー
FTP setup 入手した先「ftp.riken.jp」directory 「/Linux/centos/5/os/i386」と入力する

ちなみに、
tab で ok or back
スペース でチェックを外す

初期化
基本デフォルト rootパスのみ入力
入れたいツールは自分で入れるので
今すぐカスタマイズ
開発 開発ツール
ベースシステム ベース
言語 日本語
最低限のものだけ入れる
インストールを待つ
再起動が要求されるので、ディスクを抜いてから(設定の「ストレージ」)

root
からパスワード入力

OSの更新
yum -y update

• y は すべて yesという意味

complete!が出たら終了

macのターミナルから操作する
/sbin/ifconfig

Webサーバーのインストール（sudo yum -y install httpd）
MySQLのインストール（sudo yum -y install mysql-server）
PHPのインストール（sudo yum -y install php php-devel php-pear php-mbstring php-gd php-mysql）

Selinuxを切る

vi /etc/systemconf/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

SELINUX=enforcingをSELINUX=disabledに変更
Selinuxを無効にする

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

iptablesの無効化
/sbin/service iptables stop
/sbin/chkconfig iptables off

webサーバーの起動
/sbin/service httpd start
/sbin/service mysqld start

* 再起動時にWebサーバーを起動（chkconfig httpd on）。
* 再起動時にMySQLを起動（chkconfig mysqld on）

webサーバーの確認
http://mizunuma.dev にアクセス

mysqlの確認
mysql -u root
でmysqlに入ればok
exit;で抜ける

chown mizunuma /var/www/html というふうにdocument rootの所有者を変更する