- PR -

DBのメモリについて

1|2 次のページへ»
投稿者投稿内容
KKF
常連さん
会議室デビュー日: 2008/03/09
投稿数: 24
投稿日時: 2008-08-09 01:50
いつもお世話になっております。

下記にも色々と投稿しているのですが、
現在以下の環境でサイトを構築しています。
WEBサーバ　OS：LINUX
言語：PHP5
DBサーバ　DB：PostgreSql8.3.1
全文検索機能Luidaをインストール
現在DBサーバの件数が一番多いテーブルで約2200万件あります。

そこで質問なのですが、現在DBサーバのメモリが1Gなのですが、
これは少ないのでしょうか？

時々検索に時間がかかるときがあったり、さらにORDERBY句を利用すると
かなり遅くなってしまいます。

やはりメモリ増設したほうがよろしいでしょうか？
また、現在のメモリ使用量などが分かる方法などあるのでしょうか？

申し訳ありませんが、どなたかご教示ください。

以上　よろしくお願い致します。





[ メッセージ編集済み 編集者: JDOG 編集日時 2008-08-11 17:38 ]
ほったて
ベテラン
会議室デビュー日: 2007/11/10
投稿数: 68
投稿日時: 2008-08-10 00:27
×SentOS
○CentOS


まあそれはともかく。
データ量が 2200 万件とはいえ、この情報だけでは 1GB のメモリで足りるかどうかは判断するのは難しいかと。処理の内容によりますし。
（まさか 2200 万件をフルスキャンするなんてことはないでしょうが）

order by するときに遅いってことだとしたらwork_memの調整になるのかな？　デフォルトは 1MB らしいのでこれを調整してみるとか、shared_buffersを調整するとか、そもそも実行するSQLで無駄な全件検索してないかとか、そういう観点の調査もしてみる必要があるかと思います。

Google大先生に "PostgreSQL" "メモリ" "パラメータ" で検索するだけでも結構ヒントが見つかりますよ。こことか。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-08-10 01:34
ORDER BYはPostgreSQLの8.3以降では多少早くなったと聞いたことがありますが、
基本的にそんなに軽い処理ではありません。

チューニングが面倒だけど、とにかく早くしたいというなら、
数十ギガでも増設すればいいと思いますが、
まずはボトルネックを探しましょうよ。

実行プランを見るといいと、以前アドバイスしたと思いますが、
SQLで解決　→　パラメータで解決　→　ハード増強で解決
というようにきちんと手順を踏んだ方がいいですよ。
忠犬
大ベテラン
会議室デビュー日: 2006/05/01
投稿数: 109
投稿日時: 2008-08-10 19:21
引用:

さらにORDERBY句を利用するとかなり遅くなってしまいます。


大規模＆性能を出す必要があるシステムでは、「ソートの発生するSQLの記述は禁止」
といったプロジェクトもあります。
どうやればソート抑止できるかというと、インデクスを活用します。
そういった設計が、そもそもできていないのでは？
KKF
常連さん
会議室デビュー日: 2008/03/09
投稿数: 24
投稿日時: 2008-08-11 09:33
ほったて様
返信ありがとうございます。お勧めサイトを参考にして、もう一度色々と試してみます。

かつのり様
返信ありがとうございます。かつのり様の言うとおりボトルネックを探して、再度実行プランを考え直します。

忠犬様
返信ありがとうございました。一応インデックス等の活用は行っています。
引継ぎ案件のため、細かい設計までまだ把握していませんが、再度設計の見直しを行いたいと思います。

皆様ご教示ありがとうございました。


eno
常連さん
会議室デビュー日: 2008/08/22
投稿数: 28
お住まい・勤務地: 代々木上原
投稿日時: 2008-08-27 15:06
メモリの使用量などはmem,topや
$ ps alx | head -1 && ps alx | grep post*などそもそもapacheとpostgresqlを併用して問題ないか確認したんですよね？order byは全部のデータを読み込むでないにしろ、瞬間的なメモリ・ＣＰＵのリソースくいは大きくなると思います。しかし、メモリ容量はＣＰＵ使用率が常時１００％でないのであれば、目的のデータを取得するまでに時間がかかっている、つまりＳＱＬ文がまずいわけです。ひどい話、それだけ大規模なＤＢならばテーブルだけ指定してwhere句でフィルターしてなければ、完全なシステムのボトルネックとなると思います。同じＬＡＮ内であり、スイッチハブ経由であればネットワーク関係で時々遅くなるという現象はないでしょうし、ブラウザもタブブラウザなどwebFormのnewであればアプリケーションのnewとは違って時々遅くなるというクライアント機の原因にはなりません。チューニングにしてもwork_mem以外はデフォルトで問題ないと思います。
deanna
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 118
投稿日時: 2008-08-27 21:19
引用:

どうやればソート抑止できるかというと、インデクスを活用します。


ORDER BYを指定しないで結果の順序を保証するRDBMSがあるんでしょうか？
忠犬
大ベテラン
会議室デビュー日: 2006/05/01
投稿数: 109
投稿日時: 2008-08-27 23:19
引用:

ORDER BYを指定しないで結果の順序を保証するRDBMSがあるんでしょうか？


回答の意味を誤解しているのでは？

インデクスは、データの絞込み以外に、order by、group by、distinctなどの指定に伴って発生するソートを抑止するためにも使われます。

例えば、下記のような表定義があったとします。

コード:
create table t1
(c1      int primary key,
 c2      int,
 c3      int,
 c4      int);


そして、次のようなSQLを実行するとします。

コード:
select * from t1
 where c1 between 101 and 200
 order by c1,c2,c3


この場合、上記の表、インデクス定義では、「c1、c2、c3」列でのソートが作業ファイル等を用いて発生します。
一方、下記のようなインデクスを定義しておけば、作業ファイル等を用いたソートを抑止できる場合があります。


コード:
create index t1ix1 on t1(c1,c2,c3)


再び引用です。

引用:

ORDER BYを指定しないで結果の順序を保証するRDBMSがあるんでしょうか？


特異な例ですが、SQL Serverは、primary keyがあれば、primary keyでソートするようです。これは私の印象でなく、マニュアルにそういった記載があり、実際に試したところ、確かにprimary key順になるようです。
また、MySQLでも将来的な計画の中に、「order by指定がない場合は、primary keyでのorder byを内部的に生成したアクセス計画を作る」といった案があるようです。

しかしながら、標準SQL、殆どのRDBMSでは、「order by指定がない場合、検索順序は保証しない」ということが常識であることに変わりありません。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）