Laboratuvar 1.1 Kilitlenme sorununu yeniden oluşturma ve giderme

Şunlar için geçerlidir: .NET Core 2.1, .NET Core 3.1, .NET 5

Bu makalede Linux'ta .NET Core kilitlenme sorununu yeniden oluşturma işlemi tanıtılmaktadır. Bu makalede ayrıca Nginx aracının ve sistem günlüklerinin kilitlenme belirtileri ve göstergeleri için nasıl denetlenecekleri açıklanır.

Önkoşullar

Bu sorun giderme laboratuvarlarını izlemenin en düşük gereksinimi, düşük CPU ve yüksek CPU performans sorunlarını göstermek için bir ASP.NET Core uygulamasına sahip olmaktır.

İnternet'te bu hedefe ulaşmak için birkaç örnek uygulama bulabilirsiniz. Örneğin, istenmeyen davranışları göstermek için Microsoft'un basit webapi örneğini indirip ayarlayabilirsiniz. Alternatif olarak, örnek proje olarak BuggyAmb ASP.NET Core uygulamasını da kullanabilirsiniz.

Bu serinin önceki bölümlerini izlediyseniz, aşağıdaki kurulumun hazır olması gerekir:

• Nginx, iki web sitesini barındıracak şekilde yapılandırılmıştır:
  • İlki, myfirstwebsite ana bilgisayar üst bilgisini (http://myfirstwebsite) kullanarak istekleri dinler ve istekleri 5000 numaralı bağlantı noktasını dinleyen demo ASP.NET Core uygulamasına yönlendirir.
  • İkincisi, buggyamb ana bilgisayar üst bilgisini (http://buggyamb) kullanarak istekleri dinler ve istekleri 5001 numaralı bağlantı noktasını dinleyen ikinci ASP.NET Core örnek buggy uygulamasına yönlendirir.
• Her iki ASP.NET Core uygulaması da sunucu yeniden başlatıldığında veya uygulama yanıt vermeyi durdurduğunda otomatik olarak yeniden başlatılan hizmetler olarak çalışıyor olmalıdır.
• Linux yerel güvenlik duvarı etkinleştirilir ve SSH ve HTTP trafiğine izin verecek şekilde yapılandırılır.

Not

Kurulumunuz hazır değilse "2. Bölüm ASP.NET Core uygulamaları oluşturma ve çalıştırma" bölümüne gidin.

Bu laboratuvara devam etmek için Nginx'in arkasında çalışan en az bir sorunlu ASP.NET Core web uygulamanız olmalıdır.

Bu laboratuvarın hedefi

Bu makale iki laboratuvar bölümünden ilkidir. Laboratuvar çalışması aşağıdaki gibi bölünür:

• Bölüm 1: Kilitlenme sorununu yeniden oluşturacak, Nginx ve sistem günlüklerini denetleyerek kilitlenme belirtilerini ve göstergelerini arayacaksınız ve ardından kilitlenme dökümü dosyası oluşturarak sorun gidereceksiniz. Son olarak, Ubuntu yöneticisi apport tarafından oluşturulan kilitlenme raporundan sistem tarafından oluşturulan çekirdek döküm dosyasını toplayacaksınız.

• Bölüm 2: LLdb'yi yükleyecek ve SOS adlı bir .NET Core hata ayıklayıcısı uzantısıyla birlikte çalışacak şekilde yapılandıracaksınız. Ayrıca lldb'deki döküm dosyasını da analiz edersiniz.

Kilitlenme sorununu yeniden oluşturma

site URL'sine http://buggyamb/göz atıp Sorun Sayfaları bağlantısını seçtiğinizde bazı sorun senaryolarının bağlantılarını görürsünüz. Üç farklı kilitlenme senaryosu vardır. Ancak bu laboratuvar için yalnızca üçüncü kilitlenme senaryosunda sorun gidereceksiniz.

Herhangi bir bağlantıyı seçmeden önce Beklenen Sonuçlar'ı seçin ve uygulamanızın beklendiği gibi çalıştığını doğrulayın. Aşağıdakine benzer bir çıkış görmeniz gerekir.

Sayfa hızla yüklenmeli (bir saniyeden kısa sürede) ve ürünlerin listesini görüntülemelidir.

İlk "yavaş sayfa" senaryoyu test etmek için Yavaş bağlantısını seçin. Sayfa sonunda Beklenen Sonuçlar sayfasıyla aynı çıkışı gösterir, ancak beklenenden çok daha yavaş işlenir.

Kilitlenme sorununu yeniden oluşturmadan önce buggy uygulamasının işlem kimliğini not edin. Uygulamanızın yeniden başlatıldığını doğrulamak için bu bilgileri kullanacaksınız. Geçerli PID'yi systemctl status buggyamb.service almak için komutunu çalıştırın. Aşağıdaki sonuçlarda, hizmeti çalıştıran işlemin PID'i 2255'tir.

Kilitlenme 3 bağlantısını seçin. Sayfa yüklenir ve aşağıdaki iletiyi görüntüler:

Bu ileti kullanıcıdan şu soruyu düşünmesini ister: Bu sayfa işlemin kilitlenmesine neden olacak mı? Aynı systemctl status buggyamb.service komutu çalıştırdığınızda aynı PID'yi görmeniz gerekir. Bu, kilitlenmenin gerçekleşmediğini gösterir.

Beklenen Sonuçlar'ı ve ardından Yavaş'ı seçin. Beklenen Sonuçlar'ı seçtikten sonra doğru sayfayı görmeniz gerekir ancak Yavaş'ı seçtiğinizde aşağıdaki hata iletisi oluşturulmalıdır.

Web sayfasında başka bir bağlantı seçseniz bile, kısa bir süre için aynı hatayla karşılaşırsınız. 10-15 saniye sonra her şey yeniden beklendiği gibi yanıt vermeye başlar.

PID'nin değiştirilip değiştirilmediğini denetlemek için yeniden çalıştırın systemctl status buggyamb.service . Bu kez, PID değiştirildiğinden işlemin durdurulmuş gibi göründüğünü fark etmelisiniz. Önceki örnekte PID işlemi 2255 idi. Aşağıdaki örnekte 2943 olarak değiştirilmiştir. Görünüşe göre, web sitesi süreci çökertmek için söz verdi iyi yaptı.

Yeniden oluşturma adımlarının sorunlarını giderme

Yeniden oluşturma adımlarının özeti aşağıdadır:

1. Kilitlenme 3'e tıklayın. Sayfa doğru şekilde yüklenir, ancak işlemin kilitlenmesini öneren kafa karıştırıcı bir ileti döndürür.
2. Yavaş'ı seçin. Ürün tablosu yerine "HTTP 502 - Hatalı Ağ Geçidi" hata iletisi alırsınız.
3. Sorun başladıktan sonra, sayfaların hiçbiri sonraki 10-15 saniye boyunca işlenmez.
4. 10-15 saniye sonra uygulama doğru yanıt vermeye başlar.

"HTTP 502 - Hatalı Ağ Geçidi" hata iletisi size pek bir şey anlatmıyor. Ancak, ilk ipucunu sağlamalıdır: Bu bir ara sunucu hatasıdır ve bir ara sunucu proxy'nin arkasında çalışan uygulamayla iletişim kuramazsa oluşabilir. Önerilen kurulumda Nginx, ASP.NET Core uygulamasının ters ara sunucusu olarak çalışıyor. Bu nedenle, Nginx'ten gelen bu hata, gelen istekleri ilettiğinde arka uç uygulamasına erişemeyeceğini gösterir.

Nginx'in düzgün çalıştığını doğrulayın

Devam etmeden önce Nginx'in düzgün çalışıp çalışmadığını denetlemek isteyebilirsiniz. Uygulamanın kilitlendiğini bildiğiniz için bu adım zorunlu değildir. Ancak, Nginx günlüklerini denetleyerek Nginx'in durumunu doğrulamaya devam edebilirsiniz. Daha önce "Nginx'i yükleme ve yapılandırma" bölümünde benzer sorun giderme adımları uygulaymıştınız.

Nginx'in iki tür günlüğü vardır: Erişim günlükleri ve hata günlükleri. Bunlar klasöründe depolanır /var/log/nginx/ .

Erişim günlükleri tıpkı IIS günlük dosyaları gibidir. Önceki bölümde yaptığınız gibi bunları açın ve inceleyin. Günlüklerde, sitenin sayfalarında gezinme girişimleri sırasında zaten karşılaştığınız "HTTP 502" yanıt durumu kodu dışında yeni bilgiler gösterilmez.

komutunu kullanarak cat /var/log/nginx/error.log hata günlüklerini inceleyin. Bu günlük daha yararlı ve nettir. Nginx'in isteği işleyebildiğinden, Nginx ile buggy uygulaması arasındaki bağlantının son yanıt gönderilmeden önce kapandığını gösterir.

Bu günlük, gördüğünüz şeyin bir Nginx sorunu olmadığını açıkça gösterir.

journalctl komutunu kullanarak sistem günlüklerini denetleme

ASP.NET Core uygulaması kilitleniyorsa belirtiler bir yerde görünmelidir.

Buggy uygulaması bir sistem hizmeti olarak çalıştığından, işlemi sistem günlük dosyalarına kaydedilir. Sistem günlük dosyaları, Windows'taki sistem olay günlükleri gibidir. journalctl komutu, sistemli günlükleri görüntülemek ve işlemek için kullanılır.

Tüm günlükleri görmek için anahtarı olmadan komutunu çalıştırabilirsiniz journalctl . Ancak, çıkış büyük bir dosya olacaktır. İçeriği filtrelemeyi öğrenmek sizin yararınıza olur. Örneğin, aşağıdaki komutu çalıştırabilirsiniz:

journalctl -r --identifier=buggyamb-identifier --since "10 minute ago"

Aşağıdaki anahtarlar kullanılabilir:

• -r: En yeninin ilk sırada listelenmesi için günlükleri ters sırada yazdırın.
• --identifier: Test uygulamasının SyslogIdentifier=buggyamb-identifier hizmet dosyasındaki satırı unutmayın. (Günlükleri yalnızca sorunlu uygulamaya uygulanan girişleri göstermeye zorlamak için bunu kullanabilirsiniz.)
• --since: Belirtilen önceki dönemde günlüğe kaydedilen bilgileri gösterir. Örnek: --since "10 minute ago" veya --since "2 hour ago".

Komut için journalctl günlükleri filtrelemenize yardımcı olabilecek birkaç yararlı anahtar vardır. Bu komut hakkında bilgi edinmek için komutunu çalıştırarak man journalctlyardım sayfasına başvurmanızı öneririz.

journalctl -r --identifier=buggyamb-identifier --since today -o cat'i çalıştırın. Bazı uyarı iletilerinin oluşturulduğunu fark etmelisiniz.

Ayrıntıları görmek için ok tuşlarını kullanarak aşağı kaydırın. Bir özel durum bulacaksınız System.Net.WebException .

Günlükleri yakından incelerseniz, kod dosyası adını ve sorunun oluştuğu satır numarasını görürsünüz. Bu laboratuvarda bu bilgilerin kullanılamadığını varsayacağız. Bunun nedeni, gerçek dünya senaryolarında bu tür bilgileri alamayabilirsiniz. Bu nedenle, amaç kilitlenmenin nedenini öğrenmek için bir kilitlenme dökümünü analiz ederek devam etmektir.

Kilitlenmeden sonra çekirdek döküm dosyası alma

Bir işlem sonlandırıldığında önemli sistem davranışlarından bazılarını hatırlayın:

• Varsayılan olarak, çekirdek döküm dosyası oluşturulur.
• Çekirdek dökümü core olarak adlandırılır ve geçerli çalışma klasöründe veya /var/lib/systemd/coredump klasöründe oluşturulur.

Varsayılan davranış sistemin bir çekirdek döküm dosyası oluşturması olsa da /proc/sys/kernel/core_pattern , sonuçta elde edilen çekirdek döküm dosyasını doğrudan başka bir uygulamaya aktarmak için bu ayarın üzerine yazılabilir. Bu serinin önceki bölümlerinde Ubuntu kullandığınızda apport'un Ubuntu'da çekirdek döküm dosyası oluşturmayı yönettiğini öğrendiniz. Çekirdek core_pattern dökümünü apport'a yöneltmek için dosyanın üzerine yazılır.

Apport, rapor dosyalarını depolamak için klasörü kullanır /var/crash . Bu klasörü incelerseniz, kilitlenme sonrasında zaten oluşturulmuş bir dosya görmeniz gerekir.

Ancak, bu çekirdek döküm dosyası değildir. Bu, döküm dosyasıyla birlikte birkaç bilgi parçası içeren bir rapor dosyasıdır. Çekirdek döküm dosyasını almak için bu dosyayı çıkarmanız gerekir.

Giriş klasörünüzün altında bir dökümler klasörü oluşturun. Raporu orada ayıklamanız istenir. apport rapor dosyasının paketini açma komutu şeklindedir apport-unpack. Şu komutu çalıştırın:

sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet

Bu komut /dumps klasörünü oluşturur. apport-unpack Komutu /dumps/dotnet klasörünü oluşturur. Sonuç şu şekildedir.

~/dumps/dotnet klasöründe döküm dosyasını görmeniz gerekir. Dosya CoreDump olarak adlandırılır ve yaklaşık 191 MB olmalıdır.

Otomatik olarak oluşturulan çekirdek döküm dosyasını ayıklamak zahmetli bir işlem olabilir. Sonraki laboratuvarda kullanarak çekirdek döküm dosyalarını createdumpyakalamanın daha kolay olduğunu göreceksiniz.

Sonraki adımlar

Laboratuvar 1.2 Lldb hata ayıklayıcısında sistem tarafından oluşturulan çekirdek döküm dosyalarını açın ve analiz edin, hızlı bir analiz yapmak için lldb hata ayıklayıcısında bu döküm dosyasının nasıl açabileceğinizi göreceksiniz.