PostgresSQL-內存分配

postgresql的內存分配主要由shared_buffers、temp_buffers、work_mem、maintenance_work_mem參數控制。

shared_buffers又能夠叫作共享緩衝區，postgresql對數據操做時都要先將數據從磁盤讀取到內存中，而後進行更新，最後再將數據寫回磁盤。shared_buffers的功能就是用於存放從磁盤讀取的數據。根據文檔參數的設置範圍通常在25%~40%之間。windows與linux對內存的管理方式不一樣，在linux中須要注意共享段大小的設置(kernel.shmmax)。

temp_buffers稱之爲臨時緩衝區，用於數據庫會話訪問臨時表數據，系統默認值爲8M。能夠在單獨的session中對該參數進行設置，尤爲是須要訪問比較大的臨時表時，將會有顯著的性能提高。

work_mem能夠稱之爲工做內存或者操做內存。其負責內部的sort和hash操做，合適的work_mem大小可以保證這些操做在內存中進行。定義過小的話，sort或者hash操做將須要與硬盤進行swap，這樣會極大的下降系統的性能；太大的話導致在可以在內存中完成的操做數量減小，其餘的部分須要與磁盤進行swap操做，增長IO下降性能。系統提供的默認值是1M，在實際的生產環境中，要對系統監控數據進行分析，做出最好的選擇。
大體有兩種方式：估計方法與計算方法。第一種是能夠根據業務量的大小和類型，通常語句運行時間，來粗略的估計一下。第二種方式是經過對數據庫的監控，數據採集，而後計算其大小。總之合適的大小對系統的性能相當重要。
在實際的維護中能夠經過explain analyze分析語句的work_mem大小是否合適。在語句中設置work_mem參數的大小能夠充分利用內存，提升語句的執行效率。
對於work_mem內存分配時還要考慮數據庫的併發狀況，max_connections決定了系統的最大的併發鏈接數。不論如何調整work_mem都要考慮max_connections*work_mem+shared_buffers+temp_buffers+maintenance_work_mem+操做系統所需內存不可以超過整個的RAM大小，這是很是重要的。
work_mem參數對系統的性能是如此的重要，讓其實時的適應數據庫的運行情況顯的不太可能，可是能夠經過對數據庫運行週期的監控，總結相應的數據，而後定製一個專用的腳本，專門用來修改work_mem的大小，使其階段性的更加適應系統的情況，不失爲一種好的方法。

maintenance_work_mem稱之爲維護工做內存，主要是針對數據庫的維護操做或者語句。儘可能的將這些操做在內存中進行。主要針對VACUUM，CREATE INDEX，REINDEX等操做。在對整個數據庫進行VACUUM或者較大的index進行重建時，適當的調整該參數很是必要。
postresql文檔提示在啓用了autoacuum功能的狀況下，該參數不能配置的過大。

監聽IPv4的全部IP.

listen_addresses = '0.0.0.0'

最大容許1000個鏈接.

max_connections = 1000

爲超級用戶保留3個可用鏈接.

superuser_reserved_connections = 3

默認的unix socket文件放在/tmp, 修改成$PGDATA, 以確保安全.

unix_socket_directory = '/pgdata/digoal/1921/data02/pg_root'

默認的訪問權限是0777, 修改成0700更安全.

unix_socket_permissions = 0700

Linux下面默認是2小時.tcp的keepalives包發送間隔以及重試次數, 若是客戶端沒有響應, 將主動釋放對應的SOCKET.

tcp_keepalives_idle = 60

tcp_keepalives_interval = 10

tcp_keepalives_count = 6

大的shared_buffers須要大的checkpoint_segments,同時須要申請更多的System V共享內存資源.

這個值不須要設的太大, 由於PostgreSQL還依賴操做系統的cache來提升讀性能, 另外, 寫操做頻繁的數據庫這個設太大反而會增長checkpoint壓力.

shared_buffers = 512MB

這個值越大, VACUUM, CREATE INDEX的操做越快, 固然大到必定程度瓶頸就不在內存了, 多是CPU例如建立索引.

這個值是一個操做的內存使用上限, 而不是一次性分配出去的. 而且須要注意若是開啓了autovacuum, 最大可能有autovacuum_max_workers*maintenance_work_mem的內存被系統消耗掉.

maintenance_work_mem = 512MB

通常設置爲比系統限制的略少,ulimit -a : stack size              (kbytes, -s) 10240

max_stack_depth = 8MB

手動執行vacuum操做時, 默認是沒有停頓執行到底的, 爲了防止VACUUM操做消耗太多數據庫服務器硬件資源, 這個值是指vacuum在消耗多少資源後停頓多少時間,以便其餘的操做可使用更多的硬件資源.

vacuum_cost_delay = 10ms

#vacuum_cost_page_hit = 1               # 0-10000 credits

#vacuum_cost_page_miss = 10             # 0-10000 credits

#vacuum_cost_page_dirty = 20            # 0-10000 credits

#vacuum_cost_limit = 200                # 1-10000 credits

默認bgwriter進程執行一次後會停頓200ms再被喚醒執行下一次操做, 當數據庫的寫操做很頻繁的時候, 200ms可能太長, 致使其餘進程須要花費過多的時間來進行bgwriter的操做.

bgwriter_delay = 10ms

若是須要作數據庫WAL日誌備份的話至少須要設置成archive級別, 若是須要作hot_standby那麼須要設置成hot_standby, 因爲這個值修改須要重啓數據庫, 因此先設置成hot_standby比較好. 固然hot_standby意味着WAL記錄得更詳細, 若是沒有打算作hot_standby設置得越低性能越好.

wal_level = hot_standby

wal buffers默認是-1 根據shared_buffers的設置自動調整shared_buffers*3% .最大限制是XLOG的segment_size.

wal_buffers = 16384kB

多少個xlog file產生後開始checkpoint操做, 這個值越大, 容許shared_buffer中的被頻繁訪問的髒數據存儲得更久. 必定程度上能夠提升數據庫性能. 可是太大的話會致使在數據庫發生checkpoint的時候須要處理更多的髒數據帶來長時間的IO開銷. 過小的話會致使產生更多的WAL文件(由於full page writes=on,CHECKPOINT後的第一次塊的改變要寫全塊, checkpoint越頻繁, 越多的數據更新要寫全塊致使產生更多WAL).

checkpoint_segments = 64

這個和checkpoint_segments的效果是同樣的, 只是觸發的條件是時間條件.

checkpoint_timeout = 5min

歸檔參數的修改也須要重啓數據庫, 因此就先打開吧.

archive_mode = on

這個是歸檔調用的命令, 我這裏用date代替, 因此歸檔的時候調用的是輸出時間而不是拷貝wal文件.

archive_command = '/bin/date'

若是要作hot standby這個必須大於0, 而且修改以後要重啓數據庫因此先設置爲32.

max_wal_senders = 32

這是個standby 數據庫參數, 爲了方便角色切換, 我通常是全部的數據庫都把他設置爲on 的.

hot_standby = on

這個參數是說數據庫中隨機的PAGE訪問的開銷佔seq_page_cost的多少倍 , seq_page_cost默認是1. 其餘的開銷都是seq_page_cost的倍數. 這些都用於基於成本的執行計劃選擇.

random_page_cost = 2.0

和上一個參數同樣, 用於基於成本的執行計劃選擇. 不是說會用多少cache, 它只是個度量值. 表示系統有多少內存能夠做爲操做系統的cache. 越大的話, 數據庫越傾向使用index這種適合random訪問的執行計劃.

effective_cache_size = 12000MB

下面是日誌輸出的配置.

log_destination = 'csvlog'

logging_collector = on

log_directory = '/var/applog/pg_log/digoal/1921'

log_truncate_on_rotation = on

log_rotation_age = 1d

log_rotation_size = 10MB

這個參數調整的是記錄執行時間超過1秒的SQL到日誌中, 通常用於跟蹤哪些SQL執行時間長.

log_min_duration_statement = 1000ms

記錄每一次checkpoint到日誌中.

log_checkpoints = on

記錄鎖等待超過1秒的操做, 通常用於排查業務邏輯上的問題.

log_lock_waits = on

deadlock_timeout = 1s

記錄DDL語句, 通常用於跟蹤數據庫中的危險操做.

log_statement = 'ddl'

這個本來是1024表示跟蹤的SQL在1024的地方截斷, 超過1024將沒法顯示全SQL. 修改成2048會消耗更多的內存(基本能夠忽略), 不過能夠顯示更長的SQL. 

track_activity_query_size = 2048

默認autovacuum就是打開的, log_autovacuum_min_duration = 0記錄全部的autovacuum操做.

autovacuum = on

log_autovacuum_min_duration = 0

這個模塊用於記錄數據庫中的最近的1000條SQL以及這些SQL的統計信息, 如執行了多少次, 總共耗時是多少. 通常用於發現業務上最頻繁調用的SQL是什麼, 有針對性的進行SQL優化.

shared_preload_libraries = 'pg_stat_statements'

custom_variable_classes = 'pg_stat_statements'

pg_stat_statements.max = 1000

pg_stat_statements.track = all