とあるシステムのセッションディレクトリを覗いてみたらミリオン単位のファイルが詰まっていることが解って、I/O重いの当たり前じゃねーか…！（普通は1ディレクトリ1000ファイルまでに抑えるべき）となったので改善を試みました。
具体的にはディレクトリを階層化します。
/path/to/session/sess_hogehogehoge/path/to/session/0/1/2/sess_hogehogehogeMySQLのチューニングに当たってスロークエリログを書き出すことは良くあります。設定によっては放っておくと膨大なログになってしまうため、適度なタイミング（日毎とか週毎とか）でログローテーションしてやります。logrotateを使うのが常套手段。 スロークエリログの解析にはmysqldumpslowを使用します。mysqldumpslowを使用するとログを解析した上で、オプションに従って並べ替えて出力してくれます。ログ全体のまとめになるので、定期的これを実行すれば、どれくらいの頻度でスロークエリが発生しているかを定量的に計ることが出来ます。 …というわけで、この2つを組み合わせてみました。
/var/log/mysql-slow.log {
# create 600 mysql mysql
notifempty
daily
rotate 5
missingok
prerotate
EXT=`/bin/date +%Y%m%d`
/usr/bin/mysqldumpslow -s t /var/log/mysql-slow.log > /var/log/mysql/mysql-slow.${EXT}.log
endscript
postrotate
# just if mysqld is really running
if test -x /usr/bin/mysqladmin && \
/usr/bin/mysqladmin ping &>/dev/null
then
/usr/bin/mysqladmin flush-logs
fi
endscript
}
MySQLの再起動をするときはいつもcondrestartするだけだったのだけど、ふと気になって/etc/init.d/mysqldでコマンドを表示してみたら見たこと無いのがいくつか混じってたのでメモっておくテスト。基本的には、/etc/init.d/mysqldを読んだだけ。
以前、仕事で専用サーバを使っているときに、もの凄く嵌った経験があって。 今考えると全然大した作業ではないのだけど、僕に知識が全くなかったのでサーバ管理会社に作業代行を依頼。 ところが向こうの担当者も技術が不足していて何度やっても設定が上手く行かず。 担当者の言い分は、「せっかく変更したファイルをこちらが巻き戻している」だったけど。 まぁそんなわけはないので、作業代行の契約を切って同僚にお願いして設定してもらったらあっさり。 ホッとする反面、僕の頭の中は「あれ…？？？」 そんなトラウマ。 そんな経緯があってSSLというと設定が難しいものと考えてしまっていたのだけど、 あれから6年以上が経ちサーバにも少しは触るようになったら、作業がとてもすっきりした。 ちょうど証明書の更新タイミングで、確認しながらSSL証明書の更新と新規インストールを行ったのでメモを。
とある業務で使用しているドメインをお名前.comで管理しています。 ドメイン取るなら お名前.com – ドメイン取得 年間99円～ 競合他社に比べると柔軟な設定が出来るのでオススメなのですが、本音を言うとそこまで使いこなせてるわけでも無し値段が安いわけでもないから優先的に選択する所じゃないけど、移管するのは面倒だしそこまで面倒かけるほど価格の差もないからまぁ別にいいやという理由で利用しています。なんかごめん。 んで、お名前.comでドメインを取得するとお名前.comのDNSサービスが無料できます。最近、クッキーフリー用にドメインを取得したので試しに使ってみたんですけど…なんか不安定なんですよね。最低限設定して、浸透のための時間を十分取ってから（2日程度）ファイルにアクセスしてみると、結構な頻度で繋がらない。1回繋がるとキャッシュされるのか5分くらいスムースに表示されるようにはなるのだけど…なんだこれ。 データセンターに設置されているDNSサーバを利用しているドメインの方はいついかなる時も問題なく表示できているので、サーバとかPCとかの設定の問題ではないと思うんだけど…お名前.comのDNSサービスの問題なのかな。わからん。 まぁこのドメインは将来的にはAWSにて運用予定で、DNSもAmazon Route53を利用するつもりでいるので別に良いんだけど、なんだかちょっと不思議。このサービスを利用してる人がこれで良しとするわけ無いから、設定の仕方に何か問題あるんだと思うんだけどなぁ。
VirtualBoxを3から4に上げて、ディスクを読み込んだら次のエラーが出て立ち上がらない。
Kernel panic – not syncing: Attempted to kill init!仮想ディスクのデータが勝手に壊れるとかあるのか…復旧はどうすれば…と悩んだけど、 ここ読んだら解った。 Kernel panic booting CentOS 5 image in VirtualBox – Super User 簡単に言うと、IDEで作成したディスクをSATAに追加してるからだよ、という話。 VirtualBox4ではSATAがデフォルトなんで、それをよく確認せずに追加してしまってた。 というわけで、ストレージの設定でSATAコントローラから起動ディスクを削除し、 IDEコントローラに追加したら無事解決した。良かった良かった。
※かなり適当な知識で書いてます。基本的に作業メモ的な。
ニコニコ動画に関連して、ちょっとアグレッシブなデータ蓄積を行っているのだけど、計算したらば色々と無理が。
始めはバッチ処理の時間のことを気にしていて、だいたい1年くらいで限界が来るなぁなんて思っていたのだけど、
よくよく考えたらそれよりも先にストレージの問題が来るなぁと言うことに気付いた。
MySQLのレコード数50万件でだいたい100MBになる案件なので、
さくらのVPS512（ストレージ20GB）では最大で5,000万件くらいまでしか保管できない。
日が経つ毎に1日の増分が大きくなるのだけど、仮に1日100万件だと1ヶ月でストレージ終了。
元々さくらはストレージが小さめではあるんだけど、まーそう言う問題じゃなく、
そもそもこの企画自体が無理だったんだなぁ。
とはいえ諦めてしまうのも惜しいので、なんとか実現できる方法はないかなーと思いつつ、
クラウドか…ということでAmazonがやっているRDBサービス、「Amazon RDS」を検討してみた。
開発の終了が発表されても依然として使用しているフレッシュリーダー。 いずれGoogleリーダーにでも引っ越そうかなと考えてはいるのですけど、 設定の引き継ぎが面倒なのでなんとなく躊躇。 VPSへの引っ越しもタイミングだったかなとは思ったんですが、まぁ面倒だったので今回も結局継続使用します。 フレッシュリーダー自体は丸ごとrsyncでコピーすればOK。 データもライブラリもそれで問題ない。 （環境がLinux→Windowsとか、PHP4→PHP5とかでない限り） 以下、ハマリどころを中心にそれ以降の設定について。
いくつかあるブログ/サービスを1つのサーバにいくつ入れるか？で悩んでいたのだけど見当が付かないので、 とりあえず軽そうなものから順番に入れていき、都度、Load Averageのデータを取っていくことに。 割り切ってブログ/サービスごとにサーバを分ければ楽になるけどその分コストが嵩むことになるし、 全部を1つにまとめられれば便利だけどそれで負荷が掛かりすぎたら意味無いし。 というわけでサーバ監視システムを導入。 もっと多機能なものは他にもいくつかあったけど、入れやすさと軽さでMRTGを入れてみた。 参考にしたのはこちら。 MRTG で Load Average をグラフ化する まぁ大体、書いてあるとおりにやればOK。
んー…大体0.1前後か。まだ全然余裕あるなぁ。
（負荷が掛かっている部分は、Apacheの設定をあれこれいじってたところ）
メインブログと、それ以外で分けたら十分かも知れない。
というかそもそもブログって負荷小さいんだよな、きっと。