PostgreSQL 參數調整(性能優化)

  昨天分別在外網和無外網環境下安裝PostgreSQL，有外網環境下安裝的至關順利。可是在無外網環境下就是兩個不一樣的概念了，可謂十有八折。感興趣的同窗能夠搭建一下。

PostgreSQL安裝完成後第一件事即是作相關測試，而後調整參數。

/*CPU 查看CPU型號*/
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c /*查看物理CPU個數*/
cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l /*查看邏輯CPU個數*/
cat /proc/cpuinfo | grep "processor" | wc -l /*查看CPU內核數*/
cat /proc/cpuinfo | grep "cpu cores" | uniq  

/*查看單個物理CPU封裝的邏輯CPU數量*/
cat /proc/cpuinfo | grep "siblings" | uniq  

/*計算是否開啓超線程 ##邏輯CPU > 物理CPU x CPU核數 #開啓超線程 ##邏輯CPU = 物理CPU x CPU核數 #沒有開啓超線程或不支持超線程*/

/*查看是否超線程,若是cpu cores數量和siblings數量一致，則沒有啓用超線程，不然超線程被啓用。*/
cat /proc/cpuinfo | grep -e "cpu cores"  -e "siblings" | sort | uniq


/*內存 TOP /*命令常常用來監控linux的系統情況，好比cpu、內存的使用等。*/
/*查看某個用戶內存使用狀況,如:postgres*/ top -u postgres /* 內容解釋： 　　PID：進程的ID 　　USER：進程全部者 　　PR：進程的優先級別，越小越優先被執行 　　NInice：值 　　VIRT：進程佔用的虛擬內存 　　RES：進程佔用的物理內存 　　SHR：進程使用的共享內存 　　S：進程的狀態。S表示休眠，R表示正在運行，Z表示僵死狀態，N表示該進程優先值爲負數 　　%CPU：進程佔用CPU的使用率 　　%MEM：進程使用的物理內存和總內存的百分比 　　TIME+：該進程啓動後佔用的總的CPU時間，即佔用CPU使用時間的累加值。 　　COMMAND：進程啓動命令名稱 經常使用的命令： 　　P：按%CPU使用率排行 　　T：按MITE+排行 　　M：按%MEM排行 */

/*查看進程相關信息佔用的內存狀況，(進程號能夠經過ps查看)以下所示：*/ pmap -d 14596

ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' 
ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep postgres |  sort -nrk5 /*其中rsz爲實際內存，上例實現按內存排序，由大到小*/

/*看內存佔用*/
free -m /*看硬盤佔用率*/
df -h /*查看IO狀況*/ iostat -x 1 10
/* 若是 iostat 沒有，要 yum install sysstat安裝這個包，第一眼看下圖紅色圈圈的那個若是%util接近100%,代表I/O請求太多,I/O系統已經滿負荷，磁盤可能存在瓶頸,通常%util大於70%,I/O壓力就比較大，讀取速度有較多的wait，而後再看其餘的參數， 內容解釋: rrqm/s:每秒進行merge的讀操做數目。即delta(rmerge)/s wrqm/s:每秒進行merge的寫操做數目。即delta(wmerge)/s r/s:每秒完成的讀I/O設備次數。即delta(rio)/s w/s:每秒完成的寫I/0設備次數。即delta(wio)/s rsec/s:每秒讀扇區數。即delta(rsect)/s wsec/s:每秒寫扇區數。即delta(wsect)/s rKB/s:每秒讀K字節數。是rsec/s的一半，由於每扇區大小爲512字節 wKB/s:每秒寫K字節數。是wsec/s的一半 avgrq-sz:平均每次設備I/O操做的數據大小(扇區)。即delta(rsect+wsect)/delta(rio+wio) avgqu-sz:平均I/O隊列長度。即delta(aveq)/s/1000(由於aveq的單位爲毫秒) await:平均每次設備I/O操做的等待時間(毫秒)。即delta(ruse+wuse)/delta(rio+wio) svctm:平均每次設備I/O操做的服務時間(毫秒)。即delta(use)/delta(rio+wio) %util:一秒中有百分之多少的時間用於I/O操做,或者說一秒中有多少時間I/O隊列是非空的 */
/*找到對應進程*/ ll /proc/進程號/exe

 

瞭解到系統狀況後即可作相關合理的調整，以達到性能優化的目的。

 

1.shared_buffers
PostgreSQL既使用自身的緩衝區，也使用內核緩衝IO。這意味着數據會在內存中存儲兩次，首先是存入PostgreSQL緩衝區，而後是內核緩衝區。這被稱爲雙重緩衝區處理。對大多數操做系統來講，這個參數是最有效的用於調優的參數。此參數的做用是設置PostgreSQL中用於緩存的專用內存量。
shared_buffers的默認值設置得很是低，由於某些機器和操做系統不支持使用更高的值。但在大多數現代設備中，一般須要增大此參數的值才能得到最佳性能。
建議的設置值爲機器總內存大小的25％，可是也能夠根據實際狀況嘗試設置更低和更高的值。實際值取決於機器的具體配置和工做的數據量大小。舉個例子，若是工做數據集能夠很容易地放入內存中，那麼能夠增長shared_buffers的值來包含整個數據庫，以便整個工做數據集能夠保留在緩存中。
在生產環境中，將shared_buffers設置爲較大的值一般能夠提供很是好的性能，但應當時刻注意找到平衡點。
查看當前shared_buffers的值：

postgres=# show shared_buffers; shared_buffers ----------------
 128MB (1 row)

2.wal_buffers

PostgreSQL將其WAL（預寫日誌）記錄寫入緩衝區，而後將這些緩衝區刷新到磁盤。由wal_buffers定義的緩衝區的默認大小爲16MB，但若是有大量併發鏈接的話，則設置爲一個較高的值能夠提供更好的性能。
查看當前wal_buffers的值：

postgres=# show wal_buffers; wal_buffers -------------
 4MB (1 row)

 

3.effective_cache_size

effective_cache_size提供可用於磁盤高速緩存的內存量的估計值。它只是一個建議值，而不是確切分配的內存或緩存大小。它不會實際分配內存，而是會告知優化器內核中可用的緩存量。在一個索引的代價估計中，更高的數值會使得索引掃描更可能被使用，更低的數值會使得順序掃描更可能被使用。在設置這個參數時，還應該考慮PostgreSQL的共享緩衝區以及將被用於PostgreSQL數據文件的內核磁盤緩衝區。默認值是4GB。
查看當前effective_cache_size的值：

postgres=# show effective_cache_size; effective_cache_size ----------------------
 4GB (1 row)

4.work_mem

此配置用於複合排序。內存中的排序比溢出到磁盤的排序快得多，設置很是高的值可能會致使部署環境出現內存瓶頸，由於此參數是按用戶排序操做。若是有多個用戶嘗試執行排序操做，則系統將爲全部用戶分配大小爲work_mem *總排序操做數的空間。全局設置此參數可能會致使內存使用率太高，所以強烈建議在會話級別修改此參數值。默認值爲4MB。
查看當前work_mem的值：

postgres=# show work_mem; work_mem ----------
 4MB (1 row)

 

5.maintenance_work_mem
maintenance_work_mem是用於維護任務的內存設置。默認值爲64MB。設置較大的值對於VACUUM，RESTORE，CREATE INDEX，ADD FOREIGN KEY和ALTER TABLE等操做的性能提高效果顯著。
查看當前maintenance_work_mem的值：

postgres=# show maintenance_work_mem; maintenance_work_mem ----------------------
 64MB (1 row)

 

6.synchronous_commit

此參數的做用爲在向客戶端返回成功狀態以前，強制提交等待WAL被寫入磁盤。這是性能和可靠性之間的權衡。若是應用程序被設計爲性能比可靠性更重要，那麼關閉synchronous_commit。這意味着成功狀態與保證寫入磁盤之間會存在時間差。在服務器崩潰的狀況下，即便客戶端在提交時收到成功消息，數據也可能丟失。
查看當前synchronous_commit的設置值：

postgres=# show synchronous_commit; synchronous_commit --------------------
 on (1 row)

 

7.checkpoint_timeout和checkpoint_completion_target
PostgreSQL將更改寫入WAL。檢查點進程將數據刷新到數據文件中。發生CHECKPOINT時完成此操做。這是一項開銷很大的操做，整個過程涉及大量的磁盤讀/寫操做。用戶能夠在須要時隨時發出CHECKPOINT指令，或者經過PostgreSQL的參數checkpoint_timeout和checkpoint_completion_target來自動完成。
checkpoint_timeout參數用於設置WAL檢查點之間的時間。將此設置得過低會減小崩潰恢復時間，由於更多數據會寫入磁盤，但因爲每一個檢查點都會佔用系統資源，所以也會損害性能。此參數只能在postgresql.conf文件中或在服務器命令行上設置。
checkpoint_completion_target指定檢查點完成的目標，做爲檢查點之間總時間的一部分。默認值是 0.5。 這個參數只能在postgresql.conf文件中或在服務器命令行上設置。高頻率的檢查點可能會影響性能。
查看當前checkpoint_timeout和checkpoint_completion_target的值：

postgres=# show checkpoint_timeout;
 checkpoint_timeout 
--------------------
 5min
(1 row)

postgres=# show checkpoint_completion_target;
 checkpoint_completion_target 
------------------------------
 0.5
(1 row)

 

8.max_connections

容許客戶端鏈接的最大數目

 

9.fsync

強制把數據同步更新到磁盤,若是系統的IO壓力很大，把改參數改成off

在fsync打開的狀況下，優化後性能可以提高30%左右。由於有部分優化選項在默認的SQL測試語句中沒有體現出它的優點，若是到實際測試中，提高應該不止30%。
測試的過程當中，主要的瓶頸就在系統的IO，若是須要減小IO的負荷，最直接的方法就是把fsync關閉，可是這樣就會在掉電的狀況下，可能會丟失部分數據。

10.commit_delay

事務提交後，日誌寫到wal log上到wal_buffer寫入到磁盤的時間間隔。須要配合commit_sibling。可以一次寫入多個事務，減小IO，提升性能

 

11.commit_siblings

設置觸發commit_delay的併發事務數，根據併發事務多少來配置。減小IO，提升性能

注意：
並不是全部參數都適用於全部應用程序類型。某些應用程序經過調整參數能夠提升性能，有些則不會。必須針對應用程序及操做系統的特定需求來調整數據庫參數。

 下面介紹幾個我認爲重要的：

一、增長maintenance_work_mem參數大小

  增長這個參數能夠提高CREATE INDEX和ALTER TABLE ADD FOREIGN KEY的執行效率。

 

二、增長checkpoint_segments參數的大小

  增長這個參數能夠提高大量數據導入時候的速度。

 

三、設置archive_mode無效

  這個參數設置爲無效的時候，可以提高如下的操做的速度

  ・CREATE TABLE AS SELECT

  ・CREATE INDEX

  ・ALTER TABLE SET TABLESPACE

  ・CLUSTER等。

 

四、autovacuum相關參數 ( autovacuum介紹文章)

autovacuum：默認爲on，表示是否開起autovacuum。默認開起。特別的，當須要凍結xid時，儘管此值爲off，PG也會進行vacuum。 

autovacuum_naptime：下一次vacuum的時間，默認1min。 這個naptime會被vacuum launcher分配到每一個DB上。autovacuum_naptime/num of db。  

log_autovacuum_min_duration：記錄autovacuum動做到日誌文件，當vacuum動做超過此值時。 「-1」表示不記錄。「0」表示每次都記錄。  

autovacuum_max_workers：最大同時運行的worker數量，不包含launcher自己。  

autovacuum_work_mem    ：每一個worker可以使用的最大內存數。

autovacuum_vacuum_threshold    ：默認50。與autovacuum_vacuum_scale_factor配合使用， autovacuum_vacuum_scale_factor默認值爲20%。當update,delete的tuples數量超過autovacuum_vacuum_scale_factor*table_size+autovacuum_vacuum_threshold時，進行vacuum。若是要使vacuum工做勤奮點，則將此值改小。 

autovacuum_analyze_threshold        ：默認50。與autovacuum_analyze_scale_factor配合使用。

autovacuum_analyze_scale_factor     ：默認10%。當update,insert,delete的tuples數量超過autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold時，進行analyze。 

autovacuum_freeze_max_age：200 million。離下一次進行xid凍結的最大事務數。  

autovacuum_multixact_freeze_max_age：400 million。離下一次進行xid凍結的最大事務數。  

autovacuum_vacuum_cost_delay    ：若是爲-1，取vacuum_cost_delay值。 

autovacuum_vacuum_cost_limit       ：若是爲-1，到vacuum_cost_limit的值，這個值是全部worker的累加值。

 

PostgreSQL配置參數修改

1.修改配置文件

在配置文件C:\PostgreSQL\data\pg96\postgresql.conf 中直接修改，修改前記得備份一下原文件，由於你不知道意外和明天不知道哪一個會先來。修改完成以後，記得重啓數據庫哦。

2.命令行的修改方式

ALTER SYSTEM SET configuration_parameter { TO | = } { value | 'value' | DEFAULT }

 

例如：咱們如今要修改 maintenance_work_mem

--查看全部數據庫參數的值
show all; 
 show maintenance_work_mem; --注意這裏的設置不會改變postgresql.conf,只會改變postgresql.conf
ALTER SYSTEM SET maintenance_work_mem= 1048576; --重啓數據庫
show maintenance_work_mem; --取消postgresql.auto.conf的參數設置
ALTER SYSTEM SET maintenance_work_mem= default;

數據庫參數優化總結

max_connections = 300 # (change requires restart) unix_socket_directories = '.'   # comma-separated list of directories shared_buffers = 194GB # 儘可能用數據庫管理內存，減小雙重緩存，提升使用效率 huge_pages = on           # on, off, or try ，使用大頁 work_mem = 256MB # min 64kB ， 減小外部文件排序的可能，提升效率 maintenance_work_mem = 2GB  # min 1MB ， 加速創建索引 autovacuum_work_mem = 2GB   # min 1MB, or -1 to use maintenance_work_mem ， 加速垃圾回收 dynamic_shared_memory_type = mmap      # the default is the first option vacuum_cost_delay = 0      # 0-100 milliseconds ， 垃圾回收不妥協，極限壓力下，減小膨脹可能性 bgwriter_delay = 10ms       # 10-10000ms between rounds ， 刷shared buffer髒頁的進程調度間隔，儘可能高頻調度，減小用戶進程申請不到內存而須要主動刷髒頁的可能（致使RT升高）。 bgwriter_lru_maxpages = 1000   # 0-1000 max buffers written/round , 一次最多刷多少髒頁 bgwriter_lru_multiplier = 10.0          # 0-10.0 multipler on buffers scanned/round 一次掃描多少個塊，上次刷出髒頁數量的倍數 effective_io_concurrency = 2           # 1-1000; 0 disables prefetching ， 執行節點爲bitmap heap scan時，預讀的塊數。從而 wal_level = minimal         # minimal, archive, hot_standby, or logical ， 若是現實環境，建議開啓歸檔。 synchronous_commit = off    # synchronization level; ， 異步提交 wal_sync_method = open_sync    # the default is the first option ， 由於沒有standby，因此寫xlog選擇一個支持O_DIRECT的fsync方法。 full_page_writes = off      # recover from partial page writes ， 生產中，若是有增量備份和歸檔，能夠關閉，提升性能。 wal_buffers = 1GB           # min 32kB, -1 sets based on shared_buffers ，wal buffer大小，若是大量寫wal buffer等待，則能夠加大。 wal_writer_delay = 10ms         # 1-10000 milliseconds wal buffer調度間隔，和bg writer delay相似。 commit_delay = 20           # range 0-100000, in microseconds ，分組提交的等待時間 commit_siblings = 9        # range 1-1000 , 有多少個事務同時進入提交階段時，就觸發分組提交。 checkpoint_timeout = 55min  # range 30s-1h 時間控制的檢查點間隔。 max_wal_size = 320GB # 2個檢查點之間最多容許產生多少個XLOG文件 checkpoint_completion_target = 0.99     # checkpoint target duration, 0.0 - 1.0  ，平滑調度間隔，假設上一個檢查點到如今這個檢查點之間產生了100個XLOG，則此次檢查點須要在產生100*checkpoint_completion_target個XLOG文件的過程當中完成。PG會根據這些值來調度平滑檢查點。 random_page_cost = 1.0     # same scale as above , 離散掃描的成本因子，本例使用的SSD IO能力足夠好 effective_cache_size = 240GB # 可用的OS CACHE log_destination = 'csvlog'  # Valid values are combinations of logging_collector = on          # Enable capturing of stderr and csvlog log_truncate_on_rotation = on           # If on, an existing log file with the update_process_title = off track_activities = off autovacuum = on    # Enable autovacuum subprocess?  'on' autovacuum_max_workers = 4 # max number of autovacuum subprocesses ，容許同時有多少個垃圾回收工做進程。 autovacuum_naptime = 6s  # time between autovacuum runs ， 自動垃圾回收探測進程的喚醒間隔 autovacuum_vacuum_cost_delay = 0    # default vacuum cost delay for  ， 垃圾回收不妥協

 

其餘文章