昨天分別在外網和無外網環境下安裝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，提高性能
注意：
並非所有參數都適用於所有應用程序類型。某些應用程序通過調整參數可以提高性能，有些則不會。必須針對應用程序及操作系統的特定需求來調整數據庫參數。
下面介紹幾個我認為重要的：
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 ， 垃圾回收不妥協