天天看點

調整應用程式服務環境,何時執行任務

要優化您的 WebSphere Application Servers 達到它們最完全的擴充,除了在調整參數活動表中和調整性能參數索引中建議的過程和參數以外,使用性能顧問程式。

性能顧問程式

性能顧問程式使用性能監控基礎結構(PMI)資料來建議對對象請求代理程式(ORB)服務線程池、Web 容器線程池、連接配接池大小、持久的會話大小和時間以及預編譯語句高速緩存大小作出配置更改。Runtime Performance Advisor 在應用程式伺服器程序中運作,而另一個顧問程式在 Tivoli Performance Viewer(TPV)中運作。要擷取更多資訊,請參閱文章(使用 Runtime Performance Advisor和使用 Tivoli Performance Viewer 中的性能顧問程式)。

調整參數活動表

檢視調整參數活動表,它是調整參數索引的子集。這些熱門參數對于性能的影響重大。

調整指南主要針對伺服器調整。如果您要調整應用程式,請參閱性能:學習資源一文以擷取關于調整應用程式的更多資訊。

友善起見,包含了調整其他産品(如 DB2)、Web 伺服器和作業系統中的參數的過程。因為這些産品可能更改,是以請将這些描述作為建議考慮。

每個 WebSphere Application Server 程序具有多個影響應用程式性能的參數。您可以使用 WebSphere Application Server 管理控制台配置和調整應用程式、Web 容器、Enterprise Java Beans(EJB)容器、管理域中的應用程式伺服器和節點。

首先,檢視調整參數活動表,這是調整參數索引的子集。這些參數對性能有重要的影響。因為這些參數與應用程式相關,是以特定應用程式和環境的參數設定可改變。

調整參數索引中的每個參數連結到的資訊解釋參數,提供調整參數的原因,如何檢視或設定參數,以及預設值和建議值。

調整應用程式伺服器

WebSphere Application Server 包含必須相應調整以支援您的端到端電子商務應用程式的定制需要的相關元件。

調整 Java 虛拟機

Java 虛拟機(JVM)提供多個調整參數,這些參數影響 WebSphere Application Server 的性能(主要是 Java 應用程式),以及應用程式的性能。

調整應用程式

包含 Web 子產品、EJB 子產品、客戶機子產品、Web service 和應用程式服務的幾個主題由應用程式程式設計模型組成,并提供支援已部署應用程式的許多服務。

調整資料庫

WebSphere Application Server 支援內建多個不同的資料庫系統。每個資料庫系統以其自己的方式調整。為了您的友善起見,提供 DB2 調整參數。

調整安全性

安全性可能會影響性能,這取決于采用了某些操作。

調整硬體容量和設定

必須考慮一些影響性能的硬體因素。

調整作業系統

此部分讨論在伺服器環境中調整作業系統的注意事項。

用于分布式平台的 TCP/IP 調整提示

此部分讨論調整 TCP/IP 的注意事項。

調整 Web 伺服器

WebSphere Application Server 産品提供用于幾個 Web 伺服器品牌和版本的插件。每個 Web 伺服器作業系統組合都有特定的調整參數,這些參數可影響應用程式性能。

Web 伺服器調整參數

WebSphere Application Server 提供用于幾個 Web 伺服器品牌和版本的插件。每個 Web 伺服器作業系統組合都有特定的調整參數,這些參數可影響應用程式性能。

IBM HTTP Server

IBM HTTP Server V6.0 是多程序、多線程的伺服器。

通路日志

描述:收集所有入局 HTTP 請求。記錄日志會降低性能,因為 IO 操作開銷導緻日志在短時間内顯著增加。

如何檢視或設定:

打開 IBM HTTP Server httpd.conf 檔案,它位于目錄 IBM_HTTP_Server_root_directory/conf 中。

搜尋含有文本 CustomLog 的行。

通過在行首放置 # 來注釋掉此行。

儲存并關閉 httpd.conf 檔案。

停止并重新啟動 IBM HTTP Server。

預設值:啟用記錄每個入局 HTTP 請求。

建議值:禁用通路日志。

MaxClients

描述:MaxClients 僞指令控制 Web 伺服器在任何時候可以提供的最大同步連接配接數或使用者數。使用處于峰值時,如果您的 Web 伺服器需要立即支援 200 個活動使用者,則應該把 MaxClients 設定為 220(200 加負載額外增長的 10%)。把 MaxClients 設定得太低會導緻有些使用者認為 Web 伺服器不響應。您在您的 Web 伺服器中應該有足夠的 RAM 來支援每個已連接配接的客戶機。對于 Unix 上的 IBM HTTP Server V6.0,您應該配置設定大約 1.5MB MaxClients RAM 供 IBM HTTP Server 使用。對于 Windows 上的 IBM HTTP Server V6.0,您應該配置設定大約 300KB MaxClients RAM 供 IBM HTTP Server 使用。有些第三方子產品會顯著地增加每台已連接配接客戶機使用的 RAM 數。

如何檢視或設定:編輯 IBM HTTP Server httpd.conf 檔案中的 MaxClients 僞指令,該檔案位于目錄 IBM_HTTP_Server_root_directory/conf 中。

預設值:150

建議值:通常同步連接配接到您的 Web 伺服器的最大使用者數,附加緩沖區另外的 10%。注:KeepAliveTimeout 設定會影響使用者連接配接到 Web 伺服器的時間長短。

MinSpareServers、MaxSpareServers 和 StartServers

描述:預配置設定和維護指定的程序數,以便當負載接近指定的程序數時建立和銷毀不多的程序。指定相似的值會減少用于建立和銷毀 HTTPD 程序的 CPU 使用情況。等待 IBM HTTP Server 啟動更多伺服器(以便它可處理 HTTP 請求)時調整此參數是不可接受的。

如何檢視或設定:編輯 httpd.conf 檔案中的 MinSpareServers、MaxSpareServers 和 StartServers 僞指令,此檔案位于 IBM_HTTP_Server_root_directory/conf 目錄中。

預設值:MinSpareServers 5、MaxSpareServers 10、StartServers 5

建議值:要獲得最佳性能,為 MinSpareServers 和 StartServers 參數指定相同的值。如果 MaxSpareServers 設定成小于 MinSpareServers,那麼 IBM HTTP Server 複位 MaxSpareServer=MinSpareServer+1。把 StartServers 設定過高可導緻記憶體不足時的交換,進而降低性能。

ListenBackLog

描述:設定暫挂連接配接隊列的長度。當幾個客戶機請求連接配接到 IBM HTTP Server 并使用了所有線程時,有一個隊列保留其他客戶機請求。然而,如果您使用 Windows 上的 IBM HTTP Server V6.0 的預設快速響應高速緩存加速器(FRCA)功能,則因為 FRCA 有其自己的内部隊列而不使用 ListenBackLog 僞指令。

如何檢視或設定:對于非 FRCA:編輯 IBM HTTP Server httpd.conf 檔案。然後,添加或檢視 ListenBackLog 僞指令。

預設值:對于 HTTP Server V6.0:1024 啟用了 FRCA,511 禁用了 FRCA

建議值:使用預設值。

IBM HTTP Server - Linux

MaxRequestsPerChild

描述:設定單個子伺服器程序處理的請求數的限制。在請求數達到為 MaxRequestsPerChild 參數設定的值後,子程序死亡。當銷毀和建立子程序時調整此參數會降低您的 Web 伺服器性能。

編輯 IBM HTTP server httpd.conf 檔案,它位于 IBM_HTTP_Server_root_directory/conf 目錄中。

更改參數的值。

儲存更改并重新啟動 IBM HTTP server。

預設值:500

建議值:通常應該設定為 0。如果觀察到子記憶體使用情況随時間的過去穩定地增長,則非零設定會有用。有時在 IBM HTTP Server 使用的第三方子產品和各種 OS 運作時庫中會觀察到記憶體洩漏。

IBM HTTP Server - Windows 2000 和 Windows 2003

ThreadsPerChild

描述:設定 IBM HTTP Server 中任何時刻運作的并發線程數。

如何檢視或設定:編輯 IBM HTTP Server 檔案(httpd.conf 檔案),它位于目錄 IBM_HTTP_Server_root_directory/conf 中。更改參數的值。儲存更改并重新啟動 IBM HTTP Server。

有兩種在欠載狀态下查找使用多少線程的方法:

使用 Windows 2000 和 Windows 2003 性能螢幕,它位于桌面“開始”菜單下:

右鍵單擊桌面上的狀态欄。單擊任務管理器。

選擇程序頁籤。

單擊檢視 > 選擇列。

選擇線程計數。

單擊确定。

程序頁籤線上程列名下顯示每個程序的線程數(包括 Apache)。

使用 IBM HTTP Server 伺服器狀态(此選項可在所有平台上使用,并不僅限 Windows):

按如下所示編輯 IBM HTTP Server httpd.conf 檔案:從以下各行除去注釋字元 #:#LoadModule status_module、modules/ApacheModuleStatus.dll、#<Location/server-status>、#SetHandler server-status 和 #</Location>。

儲存更改并重新啟動 IBM HTTP Server。

在 Web 浏覽器中,轉至 URL:http://yourhost/server-status。換句話說,

單擊重新裝入以更新狀态。

(可選的)如果浏覽器支援重新整理,轉至 http://your_host/server-status?refresh=5 以每五秒重新整理一次。您将看到目前處理 45 個空閑伺服器的五個請求。

預設值:對于 IBM HTTP Server V6.0 為 250。

建議值:設定該值以避免瓶頸,它允許有恰好足夠的流量通過應用程式伺服器。

Web 伺服器配置重新裝入時間間隔

描述:跟蹤有關 WebSphere Application Server 資源的配置資訊的變化。Web 伺服器需要了解一些此類資訊,如指向 WebSphere Application Server 資源的統一資源辨別(URI)。此配置資料是在由此參數指定的時間間隔中通過 WebSphere Application Server 插件推進到 Web 伺服器中的。定期更新添加新的 servlet 定義,而無須重新啟動任何 WebSphere Application Server 伺服器。然而,動态重新生成此類配置資訊在性能方面的代價很高。在穩定的生産環境中調整此參數。

如何檢視或設定:使用“重新整理配置時間間隔 Web 伺服器插件”屬性更改此參數的目前設定。在管理控制台中,單擊伺服器 &gt; Web 伺服器 &gt; Web_server_name &gt; 插件屬性。

預設值:預設重新裝入時間間隔為 60 秒。

建議值:增加值的重新裝入間隔,該值表示一個在 servlet 更新和 Web 伺服器更新間的可接受的等待時間。

要擷取有關 plugin-cfg.xml 檔案的更多資訊,請參閱主題Web 伺服器插件。

Sun Java System Web server,Enterprise Edition(從前的 Sun ONE)- Solaris operating environment

Sun ONE Web server,Enterprise Edition 的預設配置提供了單程序、多線程伺服器。

活動線程

描述:指定伺服器中目前活動的線程數。在伺服器到達此參數設定的限制後,伺服器将停止對新連接配接的服務直至它完成舊連接配接。如果此設定過低,可壓制伺服器,進而導緻降低響應時間。要知道 Web 伺服器是否被壓制,請考慮其 perfdump 統計資訊。請檢視以下各資料:

WaitingThreads 計數:如果 WaitingThreads 計數将接近零或為零,則伺服器不接受新連接配接。

BusyThreads 計數:如果 WaitingThreads 計數接近零或為零,則 BusyThreads 很可能非常接近其限制。

ActiveThreads 計數:如果 ActiveThreads 計數接近其限制,伺服器很可能限制了其本身。

如何檢視或設定:使用“企業伺服器管理器”接口中的最大同時請求數參數,以控制 Sun ONE Web server,Enterprise Edition 中的活動線程數。此設定與 magnus.conf 檔案中的 RqThrottle 參數對應。

預設值:512

建議值:增加線程計數直到活動線程參數顯示最優的操作。

Microsoft Internet Information Server(IIS)- Windows NT 和 Windows 2000

IIS 許可權屬性

描述:Web server 有幾個屬性,它們主要影響應用程式伺服器的性能。通常,預設設定都可接受。然而,因為其他産品可更改預設設定而使用者卻不知道,是以確定檢查 IIS 設定以獲得 Web 伺服器的主目錄許可權。許可權應該設定成“腳本”而并非“執行”。如果許可權設定成“執行”,則不傳回錯誤消息,而 WebSphere Application Server 的性能将降低。

如何檢視或設定:要檢查或更改這些許可權,在 Microsoft 管理控制台中執行以下過程:

選擇 Web 站點(通常是預設 Web 站點)。

右鍵單擊并選擇屬性選項。

單擊主目錄頁籤。要設定主目錄的許可權:

在應用程式設定中,選擇許可權清單中的腳本複選框并清除執行複選框。

(可選的)檢查 sePlugin 的許可權:

展開 Web 伺服器。

右鍵單擊 sePlugin 并選擇屬性。

确認執行許可權被設定為執行。

預設值:Script

建議值:Script

每天期望的命中數

描述:控制 IIS 配置設定連接配接的記憶體。

如何檢視或設定:使用性能視窗,把 Microsoft 管理控制台的 Web 站點屬性面闆中的參數設定成大于 100000。

預設值:小于 100000

建議值:大于 100000

ListenBackLog 參數

描述:當在 Windows NT 和 Windows 2000 上使用 IIS 時,減輕重負載條件下的失敗連接配接。故障通常發生在使用大于 100 台客戶機時。ListenBackLog 會增加 IIS 保留在其隊列中的請求數。如果在 Netscape 浏覽器中間歇地看到無法找到伺服器錯誤時,請考慮提高該值。

使用指令提示符以發出 regedit 指令來通路作業系統系統資料庫。

在系統資料庫視窗中,找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ InetInfo\Parameters\ListenBackLog 目錄中的參數。

右鍵擊單該參數,以根據伺服器負載調整設定。

預設值:25(十進制)

建議值:您可将 ListenBackLog 參數設定成 200 那麼高,它不會對性能産生負面影響且提高負載處理能力。

修改 WebSphere 插件,以改進性能

您可通過修改插件的 RetryInterval 配置改進 IBM HTTP Server V6.0(帶有 WebSphere Web 伺服器插件)的性能。RetryInterval 是嘗試連接配接到已标記為臨時不可用的伺服器所等待時間的長度。進行此更改可幫助 IBM HTTP Server V6.0 調整為多于 400 個使用者。

如果到伺服器的連接配接失敗,插件将伺服器标記為臨時不可用。盡管預設值為 60 秒,建議您減小此值,以便在重負載條件下增加吞吐量。減小 RetryInterval 對于每個程序具有單個線程的 UNIX 作業系統上的 IBM HTTP Server V6.0 或對于配置為每個程序具有少于 10 個線程的 IBM HTTP Server 2.0 很重要。

減小 RetryInterval 如何影響吞吐量?如果當應用程式伺服器線程忙于處理其他連接配接(其在重負載條件下發生)時,插件嘗試連接配接到特殊應用程式伺服器,則連接配接逾時,而且插件将伺服器标記為臨時不可用。如果同一插件程序具有為同一伺服器開放的其他連接配接,而且在這些連接配接之一上接收到響應,則再次标記伺服器。然而,當您在 UNIX 作業系統上使用 IBM HTTP Server V6.0 時,不存在其他連接配接,因為每個插件程序僅存在一個線程和一個并發請求。是以,插件在嘗試再次連接配接到伺服器前,等待 RetryInterval。

因為應用程式伺服器不是真的當機,而是很忙,則請求通常在很少的時間内完成。應用程式伺服器線程變成可用于接受更多連接配接。大 RetryInterval 導緻應用程式伺服器标記為臨時不可用,導緻更多一緻的應用程式伺服器 CPU 使用率和更高的持續吞吐量。

注: 盡管減小 RetryInterval 可改進性能,但是如果所有應用程式伺服器在運作中,則當某個應用程式伺服器當機時,低值可具有方面影響。在這種情況下,每個 IBM HTTP Server V6.0 程序嘗試連接配接并更頻繁的失敗,導緻增加等待時間,并較少整個吞吐量。

下列調整參數特定于作業系統。因為這些不是 WebSphere Application Server 産品,是以注意産品可更改,而且結果可改變。

此任務的步驟(取決于配置)

調整 Windows NT 或 Windows 2000 作業系統

TcpTimedWaitDelay

描述:确定 TCP/IP 可釋放已關閉連接配接并重用其資源前,必須經過的時間。關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀态或兩倍最大段生命周期(2MSL)狀态。此時間期間,重新打開到客戶機和伺服器的連接配接的成本少于建立新連接配接。減少此條目的值允許 TCP/IP 更快地釋放已關閉的連接配接,為新連接配接提供更多資源。如果運作的應用程式需要快速釋放和建立新連接配接,而且由于 TIME_WAIT 中存在很多連接配接,導緻低吞吐量,則調整此參數。

使用 regedit 指令通路 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 系統資料庫子鍵并建立名為 TcpTimedWaitDelay 的新 REG_DWORD 值。

将此值設定為十進制 30,其為十六進制 0x0000001e。該值将等待時間設定為 30 秒。

停止并重新啟動系統。

預設值:0xF0,它将等待時間設定為 240 秒(4 分鐘)。

建議值:最小值為 0x1E,它将等待時間設定為 30 秒。

MaxUserPort

描述:确定在應用程式從系統請求可用使用者端口時,TCP/IP 可指定的最高端口号。

使用 regedit 指令通路 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 系統資料庫子鍵并建立名為 MaxUserPort 的新 REG_DWORD 值。

預設值:無

建議值:至少十進制 32768。

注:當在 Windows NT 或 Windows 2000 作業系統上調整 WebSphere Application Server 時,同時使用這兩個參數。

調整 AIX

TCP_TIMEWAIT

描述:确定 TCP/IP 可釋放已關閉連接配接并重用其資源前,必須經過的時間。關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀态或兩倍最大段生命周期(2MSL)狀态。此時間期間,重新打開到客戶機和伺服器的連接配接的成本少于建立新連接配接。減少此條目的值允許 TCP/IP 更快地釋放已關閉的連接配接,為新連接配接提供更多資源。如果運作應用程式需要快速釋放、建立新的連接配接,并且由于許多連接配接處于 TIME_WAIT 狀态而導緻低吞吐量,則調整此參數。

發出下列指令,将 TCP_TIMEWAIT 狀态設定為 15 秒:

/usr/sbin/no –o tcp_timewait =1

安裝了 DB2 的 AIX 作業系統

描述:将 DB2 日志檔案從實體資料庫檔案中分隔出來可增加性能。您還可将日志記錄和資料庫檔案從包含日志檔案系統(JFS)服務的驅動器中分隔出來。AIX 為 JFS 日志記錄使用特定卷組和檔案系統。

如何檢視或設定:使用 AIX filemon 實用程式檢視所有檔案系統輸入和輸出,并在戰略上選擇 DB2 日志的檔案系統。然後,根據DB2 調整參數設定 DB2 日志位置。

預設值:檔案的預設位置是 \home\<db2_user_name>\sqllib\db2dump。

建議值:把檔案移動到與 DB2 資料分開的、并且具有最小輸入或輸出活動的磁盤上。

AIX 檔案描述符(ulimit)

描述:指定允許的打開檔案數。預設設定通常足夠用于大多數應用程式。如果此參數的值設定過低,則顯示記憶體配置設定錯誤。

如何檢視或設定:檢查關于 ulimit 指令的 UNIX 參考頁面以擷取不同 shell 的文法。對于 KornShell shell(ksh),要将 ulimit 設定為 2000,發出 ulimit -n 2000 指令。使用 ulimit -a 指令顯示系統資源上所有限制的目前值。

預設值:對于 AIX 系統,預設設定為 2000。

建議值:2000

AIX TCP_KEEPIDLE

描述:“保持活動”包確定連接配接處于 active/ESTABLISHED 狀态。

如何檢視或設定:使用 no 指令以确定目前值或設定該值。直到下次您重新啟動機器後,更改才會生效。要永久更改該值,則将 no 指令添加到 /etc/rc.net 目錄。例如:

no -o tcp_keepidle=600

預設值:14400 毫秒。

建議值:600 毫秒。

其他 AIX 資訊

還存在很多本文檔未涉及的其他 AIX 作業系統設定要考慮。您可調整的其他設定如下所示:

擴充卡發送和接收隊列

TCP/IP 套接字緩沖區

IP 協定 mbuf 池性能

更新檔案描述符

更新排程程式

要擷取關于 AIX 作業系統的更多資訊,請參閱 性能:學習資源。

調整 Solaris 作業系統

Solaris 檔案描述符(ulimit)

描述:指定允許的打開檔案數。如果此參數的值太小,則在 WebSphere Application Server stderr.log 檔案中會顯示打開太多檔案錯誤。

如何檢視或設定:檢查關于 ulimit 指令的 UNIX 參考頁面以擷取不同 shell 的文法。對于 KornShell(ksh)shell 程式,使用 ulimit -n 1024 指令。使用 ulimit -a 指令顯示系統資源上所有限制的目前值。

Solaris TCP_TIME_WAIT_INTERVAL

描述:通知 TCP/IP 保留已關閉連接配接控制塊多久。在應用程式完成 TCP/IP 連接配接後,控制塊保留指定的時間。當高連接配接率發生時,大量 TCP/IP 連接配接累加,而且可減慢伺服器性能。伺服器在某些峰值期間會延遲。如果伺服器延遲,netstat 指令顯示對 HTTP 伺服器打開的許多套接字處于 CLOSE_WAIT 或 FIN_WAIT_2 狀态。可視延遲最多可發生 4 分鐘,其間伺服器無法發送任何響應,但是 CPU 使用率保持很高,帶有系統程序中的所有活動。

如何檢視或設定:使用 get 指令确定目前時間間隔,并使用 set 指令将時間間隔指定為 30 秒。例如:

ndd -get /dev/tcp tcp_time_wait_interval

ndd -set /dev/tcp tcp_time_wait_interval 30000

預設值:對于 Solaris 作業系統,預設等待時間間隔為 2400000 毫秒(相當于 4 分鐘)。

建議值:30000 毫秒。

Solaris TCP_FIN_WAIT_2_FLUSH_INTERVAL

描述:指定禁止處于 FIN_WAIT_2 狀态中的連接配接保持該狀态的計時器時間間隔。當高連接配接率發生時,大量 TCP/IP 連接配接累加,而且可減慢伺服器性能。伺服器在峰值期間會延遲。如果伺服器延遲,使用 netstat 指令顯示向 HTTP 伺服器打開着的許多套接字處于 CLOSE_WAIT 或 FIN_WAIT_2 狀态。可視延遲最多可發生 4 分鐘,其間伺服器無法發送任何響應,但是 CPU 使用率保持很高,帶有系統程序中的所有活動。

如何檢視和設定:您可以通過使用下列指令将目前時間間隔設定為 67.5 秒:

ndd -get /dev/tcp tcp_fin_wait_2_flush_interval

ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500

預設值:675000 毫秒。

建議值:67500 毫秒。

Solaris TCP_KEEPALIVE_INTERVAL

如何檢視或設定:使用 ndd 指令确定目前值或設定該值。例如:

ndd -set /dev/tcp tcp_keepalive_interval 300000

預設值:7200000 毫秒。

建議值:300000 毫秒。

Solaris 核心 semsys:seminfo_semume

描述:限制每個程序最大信号量撤銷條目。因為此設定指定最大值,是以參數不會導緻使用附加記憶體,除非它需要。

如何檢視或設定:如果運作 /usr/sbin/sysdef 指令,則此值顯示為 semume 參數。/etc/system 檔案中可有一個條目用于此調整參數。通過 /etc/system 條目設定此參數:

set semsys:seminfo_semume = 1024

預設值:10

建議值:無

Solaris 核心 semsys:seminfo_semopm

描述:如果運作 /usr/sbin/sysdef 指令,則顯示為 semume 參數。/etc/system 檔案中可存在用于此調整參數的條目。

如何檢視或設定:通過 /etc/system 條目設定此參數:

semsys:seminfo_semopm = 200

建議值:16384

調整 HP-UX 11i

修改 HP-UX 11i 設定以大大提高 WebSphere Application Server 性能。要擷取關于 HP 性能調整參數的其他資訊,請參閱 性能:學習資源。

Java 虛拟機(JVM)虛拟頁面大小

描述:将 JVM 訓示資訊和資料頁面大小設定為 64MB 将提高性能。

如何檢視或設定:使用 chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java 指令。指令輸出提供程序可執行檔案的目前作業系統特征。

預設值:4MB(如果未指定)

建議值:64MB

HP-UX 11i TCP_CONN_REQUEST_MAX

描述:指定當伺服器沒有任何可用線程時,作業系統可排隊的最大連接配接請求數。當高連接配接率發生時,大量 TCP/IP 連接配接請求建構,并删除客戶機連接配接。當客戶機在等待連接配接後開始逾時時,調整此設定。通過發出 netstat -p tcp 指令驗證此情況。查找下列值:connect requests dropped due to full queue

如何檢視或設定:通過使用 ndd -set /dev/tcp tcp_conn_request_max 1024 指令設定此參數。

預設值:4096

建議值:多數情況下預設值應已足夠。如果預設值不夠,考慮調整為 8192。

HP-UX 11i 核心參數建議

描述:使用 DB2 或 Oracle 資料庫的下列核心參數設定以獲得最佳性能:核心參數 WebSphere Application Server 設定 DB2 設定 Oracle 設定

maxuprc -- 512 --

maxfiles 2,048 -- --

maxfiles_lim 2,048 -- --

nkthread 10,000 -- --

max_thread_proc 2,048 -- --

nproc -- 1,028 --

nflocks -- 8,192 --

ninode -- 2,048 --

nfile -- 8,192 --

msgseg -- 32,767 --

msgmnb -- 65,535 --

msgmax -- 65,535 --

msgtql -- 1,024 --

msgmap -- 258 --

msgmni -- 256 --

msgssz -- 16 --

semmni -- 512 70

semmap -- 514 --

semmns -- 1,024 200

semmnu -- 1,024 --

shmmax -- 966,367,642 1 GB

shmmseg -- 16 10

shmmni -- 300 100

如何檢視或設定:使用 HP-UX SAM 實用程式設定核心參數。請參閱文檔,以獲得關于您的作業系統的訓示。

建議值: 請參閱表

用于 WebSphere MQ 5.3 的 HP-UX 11i 核心參數建議

描述:嵌入式消息傳遞使用 WebSphere MQ 5.3。下列是 WebSphere MQ 5.3 建議的核心參數設定:核心參數 設定

shmmax 536870912

shmseg 1024

shmmni 1024

shmem 1

sema 1

semaem 16384

semvmx 32767

semmns 16384

semmni 1024 (semmni < semmns)

semmap 1026 (semmni +2)

semmnu 2048

semume 256

msgmni 50

msgtql 256

msgmap 258 (msgtql +2)

msgmax 4096

msgmnb 4096

msgssz 8

msgseg 1024

maxusers 32

max_thread_proc 66

maxfiles 1024

nfile 10000

世代垃圾回收 nursery 大小

描述:WebSphere Application Server V5 與基于 Sun Hotspot 技術的 HP 本機 JVM 一起提供。其功能之一是使用将堆分割為新代和舊代的世代垃圾回收。必須使用性能分析工具(如 Glance)确定新代或 nursery 的适當大小。如果正确選擇 nursery 大小,垃圾回收的開銷會減少并改進吞吐量和響應時間。

如何檢視或設定:在一般 Java 選項上使用 -Xmn 指令,例如,使用 -Xmn512m 将 nursery 大小設定為 512MB。

預設值:三分之一的最大堆大小。

建議值:當建立幾個短暫的對象時,将值設定為堆大小最大值的二分之一。

調整 Linux

timeout_timewait 參數

發出下列指令,将 timeout_timewait 參數設定為 30 秒:

/sbin/sysctl -w net.ipv4.vs.timeout_timewait=30

SLES8 SP2A - sched_yield_scale 調整

描述:Linux 排程程式對過度的上下文交換非常敏感,是以已将修訂程式內建到 SLES8 核心分發,以便線上程發生處理時引進延遲。此修訂程式在 SLES8 SP3 中自動啟用,但在 SLES8 SP2A 或以上版本中必須明确地啟用。

如果您運作任何 SP2A 以下版本的 SLES8 service pack,更新到 SP2A。

發出指令 sysctl -w sched_yield_scale=1。

預設值:0

建議值:1

RedHat Advanced Server 2.1 核心更新

描述:RedHat Advanced Server 2.1 的核心更新已實作影響 WebSphere 性能的更改,尤其是記憶體到記憶體 HTTP 會話複制。

發出 uname -a 指令

如果您正在運作任何在 2.4.9-e.23 之前的核心,至少更新到此核心,最好更新到最近支援的核心。

預設值:2.4.9-e.3

建議值:2.4.9-e.23

Linux 檔案描述符(ulimit)

描述:指定允許的打開檔案數。預設設定通常足夠用于大多數應用程式。如果将此參數的值設定得太小,則可能會顯示檔案打開錯誤、記憶體配置設定故障或連接配接建立錯誤。

如何檢視或設定:檢查關于 ulimit 指令的 UNIX 參考頁面以擷取不同 shell 的文法。對于 KornShell shell(ksh)程式,要将 ulimit 指令設定為 2000,則發出 ulimit -n 2000 指令。使用 ulimit -a 指令顯示系統資源上所有限制的目前值。

預設值:對于 Linux 系統,預設設定為 1024。這是 SLES 9 的預設值。

建議值:8000

Java 記憶體調整提示

用 Java 語言寫的企業應用程式涉及複雜對象關系,并利用大量對象。雖然,Java 語言會自動管理與對象生命周期關聯的記憶體,但了解對象的應用程式使用模式是重要的。特别要驗證以下内容:

應用程式不是過度使用的對象

應用程式不是漏掉的對象

已正确設定 Java 堆參數以處理給定的對象使用模式

了解垃圾回收的效果對應用這些管理技術是必需的。

垃圾回收瓶頸

檢查 Java 垃圾回收可了解應用程式正在如何利用記憶體。垃圾回收是 Java 的特質。通過從應用程式寫程式除去記憶體管理負擔,Java 應用程式比用不提供垃圾回收的語言寫的應用程式更健壯。隻要應用程式不在濫用對象,此健壯性就适用。垃圾回收通常使用正确運作的應用程式的總執行時間的 5% 到 20%。如果不受管,則垃圾回收會是應用程式的某個最大瓶頸,特别是當運作在對稱多處理(SMP)伺服器上。在大多數垃圾回收循環期間,Java 虛拟機(JVM)使用并行垃圾收集器,最大程度地利用了 SMP,其中 Sun HotSpot 1.3.1 JVM 具有單線程的垃圾收集器。要擷取有關在 Solaris Operating Environment 中的垃圾回收的更多資訊,請參閱性能:學習資源。

垃圾回收标尺

您可以使用垃圾回收評價應用程式性能運作狀況。通過在執行固定工作負載期間監控垃圾回收,您可了解應用程式是否是過度使用的對象。垃圾回收甚至可以檢測到記憶體洩漏的存在。

您可以使用 Tivoli Performance Viewer 中的對象統計資訊或使用 verbose:gc JVM 配置設定監控垃圾回收統計資訊。verbose:gc 格式在不同的 JVM 之間或發行版級别之間不是标準化的。要擷取 IBM verbose:gc 輸出的描述和有關 IBM 垃圾收集器的更多資訊,請參閱性能:學習資源。

要擷取此類型研究,将最小和最大堆大小設定為同一值。選擇與生産用法盡可能比對的有代表性的、重複的工作負載,包括使用者錯誤。

要確定有意義的統計資訊,請運作固定工作負載直到應用程式狀态穩定為止。通常要用幾分鐘的時間來達到穩定狀态。

檢測過度使用的對象

您可以通過觀察 JVM 運作時的計數器,使用 Tivoli Performance Viewer 檢查應用程式是否是過度使用的對象。您不得不設定 -XrunpmiJvmpiProfiler 指令行選項以及 JVM 子產品最大級别,以便啟用 Java 虛拟機概要分析程式接口(JVMPI)計數器。垃圾回收之間的最佳平均時間為至少是單次垃圾回收的平均持續時間的 5 到 6 倍。如果沒有達到此數字,則應用程式将多用 15% 的時間用于垃圾回收。

如果資訊表明垃圾回收瓶頸,則有兩種方法清除瓶頸。最劃算的方法是優化應用程式以實施對象高速緩存和池。使用 Java 概要分析程式确定把哪些對象作為目标。如果您無法優化應用程式,則添加記憶體、處理器和克隆可能會有幫助。添加的記憶體允許每個克隆保持合理的堆大小。添加的處理器允許克隆并行運作。

檢測記憶體洩漏

記憶體洩漏在 Java 語言中是造成垃圾回收瓶頸的一個危險因素。記憶體洩漏比記憶體過度使用更有破壞性,因為記憶體洩漏最終會導緻系統不穩定。随着時間的過去,垃圾回收會發生得更加頻繁,直到堆用盡,而且 Java 代碼失敗并傳回緻命的缺乏記憶體異常。當未使用的對象具有從未釋放的引用時,發生記憶體洩漏。記憶體洩漏通常發生在集合類(如 Hashtable)中,這是因為表總是具有對對象的引用(甚至在删除真實的引用後)。

高工作負載總會引起應用程式在生産環境中部署後立即崩潰。這對于洩漏應用程式尤其正确,其中高工作負載會促進洩漏的放大率,而且會發生記憶體配置設定故障。

進行記憶體洩漏測試的目标是擴大數字。根據無法進行垃圾回收的位元組或千位元組量評測記憶體洩漏。此精細任務将差別有用和不可用記憶體的預期大小之間的這些量。如果擴大數字,這會導緻更大的間隔和更易于辨別不一緻性,則完成此任務會更簡便。以下清單包含有關記憶體洩漏的重要結論:

長期運作測試

記憶體洩漏問題可能在一段時間後才會顯現,是以,在長期運作測試期間易于找到記憶體洩漏。短期測試可能導緻錯誤的警報。有時,當 Java 語言中發生記憶體洩漏時,很難知道,尤其當在一段給定時間内,記憶體使用情況表面上突然地或單調地增加時。很難檢測記憶體洩漏的原因是由于這些種類的增加可能有效或可能是開發者的意圖。您可以通過将應用程式運作一段較長的時間,來了解如何區分延遲使用的對象和完全未使用的對象。進行長期運作應用程式測試能幫助您更好地确定延遲使用對象是否正在實際發生。

重複測試

在很多情況下,記憶體洩漏問題通過同一測試用例的連續重複而發生。記憶體洩漏測試的目标是建立不能使用的記憶體和使用的記憶體(根據它們的相對大小)之間的大間隔。通過一次又一次地重複同一方案,漸進地增加間隔。如果由執行測試用例引起的洩漏數太小以至于很難在某次運作中明顯地顯示出來,則進行此測試會有幫助。

您可以在系統級别或子產品級别上使用重複測試。進行子產品化測試的優點是較好控制。當設計子產品在不建立外部副作用(如記憶體使用情況)的情況下保持專用子產品時,對記憶體洩漏進行測試較簡便。首先,在運作子產品前記錄記憶體使用情況。然後,重複運作一組固定的測試用例。在測試運作結束時,為重大更改記錄和檢查目前消息使用情況。請記住,當通過将 System.gc() 插入到子產品(您要垃圾回收發生的地方)中,或使用概要分析工具強迫事件發生時,必須建議使用垃圾回收。

并發性測試

某些記憶體洩漏問題可能僅當幾個線程運作在應用程式中時發生。不幸地是,由于程式邏輯中添加的新出現的問題,同步點很容易受到記憶體洩漏的影響。程式設計粗心可能會導緻儲存或未釋放的引用。系統中增加的并發性通常會推動或促進記憶體洩漏事件。增加并發性最常見的方法就是增加測試驅動程式中的客戶機數。

當選擇将哪些測試用例用于進行記憶體洩漏測試時,考慮以下各點:

好的測試用例會經曆建立對象的應用程式區域。大多數時間,需要應用程式的知識。方案的描述可以建議建立資料空間,如添加新記錄、建立 HTTP 會話、執行事務和搜尋記錄。

檢視使用對象集合的區域。通常,記憶體洩漏由同一類中的對象組成。同樣,集合類(如 Vector 和 Hashtable)是通過調用相應的插入方法,隐式存儲對對象的引用的常見位置。例如,Hashtable 對象的 get 方法不會除去其對已檢索對象的引用。

Tivoli Performance Viewer 可以幫助查找記憶體洩漏。要擷取最佳結果,請用漸增的持續時間重複實驗,象 1000、2000 和 4000 頁請求。使用的記憶體的 Tivoli Performance Viewer 圖應該具有鋸齒形狀。圖上的每個下降對應于垃圾回收。如果發生以下某種情況,則存在記憶體洩漏:

每次垃圾回收顯著增加後,立即使用的記憶體量。鋸齒模式更象樓梯。

鋸齒模式具有不規則的形狀。

同樣,檢視已配置設定的對象數和已釋放的對象數之間的差異。如果兩個增長之間的間隔超出時間,則存在記憶體洩漏。

表明重工作負載(應用程式伺服器的 CPU 使用率一直接近 100%)期間可能的洩漏,但似乎會在接下來的較輕或接近空閑的工作負載期間恢複的堆消耗,是堆碎片整理的訓示。當 JVM 可以在垃圾回收循環期間釋放足夠的對象以滿足記憶體配置設定請求時,發生堆碎片整理,但 JVM,沒有時間将堆中小的空閑記憶體區域壓縮到較大的鄰近空間。

當釋放小對象(小于 512 個位元組)時,會發生另一種格式的堆碎片整理。會釋放對象,但不會恢複存儲器,導緻記憶體分段直到已運作堆壓縮。

要避免堆碎片整理,打開 JVM 進階設定指令行實參中的 -Xcompactgc 标志。-Xcompactgc 函數會驗證每個垃圾回收循環是否除去分段存儲。然而,壓縮是代價相對高昂的操作。請參閱Java 虛拟機設定中的堆壓縮指令行實參(-Xnocompactgc),以擷取更多資訊。

Java 堆參數

Java 堆參數還會影響垃圾回收行為。增加堆大小會支援更多對象建立。由于大的堆要用較長時間進行填充,是以在垃圾回收發生前應用程式會運作較長時間。然而,較大的堆也會用較長時間進行壓縮,和引起垃圾回收發生。請參閱Java 虛拟機設定中有關 Java 堆大小的部分,以擷取更多資訊。

對于性能分析,初始堆大小和最大堆大小應該相等。

當調整 Java 應用程式的工作集大小未知的生産系統時,初始堆大小的适宜的啟動值是最大堆大小的 25%。然後,JVM 嘗試使堆大小适應應用程式的工作集大小。

此插圖表示三個 CPU 概要檔案,每個概要檔案都在運作具有變動的 Java 堆設定的固定工作負載。在中間的概要檔案中,将初始堆大小和最大堆大小設定為 128MB。發生四次垃圾回收。垃圾回收的總時間大約是運作總時間的 15%。當堆參數加倍為 256MB 時(如在頂部的概要檔案中所示),在兩次垃圾回收之間的工作時間的長度會增加。僅發生三次垃圾回收,但每次垃圾回收的工作時間長度也會增加。在第三個概要檔案中,堆大小減少為 64MB,而且會顯示出相反的效果。使用較小的堆大小,兩次垃圾回收之間的時間和每次垃圾回收的時間也會較短。對于所有三種配置,垃圾回收的總時間大約是 15%。此示例說明有關 Java 堆大小和其與對象使用率的關系的重要概念。在 Java 應用程式中總是有垃圾回收的成本。

運作一系列改變 Java 堆設定的測試實驗。例如,用 128MB、192MB、256MB 和 320MB 運作實驗。在每次實驗期間,監控全部記憶體使用情況。如果您太多擴充堆,則可能發生記憶體分頁。使用 vmstat 指令或 Windows NT 或 Windows 2000 性能螢幕檢查頁面排程。如果發生頁面排程,則減少堆大小或将更多的記憶體添加到系統。當所有運作都完成時,比較以下各統計資訊:

垃圾回收調用次數

一次垃圾回收調用的平均持續時間

一次垃圾回收調用的工作時間長度和兩次垃圾回收調用之間的平均時間之間的比率

如果應用程式不是過度使用的對象而且沒有記憶體洩漏,則達到穩定記憶體使用率的狀态。垃圾回收也會發生得較不頻繁,而且持續時間短。

如果堆可用空間穩定在 85% 或更多,則考慮減少堆大小的最大值,這是因為應用程式伺服器和應用程式未充分利用為堆配置設定的記憶體。

要擷取有關垃圾回收的更多資訊,請參閱性能:學習資源。

有關可從 IBM Support 處擷取的關于已知問題及其解決方法的目前資訊,請參閱 IBM Support 頁面。

IBM Support 擁有的文檔可節省您收集解決此問題所需資訊的時間。在打開 PMR 前,請參閱 IBM Support 頁面。

jaesonchen 2006-10-31

繼續閱讀