用於具有過載保護的應用伺服器的系統和方法

2023-05-28 05:19:11 1

專利名稱：：用於具有過載保護的應用伺服器的系統和方法
技術領域：
：本發明一般涉及應用伺服器和消息系統(messagingsystem),尤其涉及一種用於具有過載保護的應用伺服器的系統和方法。
背景技術：
：在典型的應用伺服器和網絡伺服器環境中，在很短的時間內伺服器可能接收上千個請求。在特定的情況下伺服器將會變得過載並且不能再處理更多的請求。對於用戶來說，這會呈現為頁面錯誤或者凍結頁面(frozenpage)。用戶通常會通過請求來不斷地衝擊(hitting)伺服器，而這實際上不具有任何效果並且只會使問題變得更糟。所需要的是一種能夠通知用戶當前伺服器過載的機制，並且這能夠允許伺服器在不必處理更多請求的情況下重新獲得穩定性。傳統的做法是產生一個伺服器"找不到對象"，或者將請求放置在一個固定長度的隊列中。然而，既沒有嘗試特性化(characterize)請求，也沒有例如拒絕那些將超過一分鐘的請求而服務其它請求。
發明內容根據本發明的一個實施例，一種系統，例如一個伺服器或集群(cluster)，被設計為每當伺服器變得過載時就產生一個消息和/或拒絕進一步的工作。這以一種處理器-效率(processor-efficient)方式來進行，以便不對已經高負荷的伺服器添力。更多的壓力。該拒絕消息和動作(action)是可定製的。然而，在定製為靈活的點和過度定製為添加更多處理器要求的點之間僅有很小的區別(athinlinebetween)。最重要的是拒絕必須被快速地處理。傳統的方案不能適用於某些請求，例如保證支付請求(ensuringpaymentrequest)是以簡單瀏覽請求的開銷(expense)傳送(communicated)的。公司可以通過安裝多個伺服器來從事這一處理。然而，本發明允許即使在只有一個伺服器的情況下也能夠進行最佳的處理。根據一個實施例，該系統確定該請求將出現在優先級隊列中的何處，並且拒絕那些在該隊列之後的請求。其通過確定這些請求(例如HTTP請求)將被遞送到哪個工作負載管理器(workloadmanager)來使用最少的處理時間快速進4於這一處理。該HTTP請求通過一個排隊邏輯(queuinglogic)來進行句法分析(parsing),並且確定其目的地小服務程序(servlet)。管理員可以配置哪個小服務程序應當優先於(prioritized)其它小服務程序。句法分析於是暗示(implies)與那個小服務程序相關的特定工作負載管理器以及該請求的相應優先級。該請求並不被太嚴格的查看，而主要是在URL級上確定哪個工作負載管理器或小服務程序將處理該請求。該系統還可用於向用戶和管理員提供反饋，指示在當前某些請求將不被處理，但是例如其它請求可以被處理。這個消息還可以在合理的限度內進行定製，而這是現有技術所不能達成的。根據一個實施例，該系統被配置成指定各個工作負載管理器的閾值、以及全局過載閾值。請求被給出虛擬時間戳，並且根據優先級進行相應的排隊。當超過該閾值時，低於該閾值優先級的請求^皮拒絕。圖1示出了根據本發明的一個實施例的包括使用伺服器過載保護的系統的環境的視圖。具體實施例方式過載保護在伺服器和集群的總體可用性中扮演著重要的部分。在典型的應用伺服器和網絡伺服器環境中，在很短的時間內伺服器可能接收上千個請求。在特定的情況下伺服器將會變得過載並且不能再處理更多的請求。對於用戶來說，這會呈現為頁面錯誤或者凍結頁面。用戶通常通過請求來不斷地衝擊伺服器，而這實際上不具有任何效果並且只會使問題變得更糟。所需要的是一種能夠通知用戶當前伺服器過載的機制，並且這能夠允許該伺服器在不必處理更多請求的情況下重新獲得穩定性。傳統做法是產生一個伺服器"找不到對象"，或者將請求放置在一個固定長度的隊列中。然而，既沒有嘗試請求，也沒有例如拒絕那些將超過一分鐘的請求而服務其它請求。其它的實施並不了解過載條件並且繼續接受請求。接收請求將加重狀況導致更糟的性能和穩定性。所期望的是在這種情況下的請求的快速失敗。由於負載被在剩餘的集群成員中分散，這在集群的情況下能夠良好的工作。根據本發明的一個實施例，一種系統，例如一個伺服器或集群，被設計為每當伺服器變得過載時就產生一個消息和/或拒絕進一步的工作。這以一種處理器-效率方式來進行，以便不對已經高負荷的伺服器添加更多的壓力。該拒絕消息和動作是可定製的。然而，在定製為靈活的點和過度定製為添加更多處理器要求的點之間僅有很小的區別。最重要的是拒絕必須被快速地處理。傳統的方案不能適用於某些請求，例如保證支付請求是以簡單瀏覽請求的開銷傳送的。公司可以通過安裝多個伺服器來從事這一處理。然而，本發明允許即使在只有一個伺服器的情況下也能夠進行最佳的處理。根據一個實施例，該系統確定該請求將出現在優先級隊列中的何處，並且拒絕那些在該隊列之後的請求。其通過確定這些請求(例如HTTP請求)將被遞送到哪個工作負載管理器來使用最少的處理時間快速進行這一處理。該HTTP請求通過一個排隊邏輯來進行句法分析，並且確定其目的地小服務程序。管理員可以配置哪個小服務程序應當優先於其它小服務程序。句法分析於是暗示與那個小服務程序相關的特定工作負載管理器以及該請求的相應優先級。該請求並不被太嚴格的查看，而主要是在URL級上確定哪個工作負載管理器或小服務程序將處理該請求。該系統還可用於向用戶和管理員提供反饋，指示在當前某些請求將不被處理，但是例如其它請求可以被處理。這個消息還可以在合理的限度內進行定製，而這是現有技術所不能達成的。根據一個實施例，該系統被配置成指定各個工作負載管理器的閾值、以及全局過載閾值。請求被給出虛擬時間戳，並且根據優先級進行相應的排隊。當超過該閾值時，低於該閾值優先級的請求被拒絕。圖1示出了根據本發明的一個實施例的包括使用伺服器過載保護的系統的環境的視圖。如圖l所示，伺服器100接受來自多個客戶機102、104、106的請求。在這個例子中，伺服器100包括多個小服務程序108、110、112,每個小服務程序都有它們的相關工作負載管理器。伺服器包括伺服器狀態監視器116或類似的用於確定當前伺服器負載的機制。伺服器還包括優先級隊列118,用於在將請求傳送到小服務程序之前接受請求，以及排隊邏輯124,用於從伺服器狀態監視器接受狀態信息以及控制優先級隊列的進入。在操作中，當客戶機發出請求126、130、138時，給定當前的系統狀態，排隊邏輯將只對那些被認為可以接受的請求進行排隊。配置有更高優先級的小服務程序的請求被以更高的優先級排隊。配置有低的優先級的小服務程序將發現輸入的(incoming)請求被拒絕138，在某些例子中利用客戶機消息或動作來拒絕。示例實施下面的部分描述了一個示例實施，該示例實施包括在超過執行隊列長度、交易(transaction)計數、HTTP對話計數以及遭遇到OOME的時候所採取的過載動作。根據一個實施例，JRockit專用API被用於計算在每個GC間隔後的存儲器用量(memoryusage),並且當平均空閒存儲器低於所配置的閾值時提供通知。其通過將在過載集群中的RMI客戶機導向(directingto)還可以接受請求的成員來保證這些RMI客戶機的更快的失敗保護(failover)。術語定義，縮寫和簡寫過載一一種伺服器情況，其中接收更多的請求將導致伺服器性能和穩定性的惡化。伺服器已經超過了其資源容量，諸如可用的存儲器。OOM—由VM拋出(thrown)的java.lang.OutOfMemoryErrorFD—文件描述符OOM保護這種特徵使得伺服器在遭遇到OOM錯誤時能夠退出。在JRockitVM上，專用API被用於在每次全面(full)GC後計算存儲器用量，並在平均空閒存儲器降到閾值之下時產生事件(events)。OOM保護有兩個部分一在OOME時退出，以及在平均空閒存儲器降到閾值之下時的mbean通知。伺服器將在執行請求期間捕捉拋出的OOM錯誤，並在被配置為立即退出的情況下立即退出。這是基於應用程式本身不捕捉OOM錯誤的假定的。如果伺服器是由NodeManager或由HA解決方案支持的(backed),則該特徵是有用的。伺服器將以一個充分定義的、能夠和正常的VM中斷相區分的退出代碼來退出。在JRockit上，其管理API被用於在每次GC間隔後計算存儲器用量。如果平均空閒存儲器低於一個配置的閾值，則一個存儲器低的事件(lowmemoryevent)將被發送到註冊的監聽者(listener)。該伺服器被當作過載對待，並且採取配置的過載動作。注意通知機制的設計並不是JRockit專用的，而是將用於包括該功能的其它VM。在存儲器低的通知中可以建入(buildinto)滯後現象(hysteresis)。存在一個被使用的存儲器的上限，當該上限被達到後就發送存儲器低的通知。還存在一個下限，當該下限被達到後就撤銷存儲器低的通知。控制臺(console)可以具有包含下面選項的過載保護部分當遭遇OutOfMemoryError時的退出伺服器處理平均空閒存儲器閾值和計算空閒存儲器的存儲器樣本的數量。伺服器能夠捕捉在執行請求期間生成的OOME,並用充分定義的錯誤代碼來退出。這裡假定應用程式本身不處理OOME。系統將在內部子系統的任何可能的地方類似地處理OOME。管理員能夠將空閒存儲器閾值配置為總存儲器的百分比。在採用了這個閾值和配置的過載動作後，該伺服器被認為是過載的。用於確定存儲器低的情況的參數已經存在於ServerMbean(例如LowMemorySampleSize)中。該系統更進一步(goesonestepforther)並在JRockit和可比的VM產品上執行過載動作。J歸編程接口子系統可以利用標準MBean通知方案來為存儲器通知註冊。下面是一個例子1.向JVMRuntime添力口MemoryListenerJVMRuntimeMBeanjvmRuntime=serverRuntime.getJVMRuntime;mbeanServer.addNotificationListener(jvmRuntime.getObjectName,myMemoryListener，myMemoryFilter,null);2.MyMemoryFilter的實施importweblogic.management.runtime.MemoryNotification;publicclassMyMemoryFilterimplementsJavax.management.NotificationFilter{publicbooleanisNotificationEnabled(Notificationn){if(ninstanceofMemoryNotification){longfreeMemory=((MemoryNotification)n).getFreeMemory;longtotalMemory=((MemoryNotification)n).getTotalMemory;if(freeMemory<(0.2*totalMemory)){returntrue;returnfalse;}〃endofMyMemoryFilterweblogic.management.runtime.MemoryNotification可以有兩種方法,getFreeMemory禾口getTotalMemory。getFreeMemory返回在"ServerMbean丄owMemorySampleSize"採樣上的平均空閒存儲器。關於平均空閒存儲器的周期性的通知被發送到具有指定的通知過濾器的監聽者。如果沒有指定通知過濾器，則只有當空閒存儲器低於全局配置的存儲器閾值時才發送通知。執行隊列長度保護本特徵允許管理員限制在執行隊列中未完成的(outstanding)請求的數量。基本來說，管理員可以定義全局隊列閾值，在超過該閾值後請求將被扼殺(throttled)。自我調諧的分派模型還允許排隊的請求與OverloadManager相關。OverloadManager為那個請求類別確定最大未決請求。OverloadManager取代(override)全局隊列閾值。具有低公平共享(lowfairshare)的非-交易性RMI請求在過載伺服器中將被立即拒絕。這應用在單向、同步或非同步RMI中。如果過載條件繼續維持，則更高優先級的請求將開始被拒絕。對於這個規則有一些例外目的地為諸如JMS的子系統的請求和交易被允許進入，這是由於它們執行它們自己的過載管理。管理員(admin)請求被允許。除了(apartfrom)諸如控制臺的內部管理應用之外的網絡應用(webapp)請求將被立即拒絕。更快的RMI客戶端失敗保護如果某些或所有的集群節點都過載，則可集群化的RMI客戶機被給予一個特殊的ref。該特殊ref指向不過載並且還可以接收應用請求的集群節點。這將避免客戶端嘗試多哥集群節點並失敗。這一特徵使得RMI客戶機能夠快速識別在過載集群中的健康節點而不需要嘗試在複製列表(replicalist)中的每一項(entry)。如果管理員啟動新的集群節點來幫助減少過載，其將把客戶機導向新啟動的節點。每個伺服器的可用信息被以集群的節奏(heartbeat)發送。可用信息將說明該伺服器是否在運行、是否過載和是否被桂起(suspended)。如果伺服器超過了執行隊列閾值或者運行存儲器過低，則該伺服器被視為過載。可用信息被發送回客戶機並被如下使用集群中的所有伺服器都是健康的。發送回客戶機的複製列表將具有所有伺服器項。客戶機可以基於其負載平衡策略任意地選擇任何伺服器。集群中的一個或多個伺服器是過載的。作為連帶響應(piggybackresponse)的一個部分，系統將向指向不過載伺服器的客戶機發送特殊的ref。由於其具有更好的成功機會(change),客戶機將在其下一個請求中嘗試該特殊ref。在執行後，伺服器可以返回另一個特殊ref或者為下一個客戶機執行保留相同的一個。這種情況將持續直到過載的情況過去。如果有多個ref，則該伺服器輪換(rotates)特殊ref。如果啟動新的集群節點來降低過載的條件，該特殊ref將指向新啟動的節點。為了防止在新節點的泛濫(flooding),在幾次請求後可以撤銷該特殊ref。如果所有的集群節點都是過載的，則客戶機被請求不要再進行嘗試直到經過某個時段。等待時間是由伺服器的吞吐量、在執行隊列中的等待請求的數量等確定的。有效(active)交易限制本特徵允許管理員限制在伺服器中的有效交易的數量。一旦達到了最大的限制，伺服器將拒絕參與新的交易。注意與已有交易相關的RMI呼叫是允許進入的。只有試圖啟動新的交易的RMI呼叫將被禁止。控制臺可以具有指定交易限制的選項。當超過交易限制時，交易子系統^年拋出javax.transaction.SystemException。有效HTTP對話限制本特徵允許管理員限制在伺服器中的有效HTTP對話的數量。限制新對話的數量能避免OOME。如果達到了最大對話限制，系統將拒絕那些創建新HTTP對話的請求。在集群中，插件(plugin)將把請求導向另一個集群節點。在一個非-集群的情況下，伺服器可以將請求導向一個替代(alternate)伺服器。伺服器中允許的主HTTP對話的最大數量可以在控制臺中設置。對話限制是跨越所有應用的全局性的。如果達到了max-sessions限制，小服務程序包容器(container)將執行下列動作之一如果伺服器是在集群中，返迴響應503並且插件將對該請求進行失敗保護。如果該伺服器不在集群中但是指定了一個替代伺服器，則小服務程序包容器將該請求導向該替代伺服器。如果在網絡應用描述符中定義了過載-錯誤-頁面(overload-error-page),則伺服器將用其將過載響應返回客戶機。如果在控制臺中指定了過載重新導向(redirection)url,則其將被用來發送過載響應。死鎖一企測在JRockit上，系統能夠確定是否有線程死鎖(threaddeadlock)並且按照期望退出。這一特徵只在具有檢測線程死鎖能力的VM上才是可能的。伺服器將定期檢查卡住的(stuck)線程。如果超過一個線程被卡住，則系統使用JRockit管理API來檢查該線程是否巻入了死鎖。在這種情況下伺服器可以被配置為退出。如果伺服器是由NodeManager或諸如Veritas的HA解決方案支持的，則這是有用的。HA後端將重啟伺服器。這提供了自動的失敗恢復。注意該系統將只在同一處理中檢測死鎖。處理之間的死鎖是超出該範圍的。只有在伺服器中的所有的線程都卡住，並且自我-調諧線程模型不能添加更多的線程時才執行上述的動作。控制器可以具有在檢測到線程死鎖時退出伺服器進程的選項。伺服器將經常地監視其線程的健康狀況，並確定它們中的任何一個是否被卡住。卡住的時間間隔已經可以通過控制器來配置。如果超過一個線程被卡住，我們將使用JRockit管理API來檢查是否被卡住的線程巻入了死鎖。伺服器在結束(killing)自己之前在日誌中保存線程的轉儲(dump)。每個通道的FD保留管理員可以為每個網絡通道進行文件描述符的保留。這將使得管理員即使在DOS攻擊期間也能訪問伺服器。這將保證即使是在伺服器沉重負載的情況下，管理員用戶(adminuser)也總是能夠獲得對伺服器的訪問。即使在DOS攻擊期間，伺服器也將被管理。有可能為管理員用戶指定為每個網絡通道保留的FD的數量。伺服器將保證在任何時間為管理員用戶分配至少所保留的數量的FD。充分定義的退出代碼出代碼可以由shell腳本程序或HA代理來確定是否需要伺服器重啟。表1所示的退出代碼被定義用於伺服器終止。tableseeoriginaldocumentpage13表1過載伺服器狀態"過載"(OVERLOADED)狀態可以被添加為新的伺服器狀態。如果伺服器在運行但是不是過載的，則該狀態由ServerRuntimeMBean.getState和ServerLifeCycleRuntimeMbean.getState返回。或是由於所執行隊列長度達到其閾值或是由於存儲器低而發生過載條件。當過載條件消除(goaway)後，伺服器狀態將變回運行。狀態轉換如下1.關閉一〉待命一〉運行一〉過載一〉運行一〉關閉2.關閉一>待命一〉運行一〉過載一〉失敗一〉關閉在運行狀態中可用的操作也在過載狀態中得到支持。因此，伺服器還可以從過載狀態被掛起或關閉。具有單獨的過載狀態保證了過載條件;陂顯著地顯示在管理控制臺中並且通過各種MBean實用(utilities)。其也便於子系統向ServerLifeCycleRuntime添加通知監聽者以及得到作為正常狀態改變通知方案(scheme)的一部分的過載通知。本發明可以由傳統通用或專用數字計算機或者根據本公開編程的微處理器編程來實施。對於軟體領域技術人員顯而易見的是可以由有經驗的程式設計師基於本公開的教導來容易地準備適當的軟體編碼。介質(媒介)的電腦程式產品，其可被用於對計算機編程以執行本發明的任何處理。該存儲介質可以包括，但不局限於，軟盤、光碟、DVD、CD-ROM、微型石更盤(microdrive)以及磁光碟、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、閃速存儲設備、磁性或光學卡、納米系統(包括分子存儲器IC)或適合用於存儲指令和/霍數據的任何類型的媒介或設備。前面敘述的本發明用於說明和描述的目的而被提供。其不意味著窮盡性或為了將本發明限制在所公開的具體形式。選擇和描述實施例以便最好地說明本發明的原理及其實際應用，從而使得本領域的其它技術人員能夠理解本發明可用於很多實施例，並且具有適合於可想到的特定用途的改變。特別是，當描述使用JRockit或與JRockit—起使用的多種實施例時，顯然能夠使用其它的VM產品。本發明的範圍旨在由所附權利要求及其等價物來定義。權利要求1.一種用於提供具有過載保護的應用伺服器的系統，包括伺服器，其被配置來從客戶機接收請求，並且具有在其上操作的多個工作負載管理器；排隊邏輯，其確定由該請求被導向的工作負載管理器的優先級所確定的所接收的請求的優先級；和其中，所述排隊邏輯被配置來當伺服器狀態指示可能的過載條件時拒絕某種所述請求。2.如權利要求l所述的系統，其中每個工作負載管理器與一個小服務程序相關，並且其中所述請求被導向在所述伺服器上工作的小服務程序，並與所述工作負載管理器取得聯繫(reachedby)。3.4.如權利要求3所述的系統，其中所述可用線程時間部分被指定為用於一個工作負載管理器的允許的線程時間對於另一個工作負載管理器的相對的共享值。5.如權利要求l所述的系統，其中所述工作負載管理器可以由系統管理員來手動優先化。6.如權利要求5所述的系統，其中所述系統包括由所述系統管理員在優先化所述工作負載管理器中使用的控制臺應用程式。7.如權利要求l所述的系統，其中這樣根據目的地工作負載管理器優先化的請求根據它們的優先級被放置在隊列中。8.如權利要求7所述的系統，其中未被放置在隊列中的請求被拒絕。9.如權利要求l所述的系統，其中所述請求可以用返回客戶機的定製消息來拒絕。10.如權利要求l所述的系統，其中所述系統接收關於其用來確定可能的過載條件的伺服器的當前狀態的狀態信息。11.一種用於提供具有過載保護的應用伺服器的方法，其包括下列步驟:在伺服器接收來自客戶機的請求，所述伺服器具有多個在其上操作的工作負載管理器；確定由該請求被導向的工作負載管理器的優先級所確定的所接收的請求的優先級；和當伺服器狀態指示可能的過載條件時拒絕某種所述請求。12.如權利要求11所述的方法，其中每個工作負載管理器與一個小服務程序相關，並且其中所述請求被導向操作在所述伺服器的小服務程序，並與所述工作負載管理器取得聯繫(reachedby)。13.如權利要求11所述的方法，其中所述工作負載管理器是通過分配一部分可用的線程時間給它們使用來進行優先化的。14.如權利要求13所述的方法，其中所述可用線程時間部分被指定為用於一個工作負載管理器的允許的線程時間對於另一個工作負載管理器的相對的共享值。15.如權利要求11所述的方法，其中所述工作負載管理器可以由系統管理員來手動優先化。16.如權利要求15所述的方法，其中所述系統包括由所述系統管理員在優先化所述工作負載管理器中使用的控制臺應用程式。17.如權利要求11所述的方法，其中這樣根據目的地工作負載管理器優先化的所述請求根據它們的優先級被放置在隊列中。18.如權利要求17所述的方法，其中未被放置在隊列中的請求被拒絕。19.如權利要求11所述的方法，其中所述請求可以用返回客戶機的定製消息來拒絕。20.如權利要求11所述的方法，其中所述系統接收關於其用來確定可能的過載條件的伺服器的當前狀態的狀態信息。21.—種計算機可讀介質，包括存儲在其上的當被執行時使得所述計算機執行下列步驟的指令在伺服器接收來自客戶機的請求，所述伺服器具有多個在其上操作的工作負載管理器；確定由該請求被導向的工作負載管理器的優先級所確定的所接收的請求的優先級；和當伺服器狀態指示可能的過載條件時拒絕某種所述請求。全文摘要一種用於具有過載保護的應用伺服器的系統和方法。一種系統，例如一個伺服器或集群，被設計成每當伺服器過載時就生成一個消息和/或拒絕進一步的工作。其使用處理器-效率的方式來進行，以便不對已經高負荷的伺服器添加更多的壓力。拒絕消息或動作是可定製的。根據一個實施例，該系統確定在優先級隊列中該請求應該在哪裡出現，並拒絕那些在該隊列之後的請求。通過確定該請求將被遞送到哪個工作負載管理器，其能快速和使用最少的處理時間來這樣做。文檔編號G06F9/54GK101305346SQ200580001186公開日2008年11月12日申請日期2005年5月20日優先權日2004年5月21日發明者安諾·R·蘭根,納裡什·裡瓦納魯申請人:Bea系統公司