徒然なるままにBlog

PostgreSQL パフォーマンスチューニングまとめ

2007-07-23T09:00:29+09:00

PostgreSQLをチューニングする機会があったので
その時に調べたチューニング項目を備忘録として残しておきます。
バージョンの違いやサーバの規模などによっても
効果は変わってくると思うのであくまで参考程度のものですが。

・shared_buffers
　7系では8000〜10000程度まで引き上げる
　8系では150000程度まで引き上げることが可能、100000程度が性能のピーク
　これに多く割り当てるよりOSのバッファ領域として使う方が性能が向上する
　テーブルサイズを割り出して設定するのがベスト
　簡単に設定するなら搭載メモリ量の1/4、搭載メモリが多ければ1/2ぐらいでも可
・max_connections
　7系では256程度、8系では1000程度が性能のピーク
・work_mem(sort_mem)
　適切なサイズに調整する、2048〜4096程度
　プロセス毎に領域が割り当てられるので多すぎるとスワップする可能性も
　ソートメモリはORDER BYだけではなくMerge Join、CREATE INDEX時でも使用される
・deadlock_timeout
　長めに設定する
　1000ms×同時セッション数が理想
・effective_cache_size
　数GBメモリ積んだマシンなら総メモリの1/4〜1/2を設定
・wal_buffers
　トランザクションが多い、大きい場合に多く取っておくと書き込み効率が良くなる。32〜64程度。
・commit_delay
　同時トランザクション数が多い場合、0以上を設定すると書き込み効率が上がる
・random_page_cost
　余程巨大なテーブルが無い限り数GBのメモリのマシンなら2〜3が適当
・max_fsm_pages
　小さすぎるとクラスタ容量が増えすぎる、大きすぎると検索オーバーヘッドが大きくなる、vacuum -vの情報を見て調節
・bgwriter_maxpages
　参照系DBなら値を小さく、トランザクションが多いDBなら大きく設定する
・checkpoint_segments
　大きく設定するとハードディスクへの書き込み頻度が減り性能が向上する

・VACUUM FULLをしてもインデックスの領域は切り詰められないのでREINDEXを行い無駄な領域を削除する
・複数のハードディスク上のテーブルスペースにテーブルを作ることによりIOが分散し効率が良くなる
・walログも別ハードディスクに移すと結構IO効率が上がる
・fstabのマウント情報にnoatimeを指定し、atimeの更新を抑えると若干性能アップ

Macの小技: Macをリモコンでスリープさせる方法

2007-07-18T00:03:37+09:00

先月、家のMacをPowerMac G4からMacBook Proに買い換えました。
WWDCで何か新製品が発表されていたらきっとそれを買っていたに違いない…。
本当に今年のWWDCは近年希に見るショボさでガッカリ…。

そんな事はどうでもいいんですが、MacBook Proを買っても今まで使っていた旧シネマを
引き続き使いたかったのでDVI-ADCアダプタを経由させて繋ぎました。
で、今まではシネマの電源ボタンでMacの電源をon/off出来ていたんですが、
MacBookやMacBook Proでは出来ないことが発覚。
閉じた状態のMacBook Proにシネマ繋げて使いたいので
電源を外部から操作できないと辛い！面倒くさい！
仕方がないので電源を落とす代わりにスリープさせて使ってるんですが、
超簡単にスリープさせる方法を見つけたので紹介します。

実は最近Mac(Mac Proを除く)を買うと付属しているリモコン(Apple Remote)の
再生/停止ボタンを長押しするとMacをスリープさせる事ができます。
またスリープ時にリモコンのMenuボタンなどを押せば復帰させる事も可能です。

この方法を知ってからはこれでしかスリープ/復帰をさせていませんが、かなり便利に感じます。
いちいち確認のダイアログも出ないし、席に着く前に復帰させられるし重宝しています。
寝ながらFront RowでDVDを見たりして眠くなってきたらスリープ…とかも出来ます。
ちなみにスリープ前のスクリーンに現れるアニメ？がちょっとかわいいので必見です。

PHPベンチマーク: Zend Framework vs Symfony vs CakePHP vs CodeIgniter vs PHP on TRAX

2007-07-13T08:40:12+09:00

先日、Zend Frameworkが正式に1.0.0としてリリースされました。
公式だし今後使っていこうかなと思ったんですが、最近人気のある他のPHPフレームワークと比べて
パフォーマンスの面でどう違うか気になったので簡単なベンチマークをとって比較してみました。

今回使用したフレームワークはZend Framework、Symfony、CakePHP、CodeIgniter、PHP on TRAXの5つです。
各フレームワークで行った処理はコントローラを呼び出しビューに遷移させて
"Hello World!"を表示させるだけのかなりシンプルな内容です。
DBへの接続やモデルの作成は行わず、自動レイアウト機能があるものはオフにするか全て削除しています。
使用したソースはこちらからダウンロードできます。

ベンチマークを行った環境はCeleron 1.7GHz、メモリ1GBのLinux上でApache2.0系、PHP-5.2.3を使用し、
各フレームワークのバージョンは一般配布されているstable系の最新版を使用しました。
(Zend Framework 1.0.0、Symfony 1.0.5、CakePHP 1.1.16.5421、CodeIgniter 1.5.3、PHP on TRAX 0.14.0)
ベンチマークの方法はab(Apache付属のベンチツール)を-c 100 -n 1000のオプションで
ローカルホストから呼び出す形で行いました。
それを各々5回ずつ行い、そのRequsts per secondの平均を結果として出しています。

以下がベンチマーク結果です。

Zend Framework	16.7 Request/Sec	2.8 %
Symfony	10.7 Request/Sec	1.8 %
CakePHP	12.8 Request/Sec	2.2 %
CodeIgniter	33.2 Request/Sec	5.7 %
PHP on TRAX	7.8 Request/Sec	1.3 %
(参考)フレームワーク無し	586.1 Request/Sec	100.0 %	-

またAPCを有効にした状態でもベンチマークを取ったのでそれも載せておきます。
本当はeAcceleratorを使いたかったのですが、有効にするとZend、Symfony、TRAXで
エラーが発生したため今回は使用しませんでした。

Zend Framework	65.1 Request/Sec	9.5 %
Symfony	45.9 Request/Sec	6.7 %
CakePHP	63.9 Request/Sec	9.3 %
CodeIgniter	133.7 Request/Sec	19.5 %
PHP on TRAX	54.2 Request/Sec	7.9 %
(参考)フレームワーク無し	684.3 Request/Sec	100.0 %	-

結果はAPCの有無に関わらずCodeIgniterがぶっちぎりの優勝で次いでZendという事になりました。
SymfonyとCakePHPはAPC無しでは差は小さいですが、APCを有効にするとCakePHPが大きく勝るようです。
TRAXはAPC無しではかなり遅いですが、有効にすると劇的にパフォーマンスが向上しました。

ついでにXdebugを使い各フレームワークの関数コールをトレースしステップ数を計ってみました。
以下がその結果です。

Zend Framework	446 Steps
Symfony	934 Steps
CakePHP	854 Steps
CodeIgniter	310 Steps
PHP on TRAX	510 Steps

やはりCodeIgniterが一番ステップ数が少ないという結果になりました。
そのおかげで高いスループットを実現出来ているんでしょうね。

ベンチマークを行った結果、残念ながらZendが一番という事にはなりませんでしたが、
悪い結果ではなかったので使ってみる価値はあるんじゃないかなと思います。
しかも日本語ドキュメントがかなり完成されているのでその点も魅力的なのではないでしょうか。

注) 今回行ったベンチマークはごく単純なものなので
　実際のシステムで必ずしもこの結果の通りになるとは限りません。
　またパフォーマンスが高いというだけで有用なフレームワークというわけでもありません。
　あくまで参考としてお考え下さい。

追記) CakePHPのソースについてモデル生成が有効になっていたため、
　　ソースを修正しベンチマークを再度行って結果を修正しました。

Macでバックアップ: ChronoSyncを使う

2007-05-15T22:42:16+09:00

あー超久しぶりの更新。
これ確か前にも言ったな…。

さて、今自宅で使ってるG4 MDDは使い始めてかれこれ4年が経ちます。
OS X専用モデルとして割と安く売られてたのが最初の出会いで…てそんなことはどうでもいいんですけど。
使い続けてるとハードディスクの容量が足りなくなり内蔵ドライブの増設を繰り返して、
今はオリジナルのハードディスクは姿を消し3台のハードディスクがマウントされている状態です。
デジカメで撮った写真をiPhotoに、手持ちのCDをiTunesになどしてるとドンドン容量が減っていきますよね。
気付くと他のファイルなども合わせると200GBを超える使用量に…。
残り容量はまだあるのでそれは大丈夫ですが、万一ハードディスクが故障して
このデータが全部飛んだら…。ガクガクブルブル(AA略…
バックアップなんて何年か前にCD-RにiPhotoの画像を移したきりでそれ以来何もしていません。
その時も最初の1枚を焼いただけで面倒臭くなり止めてしまったし…。

で、さんざん悩んだあげくI-O DATAのHDC-U400というUSB外付けのハードディスクを買うことにしました。
最初はハードウェアRAID付きの2台ハードディスクを搭載したやつが欲しかったんですが
OS XだけでもRAID出来るしな…とか思い始めたんですがやっぱ何でもいいやと思ったのが購入の決め手です。

使い心地?はまぁ普通でそれなりに静かだし満足しています。
バックアップは最初iBackupというフリーウェアを使うつもりだったんですけど、
管理機能がシンプルすぎて本気でバックアップするには使用に耐えないこともあり今回は見送りました。
アプリケーションやシステムの項目毎でバックアップ出来たりするんで便利なのは便利なんですが。

他のバックアップソフトウェアを探したところChronoSyncというのが評判が良かったので試しに使ってみました。
これはかなり好感触！いい感じ！日本語対応されてるし！シェアウェアだけど！
望んでいたバックアップはUsers以下を丸ごとコピーできて、その後のバックアップは増分バックアップ
という形だったのでまさにズバリこれという感じでした。
しかも本体のハードディスクから削除されたファイルや更新されたファイルはアーカイブとして
別のディレクトリに自動で保存してくれたり一定期間経過後に削除してくれたりしてとても親切！
バックアップのスケジュールも細かく設定できてスケジュールによりバックアップが始まっても
アクティブにならないので何か作業中であってもフォーカスが奪われないのは嬉しいところです。
初回のバックアップは完全バックアップなのでやっぱり時間は掛かりましたが、
それ以降は増分だけが対象なので3分もあればバックアップが完了してしいまいます。
今はスケジュールで毎日1回バックアップを行うようにしていますが全くストレスにならないので助かっています。
これでいつG4が壊れて新しいMacがやってきても大丈夫、大丈夫！？

アーカイブ機能が親切過ぎてマジ泣ける

Amazon

I-O DATA USB 2.0/1.1対応
外付型ハードディスク 1TB HDC-EU1.0

Apacheチューニング: ロギングを高速化する

2007-01-17T23:35:49+09:00

あまり知られていません(と思われる)がApache2(2.0.41以降)にはアクセスログの書き出しをメモリにバッファリングし高速化させるという機能があります。
今回はその機能を有効にするとどれぐらい速くなるのか調べてみました。

設定方法はhttpd.confに

BufferedLogs On

と追加するだけでログのバッファリングが有効になります。

以下ベンチマークを取った結果です。

バッファリング無効	984 Request/Sec
バッファリング有効	1033 Request/Sec
(参考)ロギング無し	1055 Request/Sec

※小さなhtmlファイルに対してab -c 100 -n 1000を何度か繰り返した結果の平均です。

体感では違いを感じられないとは思いますがベンチを取るとおよそ5%程Request per secondの値が上がっていました。
静的なファイルが中心のリクエスト数の多いWebサーバであればこれを有効にすることによって多少は速くなるのではないでしょうか。
1行追加するだけで(少し)パフォーマンスアップできるのでオススメです。

追記：
BufferedLogsディレクティブは未だにexperimentalなままなので使用には注意が必要です。

memcachedを使ったPHPのシングルトン実装

2007-01-12T05:42:44+09:00

PHPのクラスに備わっているstaticはJava(Servlet)のそれとは違いHTTPのリクエストが完了すると破棄されてしまいます。
そのためstaticフィールドを使ったシングルトンの実装を行ったとしてもリクエストがある度にインスタンスが生成され独立したプロセスから同一のインスタンスにアクセスすることは不可能です。

そこで今回memcachedを利用しPHPの各プロセスから同一のインスタンスを参照できるようにしてみたいと思います。
といってもシリアライズさせているので厳密には別のインスタンスになりますが…。

ちなみにmemcachedとはオブジェクトをメモリにキャッシュさせるPHPとは独立したサーバプログラムです。
利用できる言語はPHPだけに限らずPerl、Ruby、Java、Pythonなどにも対応しています。
インストールは./configure && make && make installで簡単ですが、あらかじめlibeventのインストールしておく必要があります。

次にPHPからmemcachedに接続するためのAPIを持つPECL拡張モジュールをインストールします。

# pear install http://pecl.php.net/get/memcache-2.1.0.tgz

それからphp.iniにエクステンションの記述を追加。

extension="(memcahce.soまでのパス)/memcache.so"

これで準備完了です。

今回シングルトンとして作るクラスは設定情報などを保持するものと想定して作りました。
以下がそのクラスのソースです。

class Repository
{
        private static $memcache;

        private $map;
        private $updated;

        public static function getInstance()
        {
                self::$memcache=new Memcache();
                self::$memcache->connect("localhost",11211);

                $repository=self::$memcache->get("repository");
                if(!$repository)
                        $repository=new Repository();

                return $repository;
        }

        private function __construct()
        {
                $this->map=array();
                $this->updated=false;
        }

        public function set($key,$val)
        {
                $this->map[$key]=$val;
                $this->updated=true;
        }

        public function get($key)
        {
                return $this->map[$key];
        }

        public function __destruct()
        {
                if($this->updated)
                {
                        $this->updated=false;
                        self::$memcache->set("repository",$this);
                }
                self::$memcache->close();
        }
}

説明するほどのものでもないですが。まずgetInstance()内でMemcacheオブジェクトを通じてmemcachedに接続し、"repository"というキーでオブジェクトが存在しているか調べます。
存在していればmemcachedから取得したオブジェクトをそのまま返し、存在していなければ新たにインスタンスを生成して返します。
これで永続化されたオブジェクトを取得することが出来るのですが、その後オブジェクトの状態を変更してもJavaのように参照を保持しているわけではないので永続化されたオブジェクトは更新されません。
そこで__destructを使いオブジェクトが破棄されるタイミングでもし更新されていればmemcachedにオブジェクトを書き出す処理を行っています。

$repository=Repository::getInstance();
$repository->set("test",123);

上ような処理だけでリクエストが終了しても状態は保たれたままその後他のプロセスも同じオブジェクトを参照することが出来ます。
しかもネットワーク越しに同一のオブジェクトを共有できるためWebサーバに負荷が増えてきても容易にスケール出来るのはかなりのメリットではないでしょうか。
ただし今回の実装は排他制御を行っていないのでそのままでは使えませんが…。

参考までに他のシングルトンの実装としてオブジェクトをシリアライズしてファイルに保存するパターンとデータベース(MySQL)に保存するパターンを作りベンチマークを取ってみました。

	requests/sec	リモート接続
memcached	334	○
ファイル	439	×
DB(MySQL)	277	○

※ab -c 100 -n 1000の結果です。
※MySQLはHEAPテーブルを使用しています。

これを見るとローカルからだけの参照ならファイルにシリアライズさせるパターンが一番速いですが、リモートからの参照となるとMySQLよりmemcachedに保存した方が速いようです。
作成したファイル版とデータベース版のソースも一応置いておきます。(→ファイル版、→データベース版)

パフォーマンスは悪くないのでオブジェクトに限らず画像やテキストなどキャッシュさせれば負荷を軽減させるのに役立つのではないでしょうか。slashdotやmixiも使っているようですし。

高鷲スノーパーク

2006-12-23T21:01:52+09:00

スノボ行って来ました。
天候はチラチラ雪が舞ったり晴れたりで良かったんですが、ゲレンデは所々アイスバーンになっていてかなりガリガリいっていました。
今年は暖冬なので仕方ないんですかねぇ。

お風呂テレビ買ったどー

2006-12-22T03:25:14+09:00

僕は男の割に風呂が長い方で湯船に入らないのに40分ぐらい時間が掛かったりします。
その間もちろん髪を洗ったり体を洗ったりしてるんですが、特に考え事の無い時はとても暇なんですね。
以前から風呂にテレビついてればなーと思い各社から出ているお風呂テレビの購入を検討していたんですが、ほとんどのお風呂テレビは普通のアンテナ付きのもので受信状態が良くないと見られないという欠点があります。なので却下です。
カシオからチューナーを室内に設置して無線で映像と音声を飛ばすテレビもあるんですがちょっと高い…。
そう思っているとプリンストンからカシオのと同じ形式でそれより安いお風呂テレビが発売されているではないですか！
接続も簡単で室内に設置する無線チューナーにアンテナケーブルをつなぐだけでOKで無線で通信を行うため電波が入りが悪いところでも安定してテレビが見れます。

で、早速買ってきて使ってみました。イイ！映像もキレイだしこれは素晴らしい！お風呂タイムがテレビタイムに！
今まで風呂に入るために見逃していた番組も確実に見れます。プリンストン始まったな。
ただシャワーを出している間は音声が聞こえにくいので聞き取れるぐらいに音量を大きくするとうるさすぎて屋外に音がもれているかも知れません。
でもまあ大した問題ではないのでかなり満足しています。
デザインもシンプルだしオススメです。

ロストプラネットー、は全然関係ないです。

Amazon

Princeton フリーロケーション
防水テレビ PTV-WWTV7

FONルーター設置

2006-12-19T00:18:24+09:00

無線LAN共有プロジェクトであるFONの専用ルーターが届きました。
12月5日に申し込んだのでタダです、タダ。でも送料と代引き手数料で945円掛かった…。
さっそくベースステーションに有線接続し電源を入れるとワイヤレスネットワーク一覧FON_APとMyPlaceの2つのネットワークが見つかりました。すごい簡単。
FON_APは外に公開するパブリックなESSIDでMyPlaceはオーナーのみが接続できるプライベートなESSIDという棲み分けがされているようです。
FON_APにネットワークを切り替えて適当なURLを開こうとするとFONのポータルが表示されました。
どうやらここでFONで登録したIDとパスワードを入れて認証が通ればその後は自由にそのネットワークを使えるようになるという仕組みらしい、なるほど。
MyPlaceはネットワークを切り替えるだけで使えるようになるけど、ルーター裏に記載されているWEPキーが無いと接続できません。
無線LANのアクセスポイントを持ってない人はこれを買えば安価に環境が作れるのでお得ですね。同程度の機能を持ったものを1,980円では買えないです、さすがに。

で、ここに書いてあるとおりゴニョゴニョすると…おぉSSHでログイン出来た！
へーOpenWrtなんだ…初めて触ったよー。
こんな小さな箱で動いているLinuxを見て少し感動してしまった。

cpuinfoはこんな感じです。

system type             : Atheros AR531X_COBRA
processor               : 0
cpu model               : MIPS 4KEc V6.4
BogoMIPS                : 183.50
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

んーでもまだ誰もAPを使ってくれた履歴がない…。
ユーザーが増えたらこんなとこに設置されたAPでも使ってくれるのかしらん。

とにかく小さいです

Pager Pluginを使う

2006-09-28T22:23:57+09:00

以前からblojsomを使っていて、エントリ一覧で「次のページ」や
「前のページ」を見るための機能がなぜないんだろうと思っていました。
今は10件ずつの表示にしていますが10件表示されてそれで終わり。
以前のエントリを見るにはカレンダーをぽちぽちクリックして見ていくしかないんですね。
件数制限なしで表示するようにすれば当然以前のエントリが見られますが
全てのエントリが表示されてしまい、どえらく重くなるし…。

blojsom標準の機能に「次のページ」を出せる機能はないようなので
これはプラグイン作るしかないかーと思って何か参考になるプラグインがないかと
blojsom公式のプラグイン一覧を見ていると既にPager Pluginというそのものズバリのプラグインがあるし！
作る前にここ見ておいて良かったー…。

使用するにはまずここからpagerplugin-0.2.jarを落としてきて/WEB-INF/libに入れます。

次に/WEB-INF/plugin.propertiesへ

pager=com.mbledug.blojsom.plugin.pager.FilterPlugin

と設定を追加し
/WEB-INF/(ユーザーID)/plugin.propertiesに

html.blojsom-plugin-chain=..., calendar, ..., pager, ..., limiter, ...

とpagerを書き加えます。
ここでポイントなのが既にcalendarとlimiterがチェインされていればその間に書き加えた方がよい、
ということだそうです。

で次に/WEB-INF/(ユーザーID)/pager.propertiesというファイルを作りその中に

page-size=10

とだけ書いておきます。
ここでの右辺数値は1ページに表示させる上限の数になっています。
この場合だと10件まで表示するようになります。

最後に/WEB-INF/web.xmlへ

<init-param>
        <param-name>plugin-pager</param-name>
        <param-value>pager.properties</param-value>
</init-param>

と先ほど作った設定ファイルをプラグインが読み込むようにしてあげれば準備完了です。
反映させるにはコンテナを再起動する必要があります。

あとは「次のページ」のナビげージョンを表示させたいテンプレートの位置に

#parse("pager.vm")

と書いて、jarファイル内にあるpager.vmを/WEB-INF/(ユーザーID)/templatesに置けば終わりです。
pager.vmの中身はそんなに難しくない表示を変えることも簡単にできると思います。

使ってみた感想は、そうそうこれが欲しかったのよ！コレコレ！
という感じでとても重宝しています。次のページktkr！
でもこれってblojsomがデフォルトで持っているべき機能なんじゃないの…？