月曜日, 23 7 月 2007

PostgreSQL パフォーマンスチューニングまとめ この記事(PostgreSQL パフォーマンスチューニングまとめ)を「はてなブックマーク」に追加 この記事をクリップ! この記事(PostgreSQL パフォーマンスチューニングまとめ)を「del.icio.us」に追加

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の更新を抑えると若干性能アップ
Posted by tsujitako at 9:00 午前 in Linux/

水曜日, 18 7 月 2007

Macの小技: Macをリモコンでスリープさせる方法 この記事(Macの小技: Macをリモコンでスリープさせる方法)を「はてなブックマーク」に追加 この記事をクリップ! この記事(Macの小技: Macをリモコンでスリープさせる方法)を「del.icio.us」に追加

先月、家の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を見たりして眠くなってきたらスリープ…とかも出来ます。
ちなみにスリープ前のスクリーンに現れるアニメ?がちょっとかわいいので必見です。
Posted by tsujitako at 12:03 午前 in Mac/

金曜日, 13 7 月 2007

PHPベンチマーク: Zend Framework vs Symfony vs CakePHP vs CodeIgniter vs PHP on TRAX この記事(PHPベンチマーク: Zend Framework vs Symfony vs CakePHP vs CodeIgniter vs PHP on TRAX)を「はてなブックマーク」に追加 この記事をクリップ! この記事(PHPベンチマーク: Zend Framework vs Symfony vs CakePHP vs CodeIgniter vs PHP on TRAX)を「del.icio.us」に追加

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

今回使用したフレームワークはZend FrameworkSymfonyCakePHPCodeIgniterPHP 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のソースについてモデル生成が有効になっていたため、
  ソースを修正しベンチマークを再度行って結果を修正しました。
Posted by tsujitako at 8:40 午前 in PHP/