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