アカウント名:
パスワード:
Oracleなんかだとプロファイリング用のツール(tkprofなど)が有ります.
でもSQLで実際に性能を出すつもりで組むなら, 最初からテーブルや索引の構造を考慮して, DBエンジンの動き方をイメージしながら記述しますね. 例えば副問い合わせで最初に主キーで絞り込みを行い, そのデータを仮想表として使って他のテーブルを結合し検索するとか.
ですから言語として見たSQLは確かに非手続き型なんですが, 現実のシステムで使う場合には半ば手続き型の様に取り扱うことが多いです.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
Linux + PostgreSQL + Apache + PHP (スコア:2, 参考になる)
『ほーら、やっぱりオープンソースだとだめじゃん』
などと (いわれちゃう|誤解される) のが一番いやだなぁ。
本当の問題は全然別のところにあるんだから。
--- Toshiboumi bugbird Ohta
Re:Linux + PostgreSQL + Apache + PHP (スコア:1, 興味深い)
件のシステムですが、科目登録開始2日後くらいに
vacuumをするためかデータベースの最適化という名目で
朝方にシステムを止めるようになりました。
昼間と夜間は混雑してたり落ちたりしてて全く繋がらないから朝方位しかログインできなかったのに…
Re:Linux + PostgreSQL + Apache + PHP (スコア:2, 参考になる)
> この規模だとPostgreSQLは厳しいんじゃないんでしょうか?
確かにその可能性は少なくないと思います。…でも DBMS の
パフォーマンスってスキーマの設計に大きく依存するもの
ですから、それなりに配慮して適宜にデータ冗長性をもたす
などすれば、結構タフに作れるはずなんですよね。
# 「理想の DBMS」はデータ構造に影響を受けてはならんの
# ですが ^^;;
記事を読む限りでは、当初からかなり複雑な処理を一気に実装
してしまった ( == 上記実装上の配慮を充分に検討する余地
がない) ことが、充分にスケールできないシステムを作る
原因となってしまったように思えるのです。
--- Toshiboumi bugbird Ohta
Re:Linux + PostgreSQL + Apache + PHP (スコア:0)
要は、作った人達の知識不足が原因なだけ。ましなSIに構築を頼みましょう :)
Re:Linux + PostgreSQL + Apache + PHP (スコア:1, 参考になる)
何も考えずに (というか RDBMS がオプティマイズしてくれるものと思って) SQL を書いていると確かに PostgreSQL では厳しくなりそうです。Oracle などの商用 RDBMS はそのあたりの懐が深いんだよねぇ。
ただ、事前にきっちりプロファイリングして SQL やテーブル構成を最適化しておけば、PostgreSQL でも全然イケると思いますよ。
// PostgreSQL 7.1 の時代に 4CPU の Xeon マシンで daily 1000万 trans over、
// ピーク時 200trans/sec over でちゃんと動いてたシステムを知っているので AC。
Re:Linux + PostgreSQL + Apache + PHP (スコア:1, 興味深い)
SQLを呼んでから帰ってくるまでの時間を測る対外的プロファイリングは、恒例のやり方で出来るけど、
SQLの*中のどこが*どう遅いのかを知るには、どうやればいいんでしょう?
複数書いてみて交換して比較すればいいのかな。
でもそれだと、あんまり作業効率は良く無さそうだし、細部が見えないのは結局同じ。
Re:Linux + PostgreSQL + Apache + PHP (スコア:1)
Oracleなんかだとプロファイリング用のツール(tkprofなど)が有ります.
でもSQLで実際に性能を出すつもりで組むなら, 最初からテーブルや索引の構造を考慮して, DBエンジンの動き方をイメージしながら記述しますね. 例えば副問い合わせで最初に主キーで絞り込みを行い, そのデータを仮想表として使って他のテーブルを結合し検索するとか.
ですから言語として見たSQLは確かに非手続き型なんですが, 現実のシステムで使う場合には半ば手続き型の様に取り扱うことが多いです.
Re:Linux + PostgreSQL + Apache + PHP (スコア:1)
PostgreSQLは知りませんが、大抵の商用RDBは、セッションやユーザが、
どのくらいI/Oを行っているか、CPU、メモリを使用しているか、
排他にどれだけ時間を費やしているかを調べることが可能です。
そういった統計情報を集めて分析することで、*どこが*ボトルネック
になっているのかを調べることが可能です。
# SQLレベルで統計がとれるというと、DB2くらいかな?
Oracle などの商用 RDBMS はそのあたりの懐が深い (スコア:0)
使ったものじゃない (スコア:1, すばらしい洞察)
Re:Linux + PostgreSQL + Apache + PHP (スコア:0)