Custom Search

JITAKU_SVR_Wiki

shared_buffers

推奨値:OS搭載メモリの10~20%(デフォルト32MB)
  説明:メモリ上でデータ操作、読み込みを行うための領域
  効果:HDDの速度が遅いため、メモリに役割を任せることにより、高速なデータのやり取りが可能
     ただし、値を大きくしてもOSのキャシュとぶつかるためあまり効果が出ない

checkpoint_segments

推奨値:書き込みが多いシステムは32~256(デフォルト300秒)
  説明:メモリ上に乗っているデータをHDDに書き込むタイミング
     1つ16MBの固まりが○個出来たらHDDへ書き込む。
  効果:小さいほど高速になるが、ディスクアクセスが頻発する
      また、checkpoint_timeoutが優先されるので、そちらの値も確認すること

checkpoint_timeout

推奨値:checkpoint_segmentsより大きな値(デフォルト300)
  説明:checkpoint作成のタイミングが規定値に達すると実行される
  効果:特にパフォーマンスには影響しないが、checkpoint_segmentsより値が小さい場合、
      先にcheckpointを作成されてしまう



wal_buffers

推奨値:4MB以上(デフォルト-1)
  説明:WALログ(REDOログ)のキャッシュサイズ
     データと同じでHDDに書き込む前にメモリ上で確保する領域
     値が小さ過ぎると頻繁にディスクアクセスが頻発してしまう
  効果:ディスクアクセスが頻発するとパフォーマンス劣化につながってしまうので、
     最低4MB以上の値を与えることでパフォーマンス向上につながる

effective_cache_size

推奨値:OS搭載メモリの50%程度(デフォルト128MB)
  説明:ディスクキャッシュの実行サイズ
     データベース領域と同じサイズ以上を確保すれば、データベースをすべてメモリ内に入れられることになる。
     次項のrandum_page_costも合わせてチューニングすると尚良し
  効果:index scanは共有バッファメモリを使用せす、effective_cacheをしようする
     つまり、この値が小さいとindexのサイズが大きいとキャッシュから溢れ、
     直接HDDとやり取りを行ってしまう

random_page_cost

推奨値:2~3(デフォルト4)
  説明:HDDからランダムにブロックを読み取るコスト
  効果:より低くすることで、問い合わせオプティマイザが積極的にindex scanをするようになる

work_mem

推奨値:(実メモリ - shared_buffers) / max_connections (デフォルト1MB)
  説明:1プロセスごとに使用出来るメモリ量
  効果:大きくすることで、1プロセスあたりのメモリ使用量が大きくなるために処理が速くなる
     特にsortを行う処理が多い場合などには有効
    


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2015-12-17 (木) 16:39:58 (707d)