アカウント名:
パスワード:
Oracleなんかだとプロファイリング用のツール(tkprofなど)が有ります.
でもSQLで実際に性能を出すつもりで組むなら, 最初からテーブルや索引の構造を考慮して, DBエンジンの動き方をイメージしながら記述しますね. 例えば副問い合わせで最初に主キーで絞り込みを行い, そのデータを仮想表として使って他のテーブルを結合し検索するとか.
ですから言語として見たSQLは確かに非手続き型なんですが, 現実のシステムで使う場合には半ば手続き型の様に取り扱うことが多いです.
間に一枚トランザクション・モニタを入れて, キュー長が長くなってレスポンスが落ちたとしても, とりあえずバックエンドの処理が流れるようにするぐらいですかね. データ一貫性を考えるとデータベース部分を分散することは難しそうですし. このスループット保証という考え方は元もとは汎用機で一般的な物ですが, オープン系のWebベースシステムでも, いわゆる大規模高信頼性システムでは多く使われるようになってきています.
結局, オープンソースであるかどうかというよりも, ベストエフォートなシステムでは対応できない状況が有りうる. あるいは対応させようとすると過度な冗長性が必要になるということだと思います.
ところでフリー・商用関係なく, Linux用のトランザクション・モニタってありましたっけ?
なるほど, ORCA [med.or.jp]はトランザクション・ベースになっているわけですね.
だいたいこういうコードって、最初から入れるもんじゃなくて、「げっSEGV出ちまったよ。でもどこから出てるかわかんないからとりあえず握り潰すコード入れちまえ。ふむふむ。とりあえず問題なく動いてるみたいじゃん。このままでいいや~」というパターンがありがち。 簡単にわかりやすく言えば糞って事だな。
蛇足ながら書いとくと、SEGVをCatchするのが糞な訳じゃないよ。 SEGV受けて正常に処理されていると確認できる範囲のデータを保存するとか、相手のあるシステムだと正規の終了手段をとってからプログラムを終了させるという形で使われるのであれば、それはまっとうなやり方。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
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)
商用ソフトを併用するなら (スコア:1)
間に一枚トランザクション・モニタを入れて, キュー長が長くなってレスポンスが落ちたとしても, とりあえずバックエンドの処理が流れるようにするぐらいですかね. データ一貫性を考えるとデータベース部分を分散することは難しそうですし. このスループット保証という考え方は元もとは汎用機で一般的な物ですが, オープン系のWebベースシステムでも, いわゆる大規模高信頼性システムでは多く使われるようになってきています.
結局, オープンソースであるかどうかというよりも, ベストエフォートなシステムでは対応できない状況が有りうる. あるいは対応させようとすると過度な冗長性が必要になるということだと思います.
ところでフリー・商用関係なく, Linux用のトランザクション・モニタってありましたっけ?
Re:商用ソフトを併用するなら (スコア:1, 参考になる)
Re:商用ソフトを併用するなら (スコア:1)
なるほど, ORCA [med.or.jp]はトランザクション・ベースになっているわけですね.
Re:商用ソフトを併用するなら (スコア:1)
この手の脆弱性が嫌だからこういったものを作ったわけです。
汎用機屋にしてみると、こういったミドルウェアを持たずに業務システムを動かしているのを見ると、不安でなりません。
とは言え、今回はもっと入口のところでコケているんじゃないかと思うのですが。
Re:商用ソフトを併用するなら (スコア:0)
それぞれメリットデメリットあると思いますが、
おごちゃんの意見はどうですか?
考え方としては、ハードウェアの限界に達する前に、
ApacheなりPostgreSQLの最大接続数で絞る、という方法も
あるわけですよね。
Re:商用ソフトを併用するなら (スコア:1)
また、一度処理を受けつけたなら、当然結果は返すべきだと。
それをまっとうするのは、なかなか簡単そうで難しいことです。
Re:商用ソフトを併用するなら (スコア:0)
# なんていうか、以上が発生したならきちんと止まるべきだと思
# うわけです。
Re:商用ソフトを併用するなら (スコア:1, おもしろおかしい)
Typing fault (core dumped)
Re:商用ソフトを併用するなら (スコア:0)
Re:商用ソフトを併用するなら (スコア:0)
ぱんだぁ? (スコア:0)
static void
CatchSEGV(
int ec)
{
}
<snip>
signal(SIGSEGV,(void *)CatchSEGV);
誰か解説してくれ (スコア:0)
無粋とは思うが誰か解説をつけてくれ。
いや、つけてください。おながいしまそ。
Re:誰か解説してくれ (スコア:1, 参考になる)
CatchSEGVが何もしないようになっているので、要するにSEGVを握り潰してるだけ。
だから、こういうコードがあるという事は、このプログラムは状況によってはどんな動作をするかわからない。
だいたいこういうコードって、最初から入れるもんじゃなくて、「げっSEGV出ちまったよ。でもどこから出てるかわかんないからとりあえず握り潰すコード入れちまえ。ふむふむ。とりあえず問題なく動いてるみたいじゃん。このままでいいや~」というパターンがありがち。
簡単にわかりやすく言えば糞って事だな。
蛇足ながら書いとくと、SEGVをCatchするのが糞な訳じゃないよ。
SEGV受けて正常に処理されていると確認できる範囲のデータを保存するとか、相手のあるシステムだと正規の終了手段をとってからプログラムを終了させるという形で使われるのであれば、それはまっとうなやり方。
Re:誰か解説してくれ (スコア:0)
CatchSegv()
{
<snip>
}
じゃなくて、
CatchSegv()
{
}
<snip>
になってるところが肝。
参考になる (スコア:0)
要するに、ンコをちびっちゃったパンツをはいたまま夏コミ会場を徘徊するようなもの、と理解しました。
# 決して特定の個人を意図しているわけではな~い
Re:誰か解説してくれ (スコア:1)
# rm -rf ./.
Re:誰か解説してくれ (スコア:0)
まぁ落ちりゃいいってもんじゃないとは思うけどね。
Linuxは?Apacheは? (スコア:0)
でるのかな?
PostgreSQLが突っ込まれたのはほんとに
システム上、クリティカルな部分だから?
暗に、組み合わされたオープンソースのほかのパートに比べ
信頼されてないってことなのかも。
Re:Linuxは?Apacheは? (スコア:0)
信頼性なんて言ったら、Linuxのfsだって如何なものかっつー感じだし。
違うでしょう (スコア:0)