2010-12-21
munin の memcached プラグイン - sotarokのお勉強
Munin |
/usr/share/munin/plugins/memcached_
ってファイルがあって、これに普通にsymlink張るだけだとどうも動作しなかった。どうやら、同じ実行ファイルで、ファイル名から、取得する情報を変更する、的な実装になっているみたい。（これはあるバージョン移行のif_eth0などもそうみたい）
なので、symlinkは、以下の3種類を作ってあげる。
$ cd /etc/munin/plugins $ sudo ln -snf /usr/share/munin/plugins/memcached_ memcached_bytes $ sudo ln -snf /usr/share/munin/plugins/memcached_ memcached_counters $ sudo ln -snf /usr/share/munin/plugins/memcached_ memcached_rates
これで動作する。
(あ、あとなんか CPAN の Cache::Memcached がインストールされてなくて動作しない、ということもあった。CentOSの場合は sudo yum install perl-cache-memcached などで入れる)
|
—
|
httpd.conf に FileETag MTime Size と記述すると
“ ・基本設定
httpd.conf
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
ProxyPass / balancer://photoweb/ timeout=2
<Proxy balancer://photoweb>
BalancerMember http://web1.photozou.jp loadfactor=10 keepalive=On
BalancerMember http://web2.photozou.jp loadfactor=10 keepalive=On ..
BalancerMember http://webN.photozou.jp loadfactor=10 keepalive=On
</Proxy>
/ にアクセスした際に、BalancerMember に proxyされ、応答のないサーバには自動的にバランスしなくなります。
BalancerMember には IPアドレスや URLがつかえます。一般的には IPアドレス を指定したほうが
高速ですが、フォト蔵ではIPアドレスは使用せず、すべて名前で指定しています。
・etag に関して
FileETag INode MTime Size
となっています。
つまり web1 に画像を取りに行って ETag 値をもらっても web2にアクセスすると
i-node値が異なるため、違うETag値が返ってしまうので、 304 になりません。
そこで、web1, web2の httpd.conf に
FileETag MTime Size
と記述すると
ファイルの最終修正時刻とファイルサイズを見るようなるので、どちにアクセスしても304が返るようになります。
・アクセスログに関して
web1,web2 は proxy1 からアクセスされるので ローカルネットの IPAdress が
アクセスログに残ってしまいます。そこで web1,web2 に mod_rpaf を導入しましょう
http://stderr.net/apache/rpaf/
このモジュールをロードするとX-Forwarded-For を Host に上書きしてくれます。
今回は mod_rpaf-0.5.tar.gz を使用しました。
Makefile の APXS= の部分を適切な場所に書き換えて
make rpaf-2.0
sudo make install-2.0
httpd.confに
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1 10.0.0.10
RPAFproxy_ips に書き換える HOSTのIPアドレスを連続して書けるのですが、10.0.0. や 10.0.0.0/16
などと書くことはできません。
これは mod_rpaf-2.0.c の 123行目付近が strcmp(remote_ip, list[i]) == 0
となっているのが原因なので。これを strstr や strncmp に変更すれば
解決しそうです。
・SSLに関して
最初は poundを使用するつもりでしたが、不安定になることがあったので
proxy1ではmod_sslでSSLデコードしています。よって、ローカルネット内ではhttp でパケットが流れています。
しかし web1 が http、httpsでどちらでリクエストが来たのかを知りたい場合があります。
例えばログイン部分でHTTPS と HTTP のリンクを切り替えたりする場合です。
そのような場合には
httpd.confに
RequestHeader set X-SSL-REQUEST %{HTTPS}s
とつけてあげると、 X-SSL-REQUEST というヘッダが入ります。 %{HTTPS}s の部分は
apacheがSSLだと on と加えてくれますので、web側ではこのヘッダを見るのが
良いかと思います。
X-SSL-REQUEST は自由に変更できるので、推測されにくい文字列の方がよいかもしれないですね
・Proxyする必要のあるものと無いもの
静的な画像データなどは web にわざわざ取りに行かなくて proxyサーバに乗せておけば
良いと思います。mod_rewrite で
RewriteRule ^(css|img|js)/ - [L]
などとして、 /img などのファイルは そのまま document_root に飛ばすのが良いかと思います。
”
|
—
|
|
英数字だけなら 10 バイトくらいしか消費しないってことか
mysql |
“CHAR(10) と定義すると問答無用で 30 バイト持っていかれるが、 VARCHAR(10) って定義しても、データが英数字だけなら 10 バイトくらいしか消費しないってことか。”
|
—
|
れぶろぐ - [MySQL] VARCHAR 型の消費バイト という事は英数字が入るところはcharではなく極力varchar型にした方が良いという事みたいですね。 |
single-transaction --master-data=2
mysql |
“ MySQLのデータベースをバックアップする際にmysqldumpを使用しますが、個人的に「これはつけたらよさそう」と思っているオプションを紹介します。
–opt
–quick –add-drop-table –add-locks –extended-insert –lock-tables を指定するのと同じです。ダンプしたデータをMySQL サーバに読み込むための最速ダンプを提供します。(マニュアルそのまんま)
–single-transaction
ダンプする際に先頭にBEGINをつけるため、ダンプ時のデータのトランザクションの一貫性を保つことができます。ただしInnoDBなどのトランザクションが有効なストレージエンジンではないと意味がないです。
–flush-logs
ダンプを開始する前に、MySQL サーバ内のログファイルをフラッシュします。バイナリログを保存するような設定になっている場合はこれがフラッシュされます。ダンプしたデータとバイナリログを使用してデータを復元する場合に有用です。
–master-data
CHANGE MASTER TOコマンドをダンプの先頭に付加します。–master-data=2を指定するとCHANGE MASTER TOがコメントアウトされた状態になります。–maser-data=1と指定するとコメントアウトされずにダンプされます。
–default-character-set
ダンプする際の文字コードを指定します。
–hex-blob
バイナリ型のデータをエスケープ処理を行わずに実際に格納された値の16進表記でダンプします。 これを指定しないと default-character-set がSJIS系の場合エスケープ処理に失敗し、バイナリデータが壊れてしまう場合があります。
まとめ
自分はこんな感じでバックアップをとっています。
$ mysqldump -uroot -pxxxxxxxx --opt --flush-logs --single-transaction --master-data=2 --default-character-set=utf8 --hex-blob <database>”
|
—
|
mysqldumpでバックアップをする時につけるオプション | おいぬま日報 —optは良さそうですね |
「MySQL環境におけるFusion-io検証結果とDeNAにおける活用価値」
“ 後半の2セッションだけ参加してきたのですが、おそらく全4セッションのうちの前半の3セッション分は資料が公開されそうなので、最後のDeNA松信さんのセッションのメモを以下に残しておきます。
数字的な検証結果も興味深いところですが、ディスクやファイルシステムの特性、MySQLの仕様、I/O種別などを理解した上での適材適所な
設計をすることでパフォーマンスは大きく変わってくるんだと改めて再認識しました。めちゃめちゃ参考になりました！松信さんありがとうございました！
※ 尚、聞きながら、急ぎ足でメモを取ったので、内容・数字に誤りがある場合があるかもしれませんが、ご了承ください。
講演者
DBサーバにおいてSSDがなぜ必要か
- SSD化によって、IOPSが桁違いに向上する
- ほとんどのデータベースアクセスはランダムI/Oになる
- 通常のSAS HDDでは、1ドライブあたり200IOPS程度
- SATA SSDのIOPSは、2000+ (write) / 5000+ (read)
- PCI-E SSDになると、数万単位のIOPSを実現できる
SSDによるパフォーマンス向上と、1台あたりの処理量が大きくなることによるサーバの台数削減が可能
”
|
—
|
DeNA松信さんの「MySQL環境におけるFusion-io検証結果とDeNAにおける活用価値」セッションメモ - RX-7乗りの適当な日々 1台170万円とそれ何理工科ですが、その性能はとても高いFusion-io。 そちらの松信さんによる検証記事です。 |
アクティブサポートが、プレミアサポートと名前を変えて5年間に延長されました
mysql |
“ 従来MySQL EnterpriseにはBasic($599/年)、Silver($1,999/年)、Gold($2,999/年)、Platinum($4,999/年) Basic相当のものがなくなってしまったのが値上げと判断される主な理由なのですが、Basicについては ・アクティブサポート期間のみのサポート提供 (リリース後2年、MySQL 5.1で2010/12/31まで) と制限がきつく、受託システム開発ではまず使うことのないEditionです。 旧Silver相当の新Standard Editionについては、MySQL Enterprise Monitorが外されたという 逆に今回のEdition変更に伴いサポートポリシーが変更され、これまで2年間だった 通常企業向けシステムは5年程使われることを考えると、従来の2年間のアクティブサポートは 無償で利用できるCommunity Editionは中身の変更はまったくありませんし、 ついでですが、MySQL Clusterは劇的な値下げになっています。 今回のライセンス変更で損をするのは現在Enterprise Basic、Goldを利用している
というEditionがあったのですが、新しいStandard Edition($2,000/年)がSilver相当、
Enterprise Edition($5,000/年)がPlatinum相当となっています。
・問い合わせで使えるインシデント数が2 (Silver以上は無制限)
受託システム開発以外でも使いどころは非常に難しいと言えます。
Oracleに好意的に解釈すれば、実用性のないEditionを削除したと解釈してよいと思います。
グレードダウンはありますが、元々旧SilverにおけるEnterprise Monitorは機能制限のため
あまり役に立たなかったものですから、実害はほぼないと考えます。
アクティブサポートが、プレミアサポートと名前を変えて5年間に延長されました。
これは他のOracle製品とサービスレベルを合わせたものと考えられます。
十分長いものとは言えなかったのですが、これが5年になりさらにエクステンドサポートも
有償で提供されるようになったことから、企業向け情報システムでは非常に採用しやすく
なりました。
プレミアサポートの延長に伴いより長期間バグ修正の恩恵を受けることが期待されます。
ユーザ、および5ソケット以上のサーバでEnterprise利用しているユーザのみです。
それ以外のユーザにとってはいいことづくめだと思いますよ。
|
—
|
FROM mytable ORDER BY RAND() LIMIT 10 ) q ORDER BY column
mysql |
“SELECT *
FROM a
ORDER BY
RAND(), column
LIMIT 10
This query attempts to select 10 random records ordered by column.
ORDER BY orders the output lexicographically: that is,
the records are only ordered on the second expression when the values of
the first expression are equal.
However, the results of RAND() are, well, random. It’s infeasible that the values of RAND() will match, so ordering on column after RAND() is quite useless.
To order the randomly sampled records, use this query:
SELECT *
FROM (
SELECT *
FROM mytable
ORDER BY
RAND()
LIMIT 10
) q
ORDER BY
column
”
|
—
|
10 things in MySQL (that won’t work as expected). | EXPLAIN EXTENDED ランダムに10件取得して、それを昇順または降順に取り出したいときのクエリ。 |
四則演算すべての検算を驚くほど加速する理由 読書猿Classic:
すごい, 知識, 覚える, 数学, 四則演算, 検算, 九去法, 十一去法, 合同 |
“「9で割った余り」を求めるのが、各桁の数を足せばいいだけ（しかも9や足して9になるものは省ける）というおかげで大変計算が楽なので、よく使われるのである。9を省けるので九去法という。
他の数で割った余りを使うものでは、11で割るというものもある。
9で割った余りでの検算は、たとえば数字の位置が例えば百の桁と十の桁でひっくり返っていた場合等、検出できないという弱点がある。
十一去法は、九去法では見つけられない、桁の誤りなども見つけられるので併用するとより正確な計算ができる。
さて、どうやって11で割った余りを簡単に計算するかと言えば、右から数えて奇数桁目の数をすべて足し、そこから偶数桁目の数をすべて引くことで求められる。”
|
—
|
「足して9になる数字」が四則演算すべての検算を驚くほど加速する理由 読書猿Classic: between / beyond readers |
アドバンスセグメントは設定することをおすすめします
携帯アクセス分析でよく使うGoogle Analyticsの機能とは | カグア！Google Analytics 活用塾:事例や使い方
アドバンスセグメントは設定することをおすすめします。
tcp segmentation offload: off になっていることを確認します
“ダウンロード方向の通信に遅延が発生する場合があります。
・http,ftp,scp等でのファイルのダウンロード速度が極端に遅い。
・ファイルをダウンロード中に通信が切断される。
・ホームページの静的なコンテンツ表示に異常に時間がかかる。
上記のような現象が確認された場合、設定変更を行うことで回避できる場合があります。
■設定方法
※以下の手順は root として操作する必要があります。
1. ethtool コマンドの実行
ethtool コマンドにて tcp segmentation offload を off に設定します。
# ethtool -K eth0 tso off
上記設定は再起動を行うと無効になります。
2. 設定の確認
下記のコマンドで tcp segmentation offload: off になっていることを確認します。
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
3. 設定ファイルの作成
再起動後も設定を有効にする為に、/etc/udev/rules.d/ 以下に 50-eth_tso.rules
というファイルを作成して、下記の記述をします。
ファイル名：
/etc/udev/rules.d/50-eth_tso.rules
内容：
ACTION==”add”, SUBSYSTEM==”net”, KERNEL==”eth0”, RUN+=”/sbin/ethtool -K eth0 tso off”
|
—
|
[001387]さくらのVPSで「CentOS」を利用していますが、回線速度が遅くアクセスに時間がかかります。 | FAQ Search - さくらインターネット |
InnoDB Pluginの現時点での位置づけはベータです
“●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない
・全文検索 (TritonnやSphinx)
・GIS
●InnoDBの利点(MyISAMの欠点)
▲障害対応系
・クラッシュしても再起動するだけでリカバリができる
・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)
・オンラインバックアップができる
・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い
▲性能系
・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。
・主キー検索が高速 (クラスタ索引のため)
・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い
・インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)
・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い
▲従来は欠点だったが、InnoDB Pluginによって改善されたもの
・グループコミットが無効化されるため同時更新性能が著しく低下していた
・I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった
・CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった
・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)
▲ほか
・InnoDBでは外部キーが使える
●MyISAMの利点
・WHERE条件無しのSELECT COUNT(*)が一瞬で返る
(InnoDBの場合はテーブルをなめる必要がある)
・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い
(InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)
・OSコピーによってテーブルの移動が極めて簡単にできる
・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)
・リードオンリーのテーブルであれば圧縮できる
・ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)
・InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい
▲ソリューションによって緩和できるもの
・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる
・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる
自分は、特別な事情が無い限り、5.1最新版に含まれるInnoDB
Pluginを勧めています(*注)。ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアン
トから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert
BufferのようなI/O最適化の仕組みが無い(詳しくは「Linux-DBシステム構築/運用入門」の9章あたりを参考にしてください)ので、
InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。
ちなみに、マスターをInnoDBにして、スレーブをMyISAMにするのは以前Postしたように特別な注意が必要です。
(*
注追加) InnoDB
Pluginの現時点での位置づけはベータです。ただし、Dynamic/Compressedという特別なテーブルフォーマットを使わない限り、既存の
Pluginを使いつつ、不安定な現象に遭遇したらパラメータを変えて通常のInnoDBに戻すことが可能です。追加インストールやインストールし直し等
が必要ないという手軽さが魅力です。”
|
—
|
Open database life: MyISAMとInnoDBのどちらを使うべきか masapong さんのコメント… |
LVM2 スナップショット＋バックアップ
“
LVM2 スナップショットのスナップショット機能を使った安全なファイルシステムバックアップの方法
スナップショット先のデータは変更されないので安全にバックアップが取得できる。
（ファイルシステムよりシステムよりのLVMの層でオリジナルデータと一緒に変更管理を行っているため、小容量で安全にできる）
○ 検証環境作成# mke2fs -j /dev/testvg/testlv1
# mount /dev/testvg/testlv1 /mnt/test
# echo "aaaaaa" > /mnt/test/aaaaaa
# echo "bbbbbb" > /mnt/test/bbbbbb
○ lvスナップショット
※mysqlなどのデータベースならここでロックをかける。「FLUSH TABLES WITH READ LOCK;」# lvcreate -s -L 32M -n snaptestlv /dev/testvg/testlv1
Logical volume "snaptestlv" created
※mysqlなどのデータベースならここでロックを解除。「UNLOCK TABLES;」
○ スナップショット取得検証
オリジナルデータの変更# echo "cccccc" > /mnt/test/cccccc
# echo "bbbaaa" > /mnt/test/bbbbbb
○ スナップショットのデータの確認# mkdir /mnt/snaptest
# mount /dev/testvg/snaptestlv /mnt/snaptest
# ls /mnt/snaptest
aaaaa bbbbbb lost+found
# cat /mnt/snaptest/bbbbbb
bbbbbb
# cat /proc/mounts
/dev/testvg/testlv1 /mnt/test ext3 rw 0 0
/dev/testvg/snaptestlv /mnt/snaptest ext3 rw 0 0
# umount /mnt/snaptest
# lvm lvdisplay testvg
- Logical volume ---
LV Name /dev/testvg/snaptestlv
VG Name testvg
LV UUID yoJjdE-LVJE-LHN1-zrBu-u8bB-ra3R-ijQn0Z
LV Write Access read/write
LV snapshot status active destination for /dev/testvg/testlv1
LV Status available
# open 0
LV Size 32.00 MB
Current LE 8
COW-table size 32.00 MB
COW-table LE 8
Allocated to snapshot 0.29% ←スナップショット先lvの使用率 オリジナルデータを変更するほど増加
Snapshot chunk size 8.00 KB
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:5
○ スナップショット先のファイルシステムバックアップ# dump 0f /tmp/testlv.dmp /dev/testvg/snaptestlv
# lvm lvremove /dev/testvg/snaptestlv
※スナップショット先のlvを消さないと、いつまでもlvの古いデータコピーを続ける
○ バックアップデータの検証# rm /mnt/test/*
# cd /mnt/test
# restore rf /tmp/testlv.dmp
# ls
aaaaaa bbbbbb lost+found restoresymtable
# cat /mnt/test/bbbbbb
bbbbbb
”
|
—
|
Lightweight Language Tigerに行ってきた(午前中だけ) #lltiger (2010-07-31)
“実際、iPadを入手して「これでもう自宅にパソコンいらないや」などと言っている人をたくさん目にしている。近い将来、家庭や初等学校にはプログラマブルなデバイスが置かれることがなく、プログラムという行為がふたたびごく一部の人たちの特殊な仕事になってしまう可能性はとても高い。アラン・ケイの描いた未来は、Appleによってさらに遠くに押しやられてしまいかねないのだ。”
|
—
|
ただのにっき : Lightweight Language Tigerに行ってきた(午前中だけ) #lltiger (2010-07-31) |
ソフトウェアコードの偉大な書き手は平均的な書き手の一万倍の価値があるのです
おもしろ, プログラミング, 仕事術, 読み物, プログラマ, コード, デバッグ, リファクタリング, エンジニア, ソフトウェア |
“
”
「偉大な旋盤工は、平均的な旋盤工の数倍の給料を支払う価値があります。しかし、ソフトウェアコードの偉大な書き手は平均的な書き手の一万倍の価値があるのです。」ビルゲイツ
|
—
|
