Performans senaryolarını keşfetme

  • 5 dakika

Performans araçlarının ve özelliklerinin nasıl kullanılacağına karar vermek için senaryolar aracılığıyla Azure SQL'in performansına göz atmak önemlidir.

Yaygın performans senaryolarını anlama

SQL Server performans sorunlarını gidermeye yönelik yaygın bir teknik, bir performans sorununun Çalışıyor (yüksek CPU) veya Bekleme (kaynak beklerken) olup olmadığını incelemektir. Aşağıdaki diyagramda SQL Server performans sorununun çalışma sorunu mu yoksa bekleme sorunu mu olduğunu belirleyen bir karar ağacı ve sorunun nedeniyle çözümünü belirlemeye yönelik performans araçlarının nasıl kullanacağı gösterilir.

Koşma ve bekleme diyagramı.

Öncelikle genel kaynak kullanımına bakın. Standart bir SQL Server dağıtımı için Windows'ta Performans İzleyicisi veya Linux'ta üst gibi araçları kullanabilirsiniz. Azure SQL için aşağıdaki yöntemleri kullanabilirsiniz:

  • Azure portal/PowerShell/uyarılar

    Azure İzleyici'nin Azure SQL kaynak kullanımını izlemek için tümleşik ölçümleri vardır. Kaynak kullanımı koşullarını bulmak için uyarıları da ayarlayabilirsiniz.

  • sys.dm_db_resource_stats

    Azure SQL Veritabanı için, bu DVM’ye bakarak veritabanı dağıtımının CPU, bellek ve G/Ç kaynağı kullanımını görebilirsiniz. Bu DVM 15 saniyede bir verilerin anlık görüntüsünü alır.

  • sys.server_resource_stats

    Bu DMV, sys.dm_db_resource_stats gibi davranır, ancak SQL Yönetilen Örneğinin CPU, bellek ve G/Ç kaynak kullanımını görmek için kullanılır. Bu DVM de 15 saniyede bir anlık görüntü alır.

  • sys.dm_user_db_resource_governance

    Azure SQL Veritabanı için bu DMV, geçerli veritabanında veya elastik havuzda kaynak idare mekanizmaları tarafından kullanılan gerçek yapılandırma ve kapasite ayarlarını döndürür.

  • sys.dm_instance_resource_governance

    Azure SQL Yönetilen Örneği için bu DMV, geçerli SQL Yönetilen Örneği ile benzer bilgiler sys.dm_user_db_resource_governancedöndürür.

Koşmak

Sorunun yüksek CPU kullanımı olduğunu belirlediyseniz, bu çalışma senaryosu olarak adlandırılır. Çalışma senaryoları derleme veya yürütme işlemleri aracılığıyla kaynak tüketen sorgular içerebilir. Daha ayrıntılı analiz için aşağıdaki araçları kullanın:

  • Sorgu Mağazası

    Hangi sorguların en fazla CPU kaynağı tükettiğini bulmak için SSMS'de En Fazla Tüketilen Kaynak raporlarını, Sorgu Deposu katalog görünümlerini veya Azure portalda Sorgu Performansı İçgörüleri'ni kullanabilirsiniz.

  • sys.dm_exec_requests

    Etkin sorguların durumunun anlık görüntüsünü almak için Azure SQL’de bu DVM’yi kullanın. Yeterli CPU kapasiteniz olup olmadığını görmek için durumu RUNNABLE ve bekleme türü olan SOS_SCHEDULER_YIELD sorguları arayın.

  • sys.dm_exec_query_stats

    Bu DMV, en çok kaynak tüketen sorguları bulmak için Sorgu Deposuna çok benzer şekilde kullanılabilir. Yalnızca önbelleğe alınmış sorgu planları için kullanılabilirken, Sorgu Deposu kalıcı bir geçmiş performans kaydı sağlar. Bu DMV, önbelleğe alınmış bir sorgunun sorgu planını bulmanıza da olanak tanır.

  • sys.dm_exec_procedure_stats

    Bu DMV, sys.dm_exec_query_stats DMV’sine çok benzer bilgiler sağlar. Tek farkı, performans bilgilerinin saklı yordam düzeyinde görüntülenebilmesidir.

    Hangi sorgu veya sorguların en fazla kaynak tükettiğini belirledikten sonra, iş yükünüz için yeterli CPU kaynağına sahip olup olmadığınızı incelemeniz gerekebilir. Basit sorgu profili oluşturma, SET deyimleri, Sorgu Deposu veya genişletilmiş olay izlemesi gibi araçlarla sorgu planlarının hatasını ayıklayabilirsiniz.

Bekliyor

Sorununuzun sebebi yüksek CPU kaynak kullanımı değilse, bir kaynağı beklemekten kaynaklanan bir performans sorunu olabilir. Kaynakları beklemeyi içeren senaryolar şunlardır:

  • G/Ç bekleme süreleri
  • Kilit bekleme süreleri
  • Mandal bekleme süreleri
  • Arabellek havuzu sınırları
  • Bellek atamaları
  • Plan önbelleği çıkarma

Bekleme senaryoları üzerinde analiz gerçekleştirmek için genellikle aşağıdaki araçlara bakarsınız:

  • sys.dm_os_wait_stats

    Veritabanı veya örnekte ilk sıradaki bekleme türlerini görmek için bu DMV’yi kullanın. Bu DMV, ilk sıradaki bekleme türlerine bağlı olarak sonraki eylemin ne olacağını saptarken size yol gösterebilir.

  • sys.dm_exec_requests

    Etkin sorguların hangi kaynağı beklediklerini görmesi için belirli bekleme türlerini bulmak için bu DMV'yi kullanın. Bu, diğer kullanıcıların kilitlerini beklemeye içerek standart bir engelleme senaryosu olabilir.

  • sys.dm_os_waiting_tasks

    Bu DMV'yi, şu anda yürütülen belirli bir sorgu için belirli bir görevin bekleme türlerini bulmak için kullanabilirsiniz. Bunun neden normalden uzun sürdüğünü görebilirsiniz. sys.dm_os_waiting_tasks zaman içinde toplanan sys.dm_os_wait_stats canlı bekleme istatistiklerini içerir.

  • Sorgu Mağazası

    Sorgu Deposu, sorgu planı yürütme işleminde ilk sıradaki beklemelerinin toplamını gösteren raporlar ve katalog görünümleri sağlar. CPU bekleme süresinin, çalışmakta olan bir soruna eşdeğer olduğunu bilmeniz önemlidir.

Azure SQL’e özgü senaryolar

Hem çalışan hem de bekleyen, Azure SQL’e özgü bazı performans senaryoları vardır. Günlük idaresi, çalışan sınırları, İş Açısından Kritik hizmet katmanları için karşılaşılan bekleme süreleri ve Hiper Ölçek dağıtımına özgü bekleme süreleri bunlardan bazılarıdır.

Günlük idaresi

Azure SQL, işlem günlüğü kullanımında kaynak sınırlarını zorunlu tutmak için günlük hızı idaresini kullanabilir. Kaynak sınırlarını güvence altına almak ve taahhüt edilen SLA’yı sağlamak için bu zorlama gerekebilir. Günlük idaresi, aşağıdaki bekleme türlerinden görünebilir:

  • LOG_RATE_GOVERNOR: Azure SQL Veritabanı bekler
  • POOL_LOG_RATE_GOVERNOR: Elastik Havuzları bekler
  • INSTANCE_LOG_GOVERNOR: Azure SQL Yönetilen Örneği bekler
  • HADR_THROTTLE_LOG_RATE*: İş Açısından Kritik ve coğrafi çoğaltma gecikme süresini bekler

Çalışan sınırları

SQL Server çalışan iş parçacığı havuzunu kullanır ama çalışanların sayısıyla ilgili üst sınırları vardır. Çok sayıda eşzamanlı kullanıcıya sahip uygulamalar, Azure SQL Veritabanı ve SQL Yönetilen Örneği için zorunlu kılınan çalışan sınırlarına yaklaşabilir:

  • Azure SQL Veritabanı'nın hizmet katmanına ve boyuta bağlı sınırları vardır. Bu sınırı aşarsanız yeni sorgu hata alır.
  • Şu anda SQL Yönetilen Örneği kullanırmax worker threads, bu nedenle bu sınırı aşan çalışanlar beklemeleri görebilirTHREADPOOL.

İş Açısından Kritik HADR beklemeleri

İş Açısından Kritik hizmet katmanını kullanıyorsanız beklenmedik bir şekilde aşağıdaki bekleme türlerini görebilirsiniz:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Bu bekleme süreleri, uygulamanızı yavaşlatmasa da, bunları görmeyi beklemeyebilirsiniz. Bunlar normalde Her Zaman Açık kullanılabilirlik grubu kullanımına özgüdür. İş Açısından Kritik katmanlar, bir İş Açısından Kritik hizmet katmanının SLA ve kullanılabilirlik özelliklerini uygulamak için kullanılabilirlik grubu teknolojisini kullanır. Bu nedenle bu bekleme türleri beklenir. Uzun bekleme süreleri, G/Ç gecikmesi veya çoğaltma gecikmesi gibi bir darboğazı işaret edebilir.

Hiperskala

Hiperölçek mimarisi, RBIO (kayıt yönetiminin olası bir göstergesi) ön ekli bazı kendine özgü bekleme türlerine neden olabilir. Buna ek olarak, DMV'ler, katalog görünümleri ve genişletilmiş olaylar, sayfa sunucusu okumalarının ölçümlerini gösterecek şekilde geliştirilmiştir.

Sonraki alıştırmada, bu ünitede edindiğiniz araçları ve bilgileri kullanarak Azure SQL için performans sorununu izlemeyi ve çözmeyi öğreneceksiniz.