Service unavailable
Bu hata, genelde boş beyaz bir sayfada, oldukça iri puntolarla karşımıza çıkar. Başka bir açıklama içermez ve genellikle IIS'i yeniden başlatana kadar da kurtulamayız. Hangi nedenlerle bunu alırız? Nasıl önüne geçebiliriz?
"503 - Service unavailable" hataları, IIS'in http.sys isimli sürücüsü tarafından verilir. Yani çekirdek (kernel) seviyesinde alınırlar. Dolayısıyla, bu hatalarla ilgili kayıtlar IIS'in kayıtlarında değil HTTPERR loglarında bulunur ve detayları, güvenlik gerekçesiyle, kullanıcılara gönderilmez. HTTPERR loglarında, bu hatanın nedenine dair bir de tanım görebiliriz. Bu tanımların listesi aşağıdaki linkte detaylarıyla verilmiştir:
Ben bu yazımda, en çok rastladğımız nedenlerin neler olduğundan ve bunların nasıl çözüleceğinden bahsedeceğim.
AppOffline
Bize gelen destek çağrılarından "Service unavailable" hatası ile ilgili olanların çok büyük kısmının nedeni "AppOffline" durumudur. Yukarıdaki makalede de bahsedildiği üzere, bu, ilgili "uygulama havuzu"nun (application pool) "Rapid fail protection" nedeniyle kapatıldığı anlamına gelmektedir. Aslında durumun çözümü çok basittir: "IIS Manager"da ilgili uygulama havuzuna sağ tıklayıp başlatmak yeterli olacaktır. Ancak bu, "Rapid fail protection" tekrar devreye girip, havuzu tekrar kapatana kadar çözüm olacaktır.
Tam bu noktada "rapid fail protection" özelliğinin tanımını yapalım: Herhangi bir uygulama havuzuna ait bir "worker process"te (w3wp.exe) bir sorun olur da kapanırsa ("crash" olursa), IIS tarafından hemen bir yenisi açılır ve yeni gelen istekler ona yönlendirilir. Bu arada kapanan uygulamada çalışan istekler yarım kalacaktır ama en azından daha sonra gelen istekler sorunsuz bir şekilde yanıtlanmaya devam edecektir. Ancak, eğer çok kısa bir zaman zarfında bu kapanma sorunu çok sık oluşmaya başlarsa ne yapmak gerekir? İşte "rapid fail protection" tam olarak bu noktada devreye girer. Eğer sorun çok sık ortaya çıkmaya başlarsa, kapanan uygulamayı yeniden başlatmaz ("disable" eder) ve kullanıcıların hata görmesini sağlar. Görülecek hatayı sanırım tahmin etmişsinizdir: Service Unavailable. Bu durum gerçekleştiğinde olay günlüklerinde (event log) aşağıdaki gibi bir kayıt görürüz:
IIS 6.0:
Event Type: Error
Event Source: W3SVC
Event Category: None
Event ID: 1002
Date: 14.01.2009
Time: 11:11:20
User: N/A
Computer: Win2K3Server
Description:
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.IIS 7.0:
Log Name: System
Source: Microsoft-Windows-WAS
Date: 1/14/2009 11:07:16 AM
Event ID: 5002
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Win2K8Server
Description:
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
IIS 6.0 ve 7.0'da, her bir uygulama havuzunun "rapid fail protection" ayarı vardır. Bu ayar, ön tanımlı olarak aşağıdaki şekilde tanımlıdır:
IIS 6.0:
IIS 7.0:
"Rapid fail protection" açık olduğunda (Enabled = True) - ki biz kapatmadıysak açıktır - bizi en çok ilgilendiren parametreler şunlardır: "Failure Interval (minutes)" ve "Maximum Failures". Bu iki parametre ile bir uygulama havuzunda ne kadar sürede kaç hata alınırsa yeniden açılmayacağı tanımını yapmış oluyoruz. Yani yukarıdaki ayarlarla, eğer bir havuz 5 dakika içinde 5 defa bir sorun nedeniyle kapanacak olursa, altıncı defa çalılştırılmayacaktır.
Bu ayarlarla ilgili benim önerim "rapid fail protection"ın kapatılması yönünde olmayacaktır. Ancak belki 5 dakikada 5 defa değil de, 2-3 dakikada 5 defa gibi bir değişiklik yapmayı tercih edebilirsiniz. Buna tamamen sizin önceliklerinize ve uygulamanıza göre karar vermeniz gerekir. Elbette crash ve sonrasında tekrar ayağa kalkma süresini de göz önünde bulundurmanız gerekecektir.
En başta da söylediğim gibi, ilgili havuzu yeniden başlatarak bu sorunu çözebiliriz. Ancak burada önemli olan uygulamanın neden kapandığını tespit etmek olmalıdır. Bunun için de, eğer uygulamamız ASP.NET 2.0 ise olay günlüklerinde nedenine dair bir kayıt bulma ihtimalimiz olacaktır. Aksi takdirde "memory dump" alarak sorunun nedenini araştırmak gerekebilir.
AppPoolTimer
AppOffline kadar çok olmasa da bu da çokça karşılaştığımız nedenlerden biridir.
Her bir uygulama havuzunun, http.sys sürücüsünde bir kuyruğu bulunmktadır. Gelen istekler, http.sys tarafından bu kuyruğa bırakılırlar ve sırası gelen, ilgili w3wp.exe tarafında buradan alınıp işlenir. Ancak bazı durumlarda, w3wp.exe o kadar meşguldur ki, kuyruktan yeni bir istek alamaz. İşte bir istek bu kuyrukta çok uzun süre bekleyecek olursa, HTTPERR logunda AppPoolTimer şeklinde kaydedilen bir 503 hatası alır. Bu sorunun çözümü için, ilgili uygulamanın neden ve neyle bu kadar meşgul olduğunu tespit etmek gerekir, ki bu da genelde "memory dump" analizi ile mümkün olabilir.
ConnLimit
Oldukça nadiren de olsa, IIS üzerindeki uygulamamıza gelecek olan istek miktarını kısıtlamak isteyebiliriz. Bunu yaptığımız takdirde (ki normalde böyle bir limit tanımlı değildir), bu limit aşıldığı anda yeni istekler "Service unavailable" yanıtı alacaklardır. Bunun AppOffline'dan en temel farkı şudur: AppOffline durumunda, biz sorunu giderene kadar tüm istekler 503 alır. Ancak ConnLimit'te, bazı istekler yanıtlanırken bazıları 503 alabilir. Hatta bir kullanıcı sayfayı güncelledikçe, bazen 503 alıp bazen almayabilir. Bunun çözümü, ortaya çıkma nedeninden tahmin edebileceğiniz gibi, limiti artırmak veya tamamen kaldırmak olacaktır.
SONUÇ
Diğer nedenler üzerinde durmayacağım. Herbiriyle ilgili bilgileri yukarıdaki linkte bulabilirsiniz.
Sadece bu hata mesajına özgü olarak değil, IIS üzerinde çalışan uygulamalarla ilgili yaşanan sorunlarlın detaylarını görebileceğimiz 3 temel yer vardır:
- IIS logları
- HTTPERR logları
- Olay günlükleri
Bu üç kaynaktan toplayacağımız bilgilerle, hemen her sorunun nedenini bulabiliriz. Ancak tabii ki sorunun nedenini bulmak her zaman sorunu çözebilmek anlamına gelmeyebilir.
CENK ISCAN