のほほんラボ

IE9のエンコード判定について

IE9はどうも開いたページのエンコードを記憶しているみたい。
それが原因で今回またIEのヘンなバグ（？）につかまったのだが、
開いたページをリロードした場合、リロード後にページの文字コードが変わると、
内容によっては文字化けが発生する（汗

流れとしては、例えば・・・
1.EUCのページを開く（EUCでエンコード）
　↓
2.リロード
　↓
3.WebサーバやCGI等により、文字コードが違う（例えばUTF-8とか）Htmlが生成されレスポンス
　↓
4.文字化け発生
　UTF-8のページなのに、記憶しているEUCでエンコードしてしまう。

といった感じ。

ひとまず、何とかしてブラウザにUTF-8であることを認識させたいため、
UTF-8で生成されるhtmlの中で
metaタグの文字コード指定や
<meta http-equiv="Content-Type" content="text/html; charset="UTF-8">

キャッシュの削除
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">

さらにはCSSでも文字コード指定
@charset "utf-8";

を試してみるも効果なし（汗

とりあえず思いつく中でいけそうだったのは、
レスポンスの際のHTTPヘッダで
Content-Typeでちゃんと文字コードを指定してあげる方法。
こんな感じで　→　Content-Type: text/html; charset=UTF-8

環境の都合でしっかり検証が行えなかったけども、多分この方法でいけると思う。
ただ、ページ毎にHTTPヘッダを切り替えるっていうのは
基本的にサーバ側の環境をいじくったりすることになり、
ちょっと面倒くさい＆リスキー。

なのでこういったケースの場合、長い目で見て安全なのは
やはりhtmlの文字コードを何かしらに統一してしまうのが一番ですね。

ちなみにこの現象、IE8では発生しません（勘弁してほしいパターンですorz）。
IE7とかはどうなんだろう？と気になったりもしましたが、
原因調査だけで疲れてしまって、調べる気力が湧いてこなかったので割愛します（笑

メモリが壊れてハマる

つい最近、Fedora10を使っていたら、
コマンドを打つたびに「Segmentation Fault」と出るようになってしまった（汗
再起動してもしばらくすると出るようになり、
そうやってメッセージが出る度に再起動していたら、
いよいよ起動すらしなくなってしまった。
（具体的にはfsckのエラーチェック＆修復中でコアダンプを出して止まってしまった）

だいたい同じようなタイミングでコアダンプが出たりしたので、
おそらくHDDが壊れたか、システムの大事なファイルが壊れちゃったんだろうなぁと思い、
HDDを新しいものに替えてフォーマット＆再インストールしようとするも、
何故かインストール途中で必ず失敗してしまう・・・。

BIOSの設定を見直したり、何回かフォーマットを試みる中、
ふともしかしてメモリが壊れていたりして？と思い、
memtest86+でメモリテストを実行したら見事にビンゴ。
かなりたくさんメモリエラーが見つかり、豪快に壊れていましたorz
不幸中の幸いで、1G×2枚のうちの1枚だけにメモリエラーが見つかったため、
正常なメモリだけを残して再インストールを実施したところ、見事成功しました。

RAMなんてそうそう壊れるものじゃないと思いますし、
原因がわかったときもまさか！と思いました。
OSインストール時orプログラム実行時等でおかしな挙動が起きた時は、
プログラムの競合やHDDのトラブルを疑うのも必要ですが、
メモリのエラーチェックもしっかりチェック候補としておくべきですね。
OSのインストール時にもしっかりメモリのエラーチェックを行っておきたいところ。

Linuxのサスペンド

echo -n mem > /sys/power/state
を実行すればOK。

使っているカーネルとPCでこのコマンドによるサスペンドが行えるかは
cat /sys/power/state
を実行し、
mem
とレスポンスがあれば問題ないとのこと。

詳しくは以下ののページが参考になる。
LinuxノートPCのサスペンドとハイバネーション
→http://sourceforge.jp/magazine/06/06/08/0250241

Apacheのチューニング

MySQLの設定で最大同時接続数を触るおり、
apacheの設定も確認する機会があったので
気になったチューニング箇所をメモメモ。

設定ファイルは/etc/httpd/conf/httpd.conf

・MaxClietns
apacheでの最大同時接続数。
値が大きければ大きいほど、たくさんのコネクションを受け付けられますが、
その分負荷がかかるので注意とのこと。
この値をなるたけしっかりと決めたい場合は、
この数分だけコネクションを張った際のメモリ残量と
httpdの1プロセスあたりのメモリ消費量から決定するという手があるそう。
詳しい計算方法は以下のページが参考になります。

【LAMPサイトのチューニング入門(1) -WWWサーバ編】
http://www.emboma.jp/column/archives/2008/05/lamp1-www.html

ちなみにpreforkとworkerの両方にMaxClientsがありますが、
PHPを使用する場合はpreforkのMaxClientsを修正します。
（PHPはマルチスレッド未対応のためpreforkでサーバを動かすため。）


・MaxRequestsPerChild
一つのプロセスが受け付けることのできる最大リクエスト数。
受け付けたリクエスト数がこの値を超えると、そのプロセスは再起動する。
cgiでメモリを動的に確保しているプログラムで、
開放漏れ等が原因でリクエスト毎にメモリ消費量が増えてしまっているという場合、
このパラメータの値を設定していると再起動でメモリが解放されるため、
いつの間にかhttpdプロセスのメモリ消費量が凄まじいことに・・・なんてことには
なりにくくなるそう。
（ただこういうケースだと、そもそもcgiの処理を見直したほうがいい気もしますが（汗））
ただし、静的なコンテンツのみの場合は上記のような問題が起こりえない上に
設定値によっては頻繁に再起動が発生して負荷がかかってしまうので
無制限（0）に設定するとよいそう。


・KeepAlive
設定をOnにすると、
一つのブラウザからのリクエストを一つのTCP接続で処理することができる。
Offにした場合は、逆にそれぞれのリクエスト（複数の画像読み込みとか）に対し
TCPコネクションをはることになる。
よって、html(複数の画像やcssを含む）だけのサーバの場合だとOn、
phpの処理のみ(html生成だとか)の場合はOff
にするのが効率がいいみたい。
ちなみに、phpでhtml生成して
そのあと同一サーバに画像読み込みのリクエストが来て・・・
というよくあるケースの場合、実は設定が結構シビアになるのだそうで（汗
詳しくは以下のページが参考になります。

keep-aliveのことをちゃんと考える
http://www.inter-office.co.jp/contents/72/


・MaxKeepAliveRequests
KeepAliveがOnのとき、
一つのTCP接続開始から切断するまでに受け付けるリクエストの数。
各ページを表示させる際に発生するリクエスト数の平均値より、
少し大きい値を設定してあげるとよいそう。


・KeepAliveTimeout
KeepAliveがOnのとき、
接続しているセッションからのリクエストが来なくなってから切断するまでの待ち時間。
画像やcssだと1秒未満で落とせてしまうため、設定値は数秒でよいそう。


今後も内容がわかったパラメータについてメモを追記していくかも。

MySQLのチューニング

LAMPのサーバでアクセス数が増えたサーバで以下のログが一杯出ている時があった。

failed in database connection :MySQL Connect Error:1040:Too many connections ～

原因としては、DBに同時接続できるコネクション数が
MySQLで設定している最大数を超えたために出ていたエラーでした。
当然、この状態だと新たにDBに接続しようとしているクライアント（コネクション）は
DBに接続できないためPHP等でエラーになっちゃいます。

とりあえず最大同時接続数は増やした方がいいのかな？とか考えながら
チューニングした方がよさそうなMySQLのパラメータについて
あれこれ調べたところ、とりあえず以下のパラメータについて変更を加えることに。

・max_connections
最大同時接続数。
Apacheの最大同時接続数分(MaxClients)は確保できたほうがいいそう。
（max_connections以上のhttpリクエストが来た場合
DB処理ができないプロセスが発生するため）
ただ、接続数が増える分負荷がかかるので注意。

・thread_cache_size
スレッドキャッシュの数。
通常、MySQLのスレッドはクライアント接続ごとに生成・破棄されるのだが、
このパラメータを設定すると、設定した値の数だけスレッドが破棄されず、
他のクライアント接続で再利用することができ、
CPUへの負荷を減らすことができるそう。

・wait_timeout
DBへのコネクションのタイムアウト時間。
DB接続→スレッド生成→待機状態になってから
X秒経過したら接続を切るという数値とのこと。
デフォルト値は8時間だが、
これだとコネクションが溜まっていく一方で上記のエラーの原因になる。
長時間の持続的なDBへのアクセスが行われない限り、
数十秒単位で設定して問題ないと考えられる。

というわけで、今回はとりあえず以下のような感じで設定してみました。
設定値は・・・
-------------------------------------------
max_connections=256
thread_cache_size=70
wait_timeout=10
-------------------------------------------

設定方法は以下の通り。
・/etc/my.cnfの修正　以下の記述を追記
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
・・・
max_connections=256 ← 追加
thread_cache_size=70 ← 追加
wait_timeout=60 ← 追加

・mysqlにログイン後、以下のコマンドを実行
set global max_connections=256;
set global thread_cache_size=70;
set global wait_timeout=60;

設定後のパラメータ変更確認は
show global variables;
で確認できる。

接続数の確認は以下のコマンド
mysqladmin -u root -p extended-status --password=freespot | egrep '(Max|Threads_)'
| Max_used_connections | 54 | →これまでに記録された同時接続数の最大値
| Threads_cached | 48 | →キャッシュされているスレッド数
| Threads_connected | 6 | →現在開いている接続の数
| Threads_created | 57 | →接続を処理するために生成されたスレッド数
| Threads_running | 1 | →スリープ状態になっていないスレッド数


上記の設定でとりあえずMySQLのエラーは出なくなりました。
MySQLの設定は結構Apacheの設定と話が絡んでいたりするので
またApacheの設定についても追々メモしたいところ。

参考URL：
http://www.sssg.org/blogs/naoya/archives/1160
http://thinkit.co.jp/free/article/0707/2/2/