weblogic調優

本文摘自作者: | 來源: 7點測試網

前言:對於weblogic調優涉及很多方面,我先從weblogic sever調優開始學習.在這部分裡,又分了很多部分,我先從Tuning the Default Execute Queue Threads開始學習.
一 domain 和 WebLogic Server instances
域是管理WebLogic Server instances (severs)的基本單位,而sever擁有自己的java虛擬機器和自己的配置,如引數檔案配置(config.xml),一個域下可以多個severs但只有一個Administration Server,
Administration Server管理這些severs,Administration Server是執行管理控制檯的服務.
開啟控制檯去看下就能明白上述概念
二 Execute Queue
Execute Queue用來存放應用程式對WebLogic Server instance的請求.每個請求都被分配給一個執行緒處理.預設情況下,一個新的WebLogic Server instance有三種Execute Queue:
weblogic.kernel.default
weblogic.admin.HTTP
weblogic.admin.RMI
只有第一個可以手工配置. Web applications and RMI objects use weblogic.kernel.default.當然我們可以手工配置新的Execute Queue並分配應用程式給他們.
後兩種不可以重新配置,他們被規定用來處理 communicating with the Administration Console and for administrative traffic.
然後我們看下Execute Queue的引數
1>Queue Length:The maximum number of simultaneous requests that this server can hold in the queue.
在佇列服務所能處理的最大併發請求數目.
2>Queue Length Threshold Percent:The percentage of the Queue Length size that can be reached before this server indicates an overflow condition for the queue.
當佇列當前大小達到佇列最大尺寸的這個百分比的時候,系統會認為the queue to have a possible overflow condition,佇列的健康狀態將變為"warning" .
3>Thread Count:The number of threads assigned to this queue
分配給這個佇列的執行緒數目
4>Threads Increase:The number of threads to be added to the queue when an overflow condition occurs.
overflow condition發生後,增加的執行緒數目
5>Threads Maximum:The maximum number of threads that this queue can have; this value prevents WebLogic Server from creating an overly high thread count in the queue in response to continual overflow conditions.
佇列所能擁有的最大執行緒數目
6>Threads Minimum:The minimum number of threads that WebLogic Server will maintain in the queue
固有執行緒數目
7>Thread Priority:The priority of the threads associated with this queue
執行緒優先順序
三 調優策略
1 調優方向
我們知道，應用程式的工作是放在execute queue來處理的，這些任務被分配給不同執行緒去處理，執行緒消耗資源，所以配置很多的執行緒數目，會消耗很多資源，還會增加上下文切換，從而影響效能。執行緒過少又會引起等待，降低效能指標。所以執行緒是我們調優的方向。
那麼如何確定一個execute queue中理想的執行緒數目呢？佇列裡的應用程式在最大負載模式下執行的時候，我們去監控吞吐量，反覆做這種負載測試，不斷增加執行緒數目直至出現最大的吞吐量。在這個過程中吞吐量是隨著執行緒的數目增加而有上升趨勢的，但隨著執行緒數目的不斷增加，就會出現大量的上下文切換，在這個時候，吞吐量就會下降。
那麼如何去修改the Default Thread Count？按照下面的步驟
1〉Start the Administration Server if it is not already running.
2〉Access the Administration Console for the domain.
3〉Expand the Servers node in the left pane to display the servers configured in your domain.
4〉Right-click the name of the server instance that contains the execute queue you want to configure, and then select View Execute Queues on the pop-up menu to display a table of execute queues that can be modified.
Note: You can only modify the default execute queue for the server or a user-defined execute queue.
5〉In the Name column, click directly on the default execute queue name to display the Configuration tab for modifying execute queues.
6〉Locate the Thread Count value and increase or decrease it, as appropriate.
2 Tuning Execute Queues for Overflow Conditions
首先我們要知道什麼是 Overflow？噹噹前佇列長度是佇列最大長度的Queue Length Threshold Percent地時候，系統會認為這個佇列出現overflow.此時服務就會根據引數Threads Increase分配新的執行緒去處理佇列中暫停的任務。
總結這個過程，我們要注意下面3個過程：
1〉The threshold at which the server indicates an overflow condition. This value is set as a percentage of the configured size of the execute queue (the QueueLength value). 對應引數Queue Length Threshold
2〉The number of threads to add to the execute queue when an overflow condition is detected. These additional threads work to reduce the size of the queue to its normal operating size. 對應引數Threads Increase
3〉The maximum number of threads available to the queue. In particular, setting the maximum number of threads prevents the server from assigning an overly high thread count in response to overload conditions.對應引數Threads Maximum
3 Tuning the Execute Thread Detection Behavior
如果一個執行緒執行時間超過了一個規定的最大時間，sever就會認為把它作為stuck執行緒，併產生日誌去記錄它。這個規定的最大時間就是引數Stuck Thread Max Time。而sever會依照某個週期時間對執行緒進行掃描來判斷執行緒是否發生stuck.這個週期時間是Stuck Thread Timer Interval。下面是原文解釋。
1〉Stuck Thread Max Time: Enter the number of seconds, that a thread must be continually working before this server diagnoses the thread as being stuck. By default, WebLogic Server considers a thread to be "stuck" after 600 seconds of continuous use.
2〉Stuck Thread Timer Interval: Enter the number of seconds, after which WebLogic Server periodically scans threads to see if they have been continually working for the length of time specified by Stuck Thread Max Time. By default, WebLogic Server sets this interval to 600 seconds.
那麼在控制檯如何找到這個值呢？
1〉Start the Administration Server if it is not already running.
2〉Access the Administration Console for the domain.
3〉Expand the Servers node in the left pane to display the servers configured in your domain.
4〉Click the name of the server instance that you want to modify for improved stuck thread detection.
Note: You configure stuck thread detection parameters on a per-server basis, rather than on a per-execute queue basis.
5〉Select the Configuration —> Tuning tab in the right pane.
6〉Modify the following attributes as necessary to tune thread detection behavior. for the server
如果all threads in the default queue become stuck, the server changes its health state to "critical."
4Allocating Execute Threads to Act as Socket Readers
我們可以透過分配一些執行緒給Socket Readers來提高服務端接受客戶端請求的速度和處理能力。因此It is essential to balance the number of execute threads that are devoted to reading messages from a socket and those threads that perform. the actual execution of tasks in the server。我們透過引數ThreadPoolPercentSocketReaders attribute sets the maximum percentage of execute threads that are set to read messages from a socket
那麼如何找到這個引數呢？
To use the Administration Console to set the maximum percentage of execute threads that read messages from a socket:

1〉Start the Administration Server if it is not already running.
2〉Access the Administration Console for the domain.
3〉Expand the Servers node in the left pane to display the servers configured in your domain.
4〉Click the name of the server that you want to configure.
5〉Select the Configuration —> Tuning tab.
6〉Edit the percentage of Java reader threads in the Socket Readers attribute field. The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in the Thread Count field for the Execute Queue).
Apply the changes.
下面提供了在客戶端定義這個引數的方法：
Setting the Number of Socket Reader Threads on Client Machines
On client machines, you can configure the number of available socket reader threads in the JVM that runs the client. Specify the socket readers by defining the following parameters in the java command line for the client:
-Dweblogic.ThreadPoolSize=value
-Dweblogic.ThreadPoolPercentSocketReaders=value
總結：Adding more threads to the default execute queue does not necessarily imply that you can process more work. Even if you add more threads, you are still limited by the power of your processor. Because threads consume memory, you can degrade performance by increasing the value of the ThreadCount attribute unnecessarily. A high execute thread count causes more memory to be used and increases context switching, which can degrade performance.
The value of the ThreadCount attribute depends very much on the type of work your application does. For example, if your client application is thin and does a lot of its work through remote invocation, that client application will spend more time connected — and thus will require a higher thread count — than a client application that does a lot of client-side processing.
If you do not need to use more than 15 threads (the development default) or 25 threads (the production default) for your work, do not change the value of this attribute. As a general rule, if your application makes database calls that take a long time to return, you will need more execute threads than an application that makes calls that are short and turn over very rapidly. For the latter case, using a smaller number of execute threads could improve performance.