?
This document uses PHP Chinese website manual Release
18.4. 資源消耗
18.4.1. 內存
- shared_buffers(integer)
-
設置數據庫服務器將使用的共享內存緩沖區(qū)數量。缺省通常是 4000(32MB)， 如果內核設置不支持這么大，那么可以少些(在initdb的時候決定)。 每個緩沖區(qū)大小的典型值是 8192 字節(jié)，除非你在編譯的時候修改了 BLCKSZ的值。這個數值必須大于 16 ，并且至少是 max_connections 數值的兩倍；不過，這個數值大一些通?？梢愿倪M性能。對于生產安裝， 我們通常建議至少是幾千。這個選項只能在服務器啟動的時候設置。
如果有專用的1GB或更多內存的數據庫服務器，一個合理的shared_buffers開始值可以是25%。 shared_buffers即使設置的很大，并且有效，同樣會造成一些工作負載， 但因為PostgreSQL同樣依賴操作系統(tǒng)緩沖區(qū)，shared_buffers 這是超過40%RAM不可能比一個小點值運行更快。為了在一個較長的時間里能更好的寫大量的新數據或修改舊數據， shared_buffers設置的越大， checkpoint_segments也會越大。
如果操作系統(tǒng)內存小于1GB，相應的內存要求也會降低，以為操作系統(tǒng)留下足夠的空間。 同時，在Windows上，shared_buffers設置的較大也不一定有效。 保持相對低的設置，同時使用更多的操作系統(tǒng)緩沖，此時可能會有不錯的效果。 Windows上可用的shared_buffers值時從64MB到512MB。
增大這個參數可能導致PostgreSQL要求更多 System V共享內存，可能超出操作系統(tǒng)配置 許可的范圍。必要時請參閱節(jié)Section 17.4.1獲取如何調整這些 參數的信息。
- temp_buffers(integer)
-
設置每個數據庫會話使用的臨時緩沖區(qū)的最大數目。這些都是會話的本地緩沖 區(qū)，只用于訪問臨時表。缺省是 1000(8MB) 。這個設置可以在 獨立的會話內部設置，但是只有在會話第一次使用臨時表的時候才能增長； 企圖在該會話里隨后改變該數值是無效的。
一個會話將按照temp_buffers給出的限制，根據需要分配臨時 緩沖區(qū)。如果在一個并不需要大量臨時緩沖區(qū)的會話里設置一個大的數值， 其開銷只是一個緩沖區(qū)描述符，或者說每個temp_buffers 增加大概 64 字節(jié)。不過，如果一個緩沖區(qū)實際上被使用，那么就會額外消耗 8192 字節(jié)(或者說是BLCKSZ字節(jié))。
- max_prepared_transactions(integer)
-
設置可以同時處于"prepared"狀態(tài)的事務的最大數目 (參閱PREPARE TRANSACTION)。把這個參數設置 為零（這是默認設置）則關閉預備事務的特性。這個值只能在服務器啟動 的時候設置。
如果不打算使用prepared狀態(tài)的事務，可以把這個參數設置為0，防止意外創(chuàng)建prepared狀態(tài)的事務。 如果正在使用這種事務，將max_prepared_transactions設置為 max_connections中的值，因此每一個會話可以有一個prepared事務等待。
增加這個參數可能會導致PostgreSQL要求比缺省的操作 系統(tǒng)配置的更多的System V共享內存。 必要時請參閱節(jié)16.4.1Section 17.4.1獲取有關如何調節(jié)這個參數 的信息。
當運行一個備庫時，這個參數必須至少與主庫上的一樣大，否則，備庫上將不會執(zhí)行查詢。
- work_mem(integer)
聲明內部排序操作和 Hash 表在開始使用臨時磁盤文件之前使用的內存數目。 數值是以千字節(jié)為單位的，缺省是 1024 千字節(jié)(1MB)。 請注意對于復雜的查詢， 可能會同時并發(fā)運行好幾個排序或者散列操作；每次運行都會被批準使用這個參數 聲明的這么多內存，然后才會開始求助于臨時文件。同樣，好幾個正在運行的 會話可能會同時進行排序操作。因此使用的總內存可能是work_mem 的好幾倍。ORDER BY，DISTINCT和融合連接都要 用到排序操作。 Hash 表在散列連接、散列為基礎的聚集、散列為基礎的 IN子查詢處理中都要用到。
- maintenance_work_mem(integer)
-
聲明在維護性操作(比如VACUUM，CREATE INDEX， 和ALTER TABLE ADD FOREIGN KEY等)中使用的 最大的內存數。數值是用千字節(jié)計的，缺省是 16384 千字節(jié) (16MB)。因為在一個數據庫會話里，任意時刻只有一個這樣的 操作可以執(zhí)行，并且一個數據庫安裝通常不會有太多這樣的工作并發(fā)執(zhí)行， 把這個數值設置得比work_mem更大是安全的。 更大的設置可以改進清理和恢復數據庫轉儲的速度。
需要注意的是，當自動vacuum運行時，達到autovacuum_max_workers的時間，這個內存會被分配， 因此不要講缺省值設置很大。
- max_stack_depth(integer)
-
聲明服務器的執(zhí)行堆棧的最大安全深度。為此設置一個參數的原因是內核強制 的實際堆棧尺寸(就是ulimit -s或者局部等效物的設置)小于 安全的一兆字節(jié)左右的范圍。需要這個安全界限是因為在服務器里，并非所有 過程都檢查了堆棧深度，只是在可能遞規(guī)的過程，比如表達式計算這樣的過程 里面才進行檢查。缺省設置是 2048kB(2MB)，這個值相對比較小 ，不容易導致崩潰。但是，這個值可能太小了，以至于無法執(zhí)行復雜的函數。
把max_stack_depth參數設置得大于實際的內核限制意味著一個 正在運行的遞歸函數可能會導致一個獨立的服務器進程的崩潰。 在PostgreSQL能夠檢測內核限制的平臺上， 將不允許你將其設置為一個不安全的值。因為并非所有平臺都能夠檢測， 所以還是建議你在此設置一個明確的值。
18.4.2. 內核資源的使用
- max_files_per_process(integer)
設置每個服務器進程允許同時打開的最大文件數目。缺省是 1000 。 如果內核強制一個合理的每進程限制，那么你不用操心這個設置。但是在 一些平臺上(特別是大多數 BSD 系統(tǒng))，內核允許獨立進程打開比個系統(tǒng) 真正可以支持的數目大得多得文件數。如果你發(fā)現(xiàn)有"Too many open files"這樣的失敗現(xiàn)像，那么就嘗試縮小這個設置。這個值只能在服務器 啟動的時候設置。
- shared_preload_libraries(string)
-
這個變量聲明一個或者多個在服務器啟動的時候預先裝載的共享庫啟動。 比如'$libdir/mylib'可能會造成mylib.so(或mylib.sl) 從安裝的標準庫目錄預安裝。所有庫的名字會被轉換成小寫，除非使用了雙引號。 如果載入多個庫，那么用逗號將它們的名字隔開。 這個值只能在服務器啟動的時候設置。
可以用這個方法預先裝載PostgreSQL的過程 語言庫，通常是使用'$libdir/plXXX'語法，這里的 XXX是pgsql，perl，tcl，或python之一。
通過預先裝載一個共享庫(以及在需要的時候初始化它)，我們就可以避免 第一次使用這個庫的加載時間。不過，啟動每個服務器進程的時間可能會 增加，即使進程從來沒有使用過這些庫也這樣。因此我們只是建議對那些 將被大多數會話使用的庫才使用這個選項。
Note: 在Windows主機上，服務器啟動時預裝庫不會減少開始每個新的服務器進程所需的時間； 每個服務器進程會載入所有的預裝庫。然而，shared_preload_libraries在Windows主機上 仍然是有用的，因為在postmaster啟動時，一些共享庫可能需要執(zhí)行某些操作。 （比如，一個共享庫可能需要存儲輕量級鎖或共享內存，而postmaster已經啟動后卻做不到）。
如果沒有找到聲明的庫，那么服務器啟動將失敗。
每一個支持 PostgreSQL 的庫都有一個"magic block"用于保證兼容性。因此，不支持PostgreSQL的庫不能用 這種辦法加載。
18.4.3. 基于開銷的清理延遲
在VACUUM和ANALYZE命令 執(zhí)行過程中，系統(tǒng)維護一個內部的記數器，跟蹤所執(zhí)行的各種 I/O 操作的 近似開銷。如果積累的開銷達到了vacuum_cost_limit 聲明的限制，那么執(zhí)行這個操作的進程將睡眠vacuum_cost_limit 指定的時間。然后它會重置記數器然后繼續(xù)執(zhí)行。
這個特性的目的是允許管理員減少這些命令在并發(fā)活動的數據庫上的 I/O 影響。 比如，像VACUUM和ANALYZE這樣 的維護命令并不需要迅速完成，并且不希望它們嚴重干擾系統(tǒng)執(zhí)行其它的數據庫 操作。基于開銷的清理延遲為管理員提供了一個實現(xiàn)這個目的的手段。
這個特性是缺省關閉的。此功能默認情況下禁用手動發(fā)出VACUUM 命令，要想打開它，把vacuum_cost_delay變量設置為一個非零值。
- vacuum_cost_delay(integer)
-
以毫秒計的時間長度，如果超過了開銷限制，那么進程將睡眠一會兒。 缺省值 0 關閉基于開銷的清理延遲特性。正數值打開基于開銷的清理。 不過，要注意在許多系統(tǒng)上，睡眠的有效分辨率是 10 毫秒； 把vacuum_cost_delay設置為一個不是 10 的整數倍 的數值與將它設置為下一個 10 的整數倍作用相同。
當使用基于花費的vacuum時，vacuum_cost_delay的適當的值通常很小， 也許是10或20毫秒。通過調整另一個vacuum的cost參數，可以很好的調整vacuum的資源消耗
- vacuum_cost_page_hit(integer)
清理一個在共享緩存里找到的緩沖區(qū)的預計開銷。它代表鎖住緩沖池、 查找共享的 Hash 表、掃描頁面內容的開銷。缺省值是 1 。
- vacuum_cost_page_miss(integer)
清理一個要從磁盤上讀取的緩沖區(qū)的預計開銷。它代表鎖住緩沖池、 查找共享 Hash 表、從磁盤讀取需要的數據塊、掃描它的內容的開銷。 缺省值是 10
- vacuum_cost_page_dirty(integer)
清理修改一個原先是干凈的塊的預計開銷。它代表把一個臟的磁盤塊再次 刷新到磁盤上的額外開銷。缺省值是 20 。
- vacuum_cost_limit(integer)
導致清理進程休眠的積累開銷。缺省是 200 。
Note: 有些操作會持有關鍵的鎖，并且應該盡快結束。在這樣的操作過程中，基于 開銷的清理延遲不會發(fā)生作用。為了避免在這種情況下的長延時，實際的 延遲是vacuum_cost_delay* accumulated_balance/ vacuum_cost_limit與 vacuum_cost_delay* 4.兩者之間的最大值。
18.4.4. Background Writer
有一個獨立的服務器進程，叫做background writer，它唯一 的功能就是發(fā)出寫"臟"共享緩沖區(qū)的命令。這么做的目的是讓持有用戶查詢的 服務器進程應該很少或者幾乎不等待寫動作的發(fā)生，因為后端寫進程會做 這件事情。這樣的安排同樣也減少了檢查點造成的性能下降。后端寫進程將 持續(xù)的把臟頁面刷新到磁盤上，所以在檢查點到來的時候，只有幾個頁面需要 刷新到磁盤上。但是這樣還是增加了 I/O 的總凈負荷，因為以前的檢查點間隔 里，一個重復弄臟的頁面可能只會沖刷一次，而同一個間隔里，后端寫進程 可能會寫好幾次。在大多數情況下，連續(xù)的低負荷要比周期性的尖峰負荷好， 但是在本節(jié)討論的參數可以用于按實際需要調節(jié)其行為。
- bgwriter_delay(integer)
聲明后端寫進程活躍輪回之間的延遲。在每個輪回里，寫進程都會為一些臟 的緩沖區(qū)發(fā)出寫操作(可以用下面的參數控制)。然后它就休眠 bgwriter_delay毫秒(缺省值是200ms)， 然后重復動作。 請注意在許多系統(tǒng)上，休眠延時的有效分辨率是 10 毫秒；因此，設置一個 不是10的倍數的數值與把它設置為下一個10的倍數是一樣的效果。 這個選項只能在服務器啟動的時候或者在postgresql.conf文件里設置。
- bgwriter_lru_maxpages(integer)
在每個輪回里，不超過這么多個緩沖區(qū)將做為掃描到的即將回收使用的緩沖區(qū) 寫入磁盤。缺省值是 100 。這個選項只能在服務器啟動的時候或者在 postgresql.conf文件里設置。
- bgwriter_lru_multiplier(floating point)
每一輪要寫的臟緩沖區(qū)的數目是根據最近幾輪服務器進程需要的新的緩沖區(qū)的數目。 最近的平均值*bgwriter_lru_multiplier以估算下一輪需要的緩沖區(qū)數目。 直到有那許多干凈可重用緩沖區(qū)時，臟緩沖區(qū)寫入 （然而，達不到bgwriter_lru_maxpages時，會在每一輪都寫入）。 因此，設置為1.0表示要寫入的，預計需要的緩沖區(qū)的準確數目的時間策略。 較大的值可以提供在需求高峰時的一個緩沖，而較小的值則需要服務進程來處理一些寫操作。 缺省值是2.0。這個選項只能在服務器啟動的時候或者在postgresql.conf 文件里設置。
較小的bgwriter_lru_maxpages和bgwriter_lru_multiplier 可以降低由bgwriter進程造成的額外的I/O開銷。但更可能的是，服務器進程自己進行問題寫入，拖延了交互式查詢。
18.4.5. 異步行為
- effective_io_concurrency(integer)
-
設置并發(fā)磁盤I/O操作的數量，那么一些任務可以同時執(zhí)行。 調高這個值，可以增加I/O操作的數目（試圖發(fā)起并行連接會話的數目）。 允許的范圍是1到100，或0（禁用異步I/O請求）。
一個很好的設置是組成一個RAID 0條帶或RAID 1鏡像用于數據庫的單獨的驅動器數量。 （對RAID 5而言，不應計入的奇偶校驗驅動器）然而， 如果數據庫忙于在并發(fā)會話中多個查詢，較低的值可能會使磁盤陣列繁忙。一個比 保持磁盤工作的需要值更高的值只會造成額外的CPU開銷。
對特殊的系統(tǒng)（如，總線帶寬限制基于內存的存儲或RAID陣列）來說，有效值可能是 可用的I/O路徑數。當然，需要一些實驗來找出最佳值。
異步I/O是居于一個有效的
posix_fadvise函數（一些操作系統(tǒng)可能沒有） 如果沒有這個函數，那么這個參數設置為0。在一些操作系統(tǒng)上（如Solaris），雖然提供了 這個函數，但它不會做任何事情。