17.4. 管理內核資源 · PostgreSQL 中文文檔 9.3

# 17.4\. 管理內核資源 PostgreSQL有時可能耗盡各種操作系統的資源上限，尤其是多個服務器副本在同一個系統上運行時，或者在一個非常大的安裝時。這種情況說明了PostgreSQL 使用的內核資源和解決問題可以采取的步驟都和內核資源消耗有關。 ## 17.4.1\. 共享內存和信號燈共享內存和信號燈的正確叫法是"System V IPC" (還有消息隊列，不過與PostgreSQL無關)。， PostgreSQL只在Windows上自己提供這套機制的替換實現，要運行PostgreSQL這些機制是必需的。完全缺少這些機制的表現通常是在服務器啟動時的Illegal system call錯誤。這時除了重新配置內核外別無選擇。PostgreSQL沒它們干不了活。這種情況很少見，但是，在現代操作系統上會出現。如果PostgreSQL超出了這些IPC資源的硬限制之一的時候就會拒絕啟動，并且留下一條相當有啟發性的錯誤信息，描述問題以及需要為它做些什么 (又見[Section 17.3.1](#calibre_link-1336))。相關的內核參數在不同系統之間有著相對固定的術語； [Table 17-1](#calibre_link-1371)是一個概況。不過，設置它們的方法卻多種多樣。下面給出一些平臺的建議。 > **Note:** PostgreSQL 9.3之前，System V共享內存的數量需要啟動的服務器大得多。如果你運行更老的服務器版本，請參考你的服務器版本的文檔。 **Table 17-1\. System V IPC參數** | 名字 | 描述 | 合理取值 | | --- | --- | --- | | `SHMMAX` | 最大共享內存段尺寸(字節) | 至少 1kB (如果運行多個服務器副本需要更多) | | `SHMMIN` | 最小共享內存段尺寸(字節) | 1 | | `SHMALL` | 可用共享內存的總數量(字節或者頁面) | 如果是字節，就和`SHMMAX`一樣；如果是頁面，`ceil(SHMMAX/PAGE_SIZE)` | | `SHMSEG` | 每進程最大共享內存段數量 | 只需要 1 個段，不過缺省比這高得多。 | | `SHMMNI` | 系統范圍最大共享內存段數量 | 類似`SHMSEG`加上用于其它應用的空間 | | `SEMMNI` | 信號燈標識符的最小數量(也就是套) | 至少`ceil((max_connections + autovacuum_max_workers + 4) / 16)` | | `SEMMNS` | 系統范圍的最大信號燈數量 | `ceil((max_connections + autovacuum_max_workers + 4) / 16) * 17`加上用于其它應用的空間 | | `SEMMSL` | 每套信號燈最小信號燈數量 | 至少 17 | | `SEMMAP` | 信號燈映射里的記錄數量 | 參閱本文 | | `SEMVMX` | 信號燈的最大值 | 至少 1000 ，缺省通常是 32767 ，除非被迫，否則不要修改 | PostgreSQL的每個服務器的副本需要System V共享內存的少許字節（在64為平臺上典型為48字節）。在大多數現在的操作系統上，可以很容易的分配數量。然而，如果你運行了服務器的多個副本，或者其他應用也使用System V共享內存，那么增大`SHMMAX`可能是必要的，共享內存段或`SHMALL` 的最大字節大小，為系統范圍System V共享內存的總數量。注意`SHMALL` 在許多系統上是用頁面數而不是字節數來計算的。不太可能出問題的是共享內存段的最小尺寸(`SHMMIN`)，對PostgreSQL 來說大約是32字節左右(通常只是 1)，而系統范圍(`SHMMNI`)或每進程(`SHMSEG`) 最大共享內存段數量不應該會產生問題，除非你的系統把它們設成零。 PostgreSQL每個允許的連接使用一個信號燈([max_connections](#calibre_link-441))，并且允許autovacuum工作進程([autovacuum_max_workers](#calibre_link-1372))，以 16 個為一套。每套信號燈還包含第 17 個信號燈，它里面存儲一個"magic number"，以檢測和其它應用使用的信號燈集沖突。系統里的最大信號燈數目是由`SEMMNS`設置的，因此這個值應該至少和`max_connections`加上`autovacuum_max_workers`設置一樣大，并且每 16 個連接和工作還要另外加一個(參閱[Table 17-1](#calibre_link-1371)里面的公式)。參數`SEMMNI`決定系統里一次可以存在的信號燈集的數目。因此這個參數至少應該為`ceil((max_connections + autovacuum_max_workers + 4) / 16)`。降低允許的連接數目是一個臨時的繞開失敗的方法，這個啟動失敗通常被來自函數`semget` 的錯誤響應"No space left on device"搞得很讓人迷惑。有時候還可能有必要增大`SEMMAP`，使之至少按照`SEMMNS`配置。這個參數定義信號燈資源映射的尺寸，可用的每個連續的信號燈塊在這個映射中存放一條記錄。每當一套信號燈被釋放，那么它要么會加入到該映射中一條相連的已釋放塊的入口中，要么注冊成一條新的入口。如果映射填滿了碎片，那么被釋放的信號燈就丟失了(除非重啟)。因此信號燈空間的碎片時間長了會導致可用的信號燈比應該有的信號燈少。 `SEMMSL`參數決定一套信號燈里可以有多少信號燈，對于PostgreSQL而言應該至少是 17 。許多設置與"semaphore undo"(信號燈恢復)有關，比如`SEMMNU`和`SEMUME`，這些與PostgreSQL無關。 AIX 至少對于版本 5.1 而言，我們沒有必要為類似`SHMMAX`這樣的參數做特殊的配置，因為這個參數可以配置為所有內容都當作共享內存使用。這就是類似DB/2 這樣的數據庫常用的配置。不過，我們可能有必要在`/etc/security/limits`里面修改全局`ulimit`信息，因為文件大小的缺省硬限制(`fsize`)以及文件數(`nofiles`)可能太低了。 FreeBSD 缺省設置可以用`sysctl`或`loader`接口來修改。下面的參數可以用`sysctl`設置： ``` <samp class="literal">#</samp> <kbd class="literal">sysctl kern.ipc.shmall=32768</kbd> <samp class="literal">#</samp> <kbd class="literal">sysctl kern.ipc.shmmax=134217728</kbd> <samp class="literal">#</samp> <kbd class="literal">sysctl kern.ipc.semmap=256</kbd> ``` 要想讓這些設置重啟后有效，修改`/etc/sysctl.conf`文件。如果用`sysctl`，那么剩下的信號燈設置是只讀的，但是可以在`/boot/loader.conf`里設置： ``` kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 ``` 修改完這些值以后需要重啟以使新的設置生效。你可能還想配置內核，把共享內存鎖到 RAM 里，避免他們被交換到交換分區中。這些可以通過使用`sysctl`設置`kern.ipc.shm_use_phys`來完成。如果通過啟用sysctl的`security.jail.sysvipc_allowed`運行在 FreeBSD jail 中，那么必須將postmaster以不同的用戶身份運行在不同的 jail 中。這樣有助于增強安全性，因為它防止了非 root 用戶干擾不同 jail 中的共享內存或信號燈，并且允許 PostgreSQL IPC 清理代碼功能。在 FreeBSD 6.0 及之后的版本中，IPC 清理代碼并不能正確偵測在其它 jail 中的進程，因此無法防止其它 jail 中的 postmaster 進程占用相同的端口。 FreeBSD 4.0 之前的版本類似OpenBSD(見下文)。 NetBSD NetBSD 5.0及以后，IPC參數可以用`sysctl`調整，例如： ``` <samp class="literal">$</samp> <kbd class="literal">sysctl -w kern.ipc.shmmax=16777216</kbd> ``` 要想讓這些設置重啟后有效，修改`/etc/sysctl.conf`文件。你可能還想配置內核，把共享內存鎖到 RAM 里，避免他們被交換到交換分區中。這些可以通過使用`sysctl`設置`kern.ipc.shm_use_phys`來完成。 NetBSD 4.0 之前的版本類似OpenBSD(見下文)，除了參數應該用關鍵字`options`而不是`option`來設置。 OpenBSD 編譯內核時需要把選項`SYSVSHM`和`SYSVSEM`打開(缺省是打開的)。共享內存的最大尺寸是由選項`SHMMAXPGS`(以頁計)決定的。下面顯示了一個如何設置這些參數的例子： ``` option SYSVSHM option SHMMAXPGS=4096 option SHMSEG=256 option SYSVSEM option SEMMNI=256 option SEMMNS=512 option SEMMNU=256 option SEMMAP=256 ``` 你可能還想配置內核，把共享內存鎖在 RAM 中以避免它們被交換出去，我們可以通過使用`sysctl`設置`kern.ipc.shm_use_phys`來完成。 HP-UX 缺省設置看來對普通安裝是足夠的了。對于HP-UX 10 ， `SEMMNS`的出廠缺省是 128 ，可能對大的數據庫節點來說太小了。 IPC可以在System Administration Manager(SAM)下面的 Kernel Configuration->Configurable Parameters配置。配置完了以后選擇Create A New Kernel選項。 Linux 缺省最大段大小為32MB，缺省的最大總字節為2097152頁。一頁通常是4096字節，除了帶有"huge pages"的不尋常的內核配置（使用`getconf PAGE_SIZE`來校驗）。共享內存大小設置可以通過`sysctl`接口改變。例如，要允許16 GB: ``` <samp class="literal">$</samp> <kbd class="literal">sysctl -w kernel.shmmax=17179869184</kbd> <samp class="literal">$</samp> <kbd class="literal">sysctl -w kernel.shmall=4194304</kbd> ``` 為了這些設置在重啟后保持有效，將這些設置放到`/etc/sysctl.conf`里。這樣做是高度推薦的。老版本里可能沒有`sysctl`程序，但是同樣的改變可以通過操作`/proc`文件系統來做： ``` <samp class="literal">$</samp> <kbd class="literal">echo 17179869184 >/proc/sys/kernel/shmmax</kbd> <samp class="literal">$</samp> <kbd class="literal">echo 4194304 >/proc/sys/kernel/shmall</kbd> ``` 剩下的缺省是相當寬松的大小，通常不需要改變。 Mac OS X 在 OS X 中配置共享內存推薦的方法是創建一個名為`/etc/sysctl.conf`的文件，包含變量賦值，例如： ``` kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024 ``` 注意在某些OS X版本里，_所有五個_共享內存參數必須都在 `/etc/sysctl.conf`中設置，否則將會被忽略。還要注意最近版本的 OS X 將拒絕把`SHMMAX`的數值設置為非 4096 的倍數。在這個平臺上，`SHMALL`是用 4KB 頁來度量的。在老的OS X版本里，你將需要重啟以使共享內存配置的改變生效。自OS X 10.5起，在運行中修改除了 `SHMMNI`的所有參數成為可能，使用sysctl。但是通過`/etc/sysctl.conf` 來設置你喜歡的數值仍然是最好的，因為這樣這些數值在重啟以后仍然保留。文件`/etc/sysctl.conf`只在OS X 10.3.9及以后的版本中遵守。如果你正在運行一個10.3.x之前的版本，你必須編輯文件`/etc/rc`并在下列的命令中改變數值。 ``` sysctl -w kern.sysv.shmmax sysctl -w kern.sysv.shmmin sysctl -w kern.sysv.shmmni sysctl -w kern.sysv.shmseg sysctl -w kern.sysv.shmall ``` 注意`/etc/rc`通常通過OS X系統更新重寫，所以你應該預料到在每次更新后必須重做這些編輯。在OS X 10.2以及更早的版本里，在`/System/Library/StartupItems/SystemTuning/SystemTuning` 里編輯這些命令。 SCO OpenServer 缺省配置時，只允許每段 512KB 共享內存。要增大設置，首先進入`/etc/conf/cf.d`目錄。要顯示當前以字節記的`SHMMAX`，運行： ``` ./configure -y SHMMAX ``` 設置`SHMMAX`的新值： ``` ./configure SHMMAX=_value_ ``` 這里`_value_`是你想設置的以字節記的新值。設置完`SHMMAX`以后重新編譯內核： ``` ./link_unix ``` 然后重啟。 Solaris 2.6 到 2.9 (Solaris 6 到 Solaris 9) 相關的設置可以在`/etc/system`里面修改，例如： ``` set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=512 set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32 ``` 你需要重啟以使這些修改生效。又見[http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html](http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html) 獲取關于老版本的Solaris共享內存的信息。 Solaris 2.10 (Solaris 10) 及以后 OpenSolaris Solaris 10及以后的版本，以及OpenSolaris，缺省的共享內存和信號燈的設置對大多數PostgreSQL 應用來說是足夠的。Solaris現在對`SHMMAX`的缺省是系統RAM的四分之一。要進一步調整這些設置，使用一個和`postgres`用戶相關的項目設置。例如，作為`root` 運行下列命令： ``` projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres user.postgres ``` 這些命令增加`user.postgres`項目并且設置`postgres`用戶的最大共享內存為8GB，在下次用戶登錄時生效，或當你重啟PostgreSQL（不是重新加載）生效。上面的是假設PostgreSQL由在`postgres`組里面的`postgres`用戶運行。不需要服務器重啟。其他推薦的數據庫服務器的內核設置修改將有大量的連接： ``` project.max-shm-ids=(priv,32768,deny) project.max-sem-ids=(priv,4096,deny) project.max-msg-ids=(priv,4096,deny) ``` 此外，如果你在一個區域里面運行PostgreSQL，你可能也需要提高區域資源使用的限制。參閱_System Administrator's Guide_里面的"Chapter2: Projects and Tasks" 獲取更多關于`projects`和`prctl`的信息。 UnixWare 在UnixWare 7 上，缺省配置里的最大共享內存段是 512kB 。要顯示`SHMMAX`的當前值，運行： ``` /etc/conf/bin/idtune -g SHMMAX ``` 就會顯示以字節記的當前的缺省的最小和最大值。要給`SHMMAX`設置一個新值，運行： ``` /etc/conf/bin/idtune SHMMAX _value_ ``` `_value_`是你想設置的以字節記的新值。設置完`SHMMAX`后，重建內核： ``` /etc/conf/bin/idbuild -B ``` 然后重啟。 ## 17.4.2\. 資源限制 Unix 類系統強制了許多資源限制，這些限制可能干擾PostgreSQL服務器的運行。這里尤其重要是對每個用戶的進程數目的限制、每個進程打開文件數目、以及每個進程可用的內存。這些限制中每個都有一個"硬"限制和一個"軟"限制。實際使用的是軟限制，但用戶可以自己修改成最大為硬限制的數目。而硬限制是只能由 root 用戶修改的限制。系統調用`setrlimit`負責設置這些參數。shell 的內建命令`ulimit` (Bourne shells) 或`limit`(csh) 就是用于在命令行上控制資源限制的。在 BSD 衍生的系統上，`/etc/login.conf`文件控制在登錄時對各種資源設置什么樣的限制數值。參閱操作系統文檔獲取細節。相關的參數是`maxproc`,`openfiles`, `datasize` 。比如： ``` default:\ ... :datasize-cur=256M:\ :maxproc-cur=256:\ :openfiles-cur=256:\ ... ``` `-cur`是軟限制，后面附加`-max`就可以設置硬限制。內核通常也有一些系統范圍的資源限制。 * 在Linux上，`/proc/sys/fs/file-max` 決定內核可以支持的最大文件數。你可以通過往該文件寫入一個不同的數值修改此值，或者在`/etc/sysctl.conf`里增加一個賦值。每個進程的最大打開文件限制是在編譯內核的時候固定的；參閱`/usr/src/linux/Documentation/proc.txt`獲取更多信息。 PostgreSQL服務器每個連接都使用一個進程，所以你應該至少允許和連接數相同的進程數，再加上系統其它部分所需要的數目。通常這個并不是什么問題，但如果你在一臺機器上運行多個服務器，那你就要把事情理清楚。打開文件數目的出廠缺省設置通常設置為"社會友好"數值，就是說允許許多用戶共存一臺機器，而不會導致系統資源使用的不當比例。如果你在一臺機器上運行許多服務器，這也許就是你想要的，但是在特殊的服務器上，你可能需要提高這個限制。問題的另外一邊，一些系統允許獨立的進程打開非常多的文件；如果有幾個進程這么干，那系統范圍的上限就很容易達到。如果你發現這樣的現像，并且不想修改系統范圍的限制，你就可以設置PostgreSQL的[max_files_per_process](#calibre_link-1373) 配置參數來限制打開文件數的消耗。 ## 17.4.3\. Linux 內存過提交在Linux 2.4 以及之后的版本里，缺省的虛擬內存的行為不是對PostgreSQL最優的。原因在于內核實現內存過提交的方法，如果其它進程的內存請求導致系統用光虛擬內存，那么內核可能會終止PostgreSQL主服務器進程。如果發生了這樣的事情，你會看到像下面這樣的內核信息(參考你的系統文檔和配置，看看在哪里能看到這樣的信息)： ``` Out of Memory: Killed process 12345 (postgres). ``` 這表明`postgres`因為內存壓力而終止了。盡管現有的數據連接將繼續正常運轉，但是新的連接將無法接受。要想恢復，你應該重啟PostgreSQL。一個避免這個問題的方法是在一臺你確信不會因為其它進程而耗盡內存的機器上運行PostgreSQL。如果PostgreSQL本身是系統耗盡內存的原因，你可以通過改變你的配置來避免這個問題。在某些情況下，這樣可能幫助降低內存相關的配置參數，尤其是[`shared_buffers`](#calibre_link-1370) 和[`work_mem`](#calibre_link-1374)。其他情況下，這個問題可能是由于允許太多的連接到數據庫服務器本身引起的。在許多情況下，減少[`max_connections`](#calibre_link-441) 而不是利用外部連接池的軟件會更好。在 Linux 2.6 以及以后的版本里，可以修改內存的行為，這樣它就不會再"過提交"內存。盡管這個設置將不會完全阻止[OOM killer](http://lwn.net/Articles/104179/) 被引用，然是它將顯著地減少并且將因此導致更穩健的系統行為。這是通過用`sysctl`選取一個嚴格的過提交模式實現的： ``` sysctl -w vm.overcommit_memory=2 ``` 或者在`/etc/sysctl.conf`里放一個等效的條目。你可能還希望修改相關的 `vm.overcommit_ratio`設置。詳細信息請參閱內核文檔的 `Documentation/vm/overcommit-accounting`文件。另外一種方法，改變或不改變`vm.overcommit_memory`都可以使用，設置與進程相關的`oom_score_adj`值為主進程`-1000`，從而保證它不會成為OOM killer的目標。最簡單的方法是在調用postmaster之前在postmaster的啟動腳本執行： ``` echo -1000 > /proc/self/oom_score_adj ``` 請注意，這個操作必須由root來做，否則將不會有任何作用；所以一個root所有的啟動腳本是做這個最簡單的地方。如果你這樣做，你可能也希望用`-DLINUX_OOM_SCORE_ADJ=0`添加到`CPPFLAGS` 來建立PostgreSQL。這將導致主子進程以標準`oom_score_adj`值0來運行，所以OOM killer仍然可以在需要時以它們為目標。老版本的Linux內核不提供`/proc/self/oom_score_adj`，但是可能有相同功能的名為 `/proc/self/oom_adj`的以前的版本。除了禁用值為`-17`而不是`-1000` 外，它們做相同的工作。相應的PostgreSQL的建立標識為`-DLINUX_OOM_ADJ=0`。 > **Note:** 有些供應商的 Linux 2.4 內核有著早期 2.6 過提交的`sysctl`。不過，在沒有相關代碼的2.4內核里設置`vm.overcommit_memory`為 2 只會讓事情更糟，而不是更好。我們建議你檢查一下實際的內核源代碼(參閱文件`mm/mmap.c` 里面的`vm_enough_memory`函數)，核實一下這個是在你的內核里存在的，然后再在 2.4 內核里使用這個特性。文檔文件`overcommit-accounting` 的存在_不能_當作是這個特性存在的證明。如果有問題，請詢問你的內核供應商的專家。