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