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:

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/55f71614-ef1b-4015-b9c8-a42c1e700c25.mspx?mfr=true

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:

Rapid Fail Protection

IIS 7.0:

Rapid Fail Protection

"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:

  1. IIS logları
  2. HTTPERR logları
  3. 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

Comments (13)
  1. Okan says:

    Merhaba,

    Çok yararlı bir kaynak olmuş.

    Benim sorunum aslında bu noktada iis7 üzerinde php çalıştırıyorum sitemde gezilirken bazen fastcgi process error alıyorum hemen ardından sayfayı yenilediğimde sayfa geliyor.

    acaba sorunumun nedeni Rapid fail protection mıdır?

    teşekkürler.

  2. Elinize sağlık sizin sayenizde var olan problemimi çözmüş bulunuyorum.

    iyi çalışmalar.

  3. adem says:

    hiç yararlı değl çünkü bu işlemler nerdenyapılacak anlatmamışsın teorik bilgi olarak kalmış

  4. jetpac says:

    Oldukça aydınlatıcı. Teşekkürler.

  5. Kayhan Kayıhan says:

    Merhaba,

    bilgi paylaşımınız için teşekürler ancak bu işlemi kapattığımda pool u stop start ettiğim de çalışan sitelerde problem oldu.

    Deneyen arkadaşlara tavsiye kapatmak yerine zaman düşürmek olabilir.

  6. CenkIscan says:

    Eğer rapid-fail protection ayarından bahsediyorsanız, bunu kapatmanın aldığınız hatalarla alakalı olması mümkün değildir. Yaşadığınız sorunun nedenini başka yerlerde aramanızı öneririm.

  7. ömer says:

    cok iyi olmuş,cok da guzel olmus..Tam bir reçete gibi olmuş 😉

  8. sinan oğuzer says:

    cenk bey gamesliga.biz sitesinde 503 hatası veriyor nerden nereye girip bu ayarları yapmalıyım yardımcı olurmusunz ?

  9. CenkIscan says:

    HTTPErr loglarından 503 hatasının nedenine bakmalısınız yukarıda anlattığım gibi. Bir de application pool'larınız disable olmuş mu kontrol edin. Eğer disable görüyorsanız üzerine sağ tıklayıp start etmeniz gerekecektir.

  10. çokkk sağol says:

    saol kardeş sorunu çözdümmm eyvallahh

  11. hülya says:

    bu application pool ayarlarına nereden ulaşıcaz sayfada ben hiç bilmiyorumda yardımcı olabilirseniz çok sevinirim.

  12. CenkIscan says:

    İlgili application pool'a sağ tıkladığınızda, IIS 6.0 için Properties, 7.0 ve sonrası için Advanced Settings altında yukarıdaki ekran görüntülerindeki ayarları yapabilirsiniz.

  13. Asım Nesli says:

    Merhaba  Cenk Bey,

    iis6 da çlaışan bir uygulamayı iis 8  üzerine  taşıdım,  503 hatası  alıyor ve apppool   stop oluyor, start edip tekrar request yapınca,  yine stop oluyor.  sorunu nasıl tespit edebilirmi. nerelere bakmam  gerekir.

    iis 6 ve iis8  application poolar aynı ayarlara sahip.

Comments are closed.

Skip to main content