にわかサーバー屋さんの覚書

サーバー系を担当しているけど、設計などは日々勉強中のプログラマの覚書

MySQL - スレッド毎のバッファ調整

前回は、コネクションとスレッドの調整を書いたけど、

おまけで、スレッド毎のバッファの調整も聞いたのでメモ。

my.conf

sort_buffer_size

ORDER BYやGROUP BYのときに使われるメモリ上の領域らしい。

ソートするカラムに対して、インデックスがついていない場合に利用される。

ソート用のメモリを超える場合、ディスクを使用。

 

 

この値を調整する際に、指針とする値が、

Sort_merge_Passes

 上記の値は、テンポラリファイルを利用したソートの回数(マージソートのパス数)を表示。

つまり、メモリでは収まっていないと言うこと。

 

Sort_merge_Passesの確認方法

show global status like 'Sort_merge_passes';

+-------------------+-------+

| Variable_name     | Value |

+-------------------+-------+

| Sort_merge_passes | 0     |

+-------------------+-------+ 

 ゼロが望ましいそうです。

 

ただ、こちらの値はデフォルト2Mで、特に問題が起きたことは無いそうです。

調子に乗って、大きすぎると、メモリの割り当てのオーバーヘッドになるので注意。

 

まぁ、使うケースとしては、集計などのバッチ処理を行う場合に、

事前に調整しておいて実行して、終わったら戻すといった感じで使うのがいいみたい。

 

MySQL - 接続数が多いときの設定(同時接続とスレッドキャッシュ)

MySQLに接続数が多いときの設定の覚書

 

MySQLはクライアントから接続の度にスレッドを作って、

処理してはクライアントに返して、スレッドを破棄します。

 

そこで、サーバーにアクセスが多い場合に、調整するのがいい項目があったりします。

 

同時接続数

MySQLに同時に接続できる台数があり、それを超えると。

[1040] Too many connections と怒られます。

 

確認

SHOW STATUS LIKE 'Max%';

※長いのでこんなのでいい

+----------------------+-------+

| Variable_name        | Value |

+----------------------+-------+

| Max_used_connections | 1     |

+----------------------+-------+

このパラメータどれだけ接続数があるか確認。

 

my.conf

max_connections

※デフォルトは100

300にする場合

max_connections=300

  

接続増やすと作成されるスレッドも増えるので、スレッドの方も調整する。

 

スレッドのキャッシュ

コネクションの切断後に、スレッドをキャッシュしておくサイズです。

 

my.conf

thread_cache_size

デフォルト8M

 

max_connectionsが300の場合

thread_cache_size=100

※一般的な設定は、max_connectionsの3分の1みたいです。

 

確認

SHOW STATUS LIKE 'Threads%';

コレで表示される、

+-------------------+-------+

| Variable_name     | Value |

+-------------------+-------+

| Threads_cached    | 0     |

| Threads_connected | 1     |

| Threads_created   | 1     |

| Threads_running   | 1     |

+-------------------+-------+

 

その中の、Threads_created

 

これは、新しく作成されたスレッド数ってことなので、

この数がキャッシュのミスというか、ハズレ。

これが、0であれば全部キャッシュでヒットしていると言うことになります。

 

 

基本中の基本のような設定か。

もう、これだけでおなかいっぱい。

NoSQL - mongoDBのこと

もう、概念的なところだけは何となく理解して、

周りでしゃべっていることだけでも理解していこうと精一杯です。

 

で、mongoDB

 

まずは、どんな製品かって言うと、

KVSっぽい高速な処理速度と、RDBの様な機能も捨てない

って感じでしょうか。

 

KVSっぽいって部分は、テーブルなどは無く、

ドキュメント指向と呼ばれるように、JSON形式のデータで格納する。

{"id": 10001, "name": "ゲス山ゲス男"}

 ※実際の書き込みは、JSONをバイナリにした感じらしい。

で、コストの高いトランザクションはなく、機能としてJOINとかも無い。

 

 で、RDBぽいってところは、

KVSがキーの完全一致でデータを引っ張ってくるに対して、

mongoDBは、SQLでいうと、select/where/order byや、group byとかいけるみたい。

db.table_name.find({id:10001})

 

ということで、

割とシンプルな読み書きだけで、でも、アクセスはどえらい多い様なシステムには、

向いてるんじゃ無いでしょうか。

私が見た中では、ログオン履歴、購入履歴など、

ログ保存のサーバーとして運用されておりました。

 

その他、シャーディングと呼ばれる、

複数のサーバーにデータの分散して保存する機能なども、

自動でスケーリングしてくれる機能などもあるようです。

WEB+DB PRESS Vol.75

WEB+DB PRESS Vol.75

 
MongoDBのはじめての運用テキスト

MongoDBのはじめての運用テキスト

 

 うん、このmongoDBは使いどころはありそうですね。

 

閉鎖するサイトのドメインを、他のWEBサーバーへ振った際のmod_rewriteの覚書

AとBというサイトが別のサーバーで運営されてて、

Aを閉鎖。

 

Aサーバーの契約が無くなるので、

AドメインをBのサイトのIPに割り当てる(DNS)。

 

同じサーバーだが、

Aドメインを指定してきたクライアントには、閉鎖のお知らせ

Bドメインを指定してきたクライアントには、通常のサイト

を表示する。

 

仕込んだ処理は、

 

Bのドキュメントルートに、.htaccessを仕掛けて、

HTTP_HOSTを使いmod_rewiteで判定。

該当すればサブディレクトリの閉鎖お知らせ情報を表示。

 

ディレクトリ構造

DocumentRoot(Bサイト - ドキュメントルート)

   └A(ディレクトリ)

    └index.html(閉鎖のお知らせ)

 

.htaccess

RewriteEngine on

RewriteBase /

RewriteCond %{HTTP_HOST} ^www.aaa.co.jp$ [NC]

RewriteRule ^$ A/index.html [L]

 

で、お知らせ表示でけた。

 

VirtualHostでやるとかってことも出来るけど、アクセスも少ないしmod_rewriteでサクッとできるのでこの対応に。

 

NoSQL - KVS(Radisのこと)

ざっと、私の周りの実装をみると、

NoSQL系でみたことがあるプロダクトとしては、

memcached、Redis、MongoDBですね。

 

で、memcachedと、RedisがKVS。

どちらもインメモリで動作するので高速。

 

 

memcached

  • 結果をセット、ゲットするシンプルな動作
  • データを古いデータから自動で消しちゃう
  • クラッシュなどしたら揮発しちゃう

結局、キャッシュ。ちゃんとデータが消えないようにするには、

これまでのRDBMSで保存しておく必要があるため限界がある。

 

そこで、データはちゃんと保存しておきたい、

でも、memcached並みに早いのがいい。

 

といった、わがままなニーズに応えてくれるのが、Radis。

おまけに、連想配列とか、データのソートとかデータを扱う機能も充実してるらしい。

 

Radis

  • インメモリで早い
  • データ構造化も扱えるよ
  • 定期的にスナップショットを取ってくれるからちょっと安心

 

MySQL+memcachedでもヒーヒー言いそうなシステムなら、

Radisどうよ?って感じですかね。

 

大量のユーザーを抱えたゲームのランキングシステムなんかに向いている感じかな。

 

 

こんなふわふわした理解、大丈夫なのかな。。。