postgresql 參數配置優化詳介紹

一、Linux內核參數設置:/etc/sysctl.conf
    http://www.pgsqldb.org/pgsqldoc-8.1c/kernel-resources.html#SYSVIPC
    缺省設置只適合小安裝(缺省最大共享內存是 32 MB)。
    不過,其它的缺省值都相當大,通常不需要改變。
    最大的共享內存段設置可以用sysctl 接口設置。
    比如,要允許 128MB,並且最大的總共享內存數爲 2097152 頁(缺省):
    你可以把這些設置放到 /etc/sysctl.conf 裏,在重啓後保持有效。
    $ sysctl -w kernel.shmmax=134217728
    $ sysctl -w kernel.shmall=2097152 #ceil(SHMMAX/PAGE_SIZE)
  老版本里可能沒有 sysctl 程序,但是同樣的改變可以通過操作 /proc 文件系統來做:
    $ echo 134217728 >/proc/sys/kernel/shmmax
    $ echo 2097152 >/proc/sys/kernel/shmall

二、影響 PostgreSQL 的內存使用的配置參數
  名稱                    近似倍率(每次增加的字節數)
  max_connections           400 + 220 * max_locks_per_transaction
  max_prepared_transactions 600 + 220 * max_locks_per_transaction
  shared_buffers            8300 (假設 8K 的BLCKSZ)
  wal_buffers               8200 (假設 8K 的BLCKSZ)
  max_fsm_relations         70
  max_fsm_pages             6
 
三、Usage Approximate shared memory bytes required (as of 8.3)
  Connections (1800 + 270 * max_locks_per_transaction) * max_connections
  Autovacuum workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
  Prepared transactions (770 + 270 * max_locks_per_transaction) * max_prepared_transactions
  Shared disk buffers (block_size + 208) * shared_buffers
  WAL buffers (wal_block_size + 8) * wal_buffers
  Fixed space requirements 770 kB 

四、參數調整:
    參數具體含義參考:http://www.pgsqldb.org/pgsqldoc-cvs/runtime-config-resource.html
  shared_buffers  memory的 1/4 - 1/2
  temp_buffers #根據每次訪問表讀取的平均量而設置
  max_prepared_transactions #默認,暫不調整
  work_mem RAM的 2% - 4% #可以根據explain analyze分析語句查看及數據庫查詢形式.
  maintenance_work_mem > work_mem + ↑M # 目前我們服務器上:work_mem+50-100暫時足夠,後續根據數據庫
  max_stack_depth < ulimit -s
  effective_cache_size memory的 1/2
  max_connections # max_connections * work_mem < memory
  max_prepared_transactions # 0或max_connections 一樣大小
  checkpoint_segments RAM的 10% 比較合理
  wal_buffers #大到能保存下一次事務生成的 WAL 數據即可,但得在服務器啓動的時候設置
  max_fsm_pages # 16 * max_fsm_relations 只能在服務器啓動的時候設置
  max_fsm_relations # 最大數目的關係(表和索引)* 50
  # - Planner Method Configuration -
   enable_bitmapscan = on
   enable_hashagg = on
   enable_hashjoin = on
   enable_indexscan = on
   enable_material = on
   enable_mergejoin = on
   enable_nestloop = on
   enable_seqscan = on
   enable_sort = on
   enable_tidscan = on
  注意:考慮 max_connections * work_mem + shared_buffers + temp_buffers + maintenance_work_mem + 操作系統所需內存 < RAM
    
五、詳細參數說明
  --服務器配置
  Mem:   1035140k total,  1014492k used,    20648k free,   146700k buffers
  Swap:  1052248k total,      320k used,  1051928k free,   718972k cached
  --參數詳細配置及詳細說明
  1、shared_buffers = 1/4 memory in your system #這是最重要的參數,postgresql通過shared_buffers和內核和磁盤打交道,因此應該儘量大,讓更多的數據緩存在shared_buffers中
  2、temp_buffers
     /*設置每個數據庫會話使用的臨時緩衝區的最大數目,
      這些都是會話的本地緩衝區,只用於訪問臨時表。缺省是 1000。
      這個設置可以再獨立的會話內部設置,但是只有在會話第一次使用臨時表的時候才能增長,在該會話裏隨後的改變該數值的企圖將沒有作用。
      一個會話將按照 temp_buffers 給出的限制,根據需要分配臨時緩衝區。
      如果在一個並不需要大量臨時緩衝區的會話裏設置一個大的數值,
      其開銷只是一個緩衝區描述符,或者說每次temp_buffers裏的增加大概64字節,
      不過,如果一個緩衝區實際上被使用,那麼就會有額外的8192字節爲之消耗(或者,概括來說是 BLCKSZ 字節)。
     */
  3、effective_cache_size =1/2 of total memory
     /*是PostgreSQL能夠使用的最大緩存,這個數字對於獨立的PostgreSQL服務器而言應該足夠大,
      比如4G的內存,可以設置爲3.5G (437500),use 25% of RAM for cache size, and 2-4% for sort size
     */
  4、work_mem
     /*EnterpriseDB在執行排序操作時,會根據work_mem的大小決定是否將一個大的結果集拆分爲幾個小的
      和work_mem查不多大小的臨時文件。顯然拆分的結果是降低了排序的速度。
      因此增加work_mem有助於提高排序的速度。及散列表在散列連接,散列爲基礎的聚集,以及散列爲基礎的 IN 子查詢處理中都要用到。
      通常設置爲實際RAM的2% -4%,根據需要排序結果集的大小而定,比如81920(80M)
     */
  5、maintenance_work_mem
        /*這裏定義的內存只是在CREATE INDEX, VACUUM等時用到,
          因此用到的頻率不高,但是往往這些指令消耗比較多的資源,因爲在一個數據庫會話裏,
          任意時刻只有一個這樣的操作可以執行,並且一個數據庫安裝通常不會有太多這樣的工作併發執行,
          把這個數值設置得比 work_mem 更大是安全的。更大的設置可以改進清理和恢復數據庫轉儲的速度。
      因此應該儘快讓這些指令快速執行完畢:給maintence_work_mem大的內存,比如512M(524288)
     */
  6、max_connections
        /*通常max_connections的目的是防止 max_connections * work_mem 超出了實際內存大小。
          比如,如果將work_mem設置爲實際內存的2%大小,則在極端情況下,如果有50個查詢都有排序要求,
          而且都使用2%的內存,則會導致swap的產生,系統性能就會大大降低。
          當然,如果有4G的內存,同時出現50個如此大的查詢的機率應該是很小的。
          不過,要清楚 max_connections和work_mem的關係
         */
  7、max_prepared_transactions (integer) <= max_connections
     /*設置可以同時處於"準備好"狀態的事務的最大數目,把這個參數設置爲零則關閉準備好的事務的特性,
      缺省是 5,這個選項只能在服務器啓動的時候設置,
      如果你不使用準備好事務,這個參數也可以設置爲零。
      如果你使用它們,你可能會需要把 max_prepared_transactions 設置成至少和 max_connections 一樣大,
      以避免在準備步驟的失敗,增加這個參數可能會導致 PostgreSQL 要求比缺省的操作系統配置的更多的 System V 共享內存。
     */
  8、max_stack_depth (integer) <= ulimit -s
     /*聲明服務器的執行堆棧的最大安全深度。
     內核強制的實際堆棧尺寸(就是 ulimit -s 或者局部等效物的設置),
     小於一個安全的一兆字節左右的範圍。需要這麼一個安全的界限是因爲在服務器裏,
     並非所有過程都檢查了堆棧深度, 而只是在可能遞規的過程,比如表達式計算這樣的過程裏面進行檢查。
     把這個參數設置得大於實際的內核限制講意味着一個正在跑的遞歸函數可能會導致一個獨立服務器進程的崩潰。
     缺省設置是 2048 KB (兩兆),這個值相對比較小,不容易導致崩潰。
     但是,這個值可能太小了,以至於無法執行復雜的函數。
     */
  9、max_fsm_pages (integer) > 16 * max_fsm_relations
     /*設置在共享的自由空間映射表裏自由空間會跟蹤的最大數目的磁盤頁面數。
       每個頁面槽位需要消耗六個字節的共享內存。缺省是 20000。這個選項只能在服務器啓動的時候設置。*/
  10、max_fsm_relations (integer) ~ (表和索引)*50
     /*設置自由空間將在共享地自由空間映射裏跟蹤的最大數目的關係(表和索引)。
      每個槽位大概要使用五十字節左右。缺省是 1000。
      這個選項只能在服務器啓動的時候設置。
     */
  11、vacuum_cost_delay (integer)
     /*以毫秒計的時間長度,如果超過了開銷限制,那麼進程將睡眠一會兒,缺省值是 0,它關閉基於開銷的清理延遲特性。
      正數值打開基於開銷的清理,不過要注意在許多系統上 sleep 延遲的有效分辨率是 10 毫秒;
      把 vacuum_cost_delay 設置爲一個不是 10 的整數倍的數值與將它設置爲下一個 10 的整數倍作用相同。
     */
  12、vacuum_cost_page_hit (integer)  #清理一個在共享緩存裏找到的緩衝區的預計開銷。它代表鎖住緩衝池,查找共享的散列表以及掃描頁面的內容的開銷。缺省值是 1。
  13、vacuum_cost_page_miss (integer) #清理一個要從磁盤上讀取的緩衝區的估計開銷。這個行爲代表鎖住緩衝池,查找共享散列表,從磁盤讀取需要的數據塊以及掃描它的內容的開銷。缺省值是 10。
  14、vacuum_cost_page_dirty (integer) #如果清理修改一個原先是乾淨的塊的預計開銷,它需要一個把髒的磁盤塊再次沖刷到磁盤上的額外開銷。缺省值是 20。
  15、vacuum_cost_limit (integer) #導致清理進程休眠的積累開銷。缺省是 200。
    /*注意: 有些操作會持有關鍵的鎖,並且應該儘快結束。
     在這樣的操作過程中,基於開銷的清理延遲不會發生作用。爲了避免在這種情況下的長延時,
     實際的延遲是:vacuum_cost_delay*accumulated_balance/vacuum_cost_limit與vacuum_cost_delay*4之間的最大值
    */
  16、bgwriter_delay (integer)
     /*聲明後端寫進程活躍回合之間的延遲。在每個回合裏,寫進程都會爲一些髒的緩衝區發出寫操作。
      然後它就休眠 bgwriter_delay 毫秒,然後重複動作。缺省值是 200。
      請注意在許多系統上,休眠延時的有效分辨率是 10 毫秒;
      因此,設置 bgwriter_delay 爲一個不是 10 的倍數的數值與把它設置爲下一個 10 的倍數是一樣的效果。
      這個選項只能在服務器啓動的時候。
     */
  17、bgwriter_lru_percent (floating point)
     /*爲了減少服務器進程發出自己的寫操作的可能,後端寫進程儘量寫那些可能很快被重複使用的緩衝區。
      在每個回合裏,它檢查最多百分之 bgwriter_lru_percent 的快要被重複使用的緩衝區, 然後寫出其中的髒緩衝區。
      缺省值是 1.0(這是全部共享緩衝區的百分比),這個選項只能在服務器啓動的時候設置。
     */
  18、bgwriter_lru_maxpages (integer) #在每個回合裏,不超過這麼多個緩衝區將做爲掃描到的即將重複使用的緩衝區寫入磁盤,缺省值是5。這個選項只能在服務器啓動的時候設置。
  19、bgwriter_all_percent (floating point)
     /*爲了減少檢查點時刻需要做的工作,後端寫進程還會對整個緩衝池進行循環掃描, 把那些認爲是髒的緩衝區寫出到磁盤。
      在每個回合裏,它爲此檢查最多百分之 bgwriter_all_percent 的緩衝區進行操作。
      缺省值是 0.333(這是全部共享緩衝區的百分比),使用缺省的 bgwriter_delay,
      這個設置可以做到每分鐘掃描一次整個共享緩衝池,同上。
     */
  20、bgwriter_all_maxpages (integer) #在每個回合裏,不超過這個數值的緩衝區,將作爲掃描整個緩衝池的結果,寫入磁盤,缺省值是 5,同上。
     /*小的 bgwriter_all_percent 和 bgwriter_all_maxpages 減少後端寫進程導致的額外 I/O 負荷,
      但是會導致在檢查點的時候的更多工作。
      要降低檢查點時的峯值負荷,增加這兩個值。
      類似的小的 bgwriter_lru_percent 和 bgwriter_lru_maxpages 減小後端寫進程導致的額外的 I/O 負載,
      但是會有可能是服務器進程不得不自己發出寫動作,降低交互查詢的交互性。
      要想完全關閉後臺寫進程,可以把兩個 percent 和/或兩個 maxpages 設置爲零。
     */

六、增加最大連接數到2000以上
   Linux操作系統中默認的SEMMNI一般只能支持2000個左右的連接,這個值應該設爲 max_connections*16,
   但實際上各不同的系統中有似乎有一點偏差,如:
     SEMMNI=128時,公式算出的最大連接數(max_connections)爲2048,在RHEL5中最大隻能用到2030
   RHEL5中修改SEMMNI方法:
     vi /etc/sysctl.conf #中加入一行
     kernel.sem=250 32000 32 128
   當中最後一個'128'爲當前的SEMMNI

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章