文章版權由做者李曉暉和博客園共有,若轉載請於明顯處標明出處:http://www.cnblogs.com/naaoveGIS/。sql
最近連續有兩個項目現場出現了AGS服務蕩掉的問題,一個是通州現場,一個是福州現場。數據庫
通州現場環境爲ArcGIS9.2,使用IMS發佈的地圖服務,其問題表現爲每隔兩天左右,其地形圖服務便會崩潰一次,重啓地形圖服務後地圖能夠正常顯示。緩存
由於IMS中地圖的出圖爲動態出圖,因此其出圖時須要經過鏈接SDE,此問題的出現極可能是SDE中最大鏈接數的問題。服務器
福州現場環境爲ArcGIS10.0,使用的ArcGIS Server發佈的矢量服務(Map Server),其問題表現爲基本天天矢量服務都會蕩掉一次,重啓後,系統即可以正常運行。微信
矢量服務蕩掉有不少種緣由,猜測了以下幾種可能:性能
(1)沒有按期清除ArcGIS Server中的緩存,致使緩存過多而蕩掉。操作系統
(2)因爲Windows防火牆的緣由,Context和SDE的鏈接限制一段時間後,會被系統Kill掉,然而Context並不知情,因而在空閒一段時間後的第一次訪問中,仍然使用該連接,鏈接不上SDE致使Crash。rest
(3)矢量查詢須要經過SDE鏈接數據庫,會不會SDE的最大鏈接數設置少了,致使服務蕩掉。日誌
(4)由於矢量查詢時一樣須要用到數據庫中的遊標,會不會數據庫的最大遊標數設置少了,致使服務蕩掉。server
SDE的默認鏈接數是48個,修改它有兩種方式,一種是經過註冊表,一種是經過數據庫。這裏我將兩種修改方式都作一個介紹。
打開SDE的安裝目錄下的(通常安裝路徑爲C:\ arcgis\ArcSDE\sqlexe\etc)giomgr.defs文件進行編輯,設置CONNECTIONS參數爲你的最大鏈接數。經過命令導入到數據庫中:sdeconfig –o import –f C:\arcgis\ArcSDE\sqlexe\etc\giomgr.defs –i esri_sde(數據庫實例名) –s (ServerName) –u sde(用戶名) –p sde(密碼) 。 設置好後須要重啓SDE服務才能生效。
運行select * from sde.server_config;在這個表中修改CONNECTIONS的NUM_PROP_VALUE便可。
可以刪除無效鏈接的最大功臣就是TCPKEEPALIVE了。TCPKEEPALIVE參數能夠控制數據庫是否會根據已配置好的間隔時間來定時檢查鏈接是否爲無效鏈接,若是是,則自動刪除該鏈接。
例如,當TCPKEEPALIVE參數設置爲TRUE後,數據庫會根據SDE服務所在機器的註冊表項KEEPALIVETIME所提供的響應時間,不斷偵測全部鏈接是否爲無效鏈接,若是爲無效鏈接,則自動刪除該鏈接。
此參數的修改跟SDE的最大鏈接數的修改方式同樣,有兩種方式,具體能夠參考上節描述的方法。
這裏涉及到另一個參數:KEEPALIVETIME。
對於操做系統默認安裝的機器來講,KEEPALIVETIME註冊表項是沒有的,而若是沒有話,服務器不會主動發送發送KeepAlive數據包來確認空閒鏈接是否依然毫無變化,也就不會進行刪除操做。因此上面提到的無效鏈接會愈來愈多。咱們能夠在以下路徑中:Local_Machine\system\CurrentControlSet\Services\Tcpip\Parameters 添加DWORD項:KeepAliveTime。這樣系統的註冊表中便有了KEEPALIVETIME項。
若是系統中已經有了KEEPALIVETIME項,咱們不填寫它的值時,它默認的就是兩小時。根據網上別人的經驗,推薦設置爲5分鐘。不過具體狀況根據項目來定,最後重啓SDE才能生效。
咱們在給通州現場設置了以上三個配置後,過了兩天,現場反映地圖服務仍是蕩掉了。因而咱們再次查資料,發現還有一個關鍵的地方須要配置——SharedSection。
Windows爲每一個服務分配了一個固定大小的內存(默認512K)。每一個sde進程大約須要9K內存,所以sde默認的鏈接數爲512/9約等於48。
若是咱們不修改這個固定大小內存的配置,即便咱們已經將SDE的最大鏈接數配置改爲了128,同樣沒法生效。
按照上面的換算方法,9*128=1152,而後咱們適當的將其改爲1024。
最後咱們在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows 項中找到SharedSection,並將原SharedSection=1024,3072,512中的第三項改成1024。改完後,到目前已通過了兩週,現場反映地圖服務沒有蕩掉過。
經過http://192.168.101.9:8399/arcgis/rest/admin這個鏈接進入管理頁面,而後設置天天的一個時刻按期清除緩存。給現場修改後,次日現場工程人員回覆仍是蕩掉了。
在服務的ServiceProperties裏面設置這個按期檢查鏈接的時間間隔。給現場修改的是30分鐘。次日問現場,現場反饋服務仍是蕩掉了。
仔細觀察錯誤日誌,發如今衆多報錯中有以下一個錯誤。猜測數據庫遊標數可能設置小了。
經過show parameter open_cursors;查看現場的遊標數目爲250。
經過select count(*) from v$open_cursor ;查看現場目前的遊標打開的數目,發如今矢量服務關閉了的狀況下,這個數目已通過了200。
經過alter system set open_cursors=2000 scope=both;將遊標數目變大。
爲保險起見,經過上面提到過的幾個步驟,將SDE的最大鏈接數以及殺進程的配置等所有修改。
目前已通過了兩週,現場沒再出現服務蕩掉的狀況。
不過我總擔憂遊標數設置大了會影響系統,由於,遊標在shared pool佔有必定的內存,太多會帶來浪費,固然也不能太少,太少的話會給系統帶來必定壓力,引發系統內存爭搶。
今天詢問了下公司在北京的DBA,他告訴我,遊標數量根據現場環境不一樣而不一樣,若是會話很少,建議使用會話數*5來設置,若是多的話,好比超過200個會話,那*3也能夠,而且,遊標數多少對性能影響小,若是你內存資源充足,能夠多設置點。
我給現場設置的是2000,這樣看來是合理的。
(1)只修改SDE最大鏈接數,而不修改註冊表中的SharedSection,是無效果的。
(2)因爲矢量查詢與數據庫是有直接聯繫的,每一次查詢均須要使用遊標,若是數據庫中的遊標設置過小,容易引發矢量查詢的崩潰。
-----歡迎轉載,但保留版權,請於明顯處標明出處:http://www.cnblogs.com/naaoveGIS/
若是您以爲本文確實幫助了您,能夠微信掃一掃,進行小額的打賞和鼓勵,謝謝 ^_^