Aracılığıyla paylaş

SQL Hiper Ölçek performans sorunlarını giderme tanılaması

Şunlar için geçerlidir:Azure SQL Veritabanı

Hiper Ölçek veritabanındaki performans sorunlarını gidermek için genel SQL performans ayarlama yöntemleri tüm performans araştırmalarının başlangıç noktasıdır. Ancak, Hiper Ölçek'in dağıtılmış mimarisi göz önünde bulundurulduğunda ek tanılama verilerinin dikkate alınması gerekebilir. Bu makalede Hiper Ölçek'e özgü tanılama verileri açıklanmaktadır.

Azaltılmış kayıt oranı beklemeleri

Azure SQL Veritabanı'ndaki her veritabanı ve elastik havuz, günlük hız yönetimiile günlük oluşturma hızını yönetir. Günlük hızı sınırı, primary_max_log_rate sütununda görüntülenir.

Bazen, kurtarılabilirlik hizmet düzeyi sözleşmelerinin (SLA'ların) korunması için birincil hesaplama replikasındaki günlük oluşturma oranı azaltılmalıdır. Örneğin, günlük hizmetinden yeni günlük kayıtlarının işlenmesinde önemli ölçüde geri kalan bir sayfa sunucusu veya başka bir işlem çoğaltması olduğunda bu durum gerçekleşebilir. Arka planda hiper ölçek bileşenleri yoksa, günlük hız düzenleme mekanizması, premium serisi ve bellek için iyileştirilmiş donanım için, veritabanı başına 150 MiB/sn günlük oluşturma hızına ulaşılmasını sağlar. Standart seri donanımlar için veritabanı başına günlük hızı üst sınırı 100 MiB/sn'dir. Elastik havuzlar için maksimum günlük hızı, premium serisi ve premium serisi bellek için iyileştirilmiş donanım için havuz başına 150 MiB/sn, diğer donanımlar için ise havuz başına 125 MiB/sn'dir.

Log hızı azaldığında, sys.dm_os_wait_stats içerisinde aşağıdaki bekleme türleri görünür:

Bekleme türü Sebep
RBIO_RG_STORAGE Sayfa sunucusu tarafından gecikmiş kayıt tüketimi
RBIO_RG_DESTAGE Uzun vadeli günlük depolama tarafından gecikmiş günlük tüketimi
RBIO_RG_REPLICA HA ikincil çoğaltması veya adlandırılmış çoğaltma tarafından gecikmeli günlük tüketimi
RBIO_RG_GEOREPLICA Coğrafi ikincil replika tarafından gecikmeli günlük tüketimi
RBIO_RG_DESTAGE Günlük hizmeti tarafından günlük tüketiminin gecikmesi
RBIO_RG_LOCALDESTAGE Günlük hizmeti tarafından günlük tüketiminin gecikmesi
RBIO_RG_STORAGE_CHECKPOINT Yavaş veritabanı denetim noktası nedeniyle bir sayfa sunucusunda günlük tüketimi gecikti.
RBIO_RG_MIGRATION_TARGET Ters geçiş sırasında Hiperölçek olmayan veritabanı tarafından günlük tüketiminin gecikmesi

sys.dm_hs_database_log_rate() dinamik yönetim işlevi (DMF), eğer varsa, günlük hızı azaltmayı anlamanıza yardımcı olmak için daha fazla ayrıntı sağlar. Örneğin, hangi belirli ikincil çoğaltmanın günlük kayıtlarının uygulanmasında geride kaldığını ve henüz uygulanmamış işlem günlüğünün toplam boyutunu size söyleyebilir.

Sayfa sunucusu okur

İşlem çoğaltmaları veritabanının tam bir kopyasını yerel olarak önbelleğe almaz. Hesaplama kopyasının yerel verileri, arabellek havuzunda (bellekte) ve en sık erişilen veri sayfalarının bir kısmını içeren yerel dayanıklı arabellek havuzu uzantısı (RBPEX) önbelleğinde depolanır. Bu yerel SSD önbelleği işlem boyutuyla orantılı olarak boyutlandırılır. Öte yandan her sayfa sunucusu, veritabanının koruduğu bölümü için eksiksiz bir SSD önbelleğine sahiptir.

İşlem çoğaltmasında okuma GÇ'leri verildiğinde, veriler arabellek havuzunda veya yerel SSD önbelleğinde yoksa, istenen Günlük Sırası Numarası (LSN) sayfa ilgili sayfa sunucusundan getirilir. Sayfa sunucularından okuma işlemleri uzaktır ve yerel SSD önbelleğindeki okumalardan daha yavaştır. G/Ç ile ilgili performans sorunlarını giderirken, görece daha yavaş olan sayfa sunucusu okumaları üzerinden ne kadar G/Ç işlemi yapıldığını anlamamız gerekir.

Çeşitli dinamik yönetilen görünümler (DMV' ler) ve genişletilmiş olaylar, sayfa sunucusundan gelen ve toplam okuma sayısıyla karşılaştırılabilir uzaktan okuma sayısını belirten sütunlara ve alanlara sahiptir. Sorgu Deposu, sorgu çalışma zamanı istatistiklerinde sayfa sunucusu okumalarını da yakalar.

  • Rapor sayfası sunucusu okuma sütunları yürütme DMV'lerinde ve katalog görünümlerinde kullanılabilir:

  • Sayfa sunucusu okuma alanları aşağıdaki genişletilmiş olaylarda bulunur:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info

  • ActualPageServerReads / ActualPageServerReadAheads öznitelikleri, çalışma zamanı istatistikleri içeren planlar için sorgu planı XML'sinde bulunur. Örneğin:

    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Bahşiş

    Bu öznitelikleri sorgu planı özellikleri penceresinde görüntülemek için SSMS 18.3 veya üzeri gereklidir.

Sanal dosya istatistikleri ve GÇ hesaplaması

Azure SQL Veritabanı'nda sys.dm_io_virtual_file_stats() DMF, IOPS, aktarım hızı ve gecikme süresi gibi veritabanı G/Ç istatistiklerini izlemenin bir yoludur. Hiper Ölçek'teki G/Ç özellikleri,dağıtılmış mimarisi nedeniyle farklıdır. Bu bölümde, bu DMF'de görüldüğü gibi okuma ve yazma G/Ç işlemlerine odaklanacağız.

Hiperölçek için sys.dm_io_virtual_file_stats() konusundaki ilgili veriler aşağıdaki gibidir:

  • Değerin database_idDB_ID işlevi tarafından döndürülen değerle eşleştiği ve değerin file_id 2'den farklı olduğu satırlar sayfa sunucularına karşılık gelir. Genellikle her satır bir sayfa sunucusuna karşılık gelir. Ancak, daha büyük dosyalar için birden çok sayfa sunucusu kullanılır.

    • 2 içeren file_id satır işlem günlüğüne karşılık gelir.

  • database_id sütunundaki değerin 0 olduğu satırlar, bilgisayar kopyasında yerel SSD önbelleğine karşılık gelir.

Yerel SSD önbellek kullanımı

Yerel SSD önbelleği, veritabanı motorunun sorguları işlediği aynı hesaplama çoğaltması üzerinde bulunduğundan, bu önbelleğe karşı G/Ç, sayfa sunucularına karşı G/Ç'den daha hızlıdır. Hiper Ölçek veritabanında veya elastik havuzda, sys.dm_io_virtual_file_stats() yerel SSD önbelleğinin G/Ç istatistiklerini bildiren özel satırlar vardır. database_id sütunu için bu satırlar 0 değerine sahiptir. Örneğin, aşağıdaki sorgu veritabanı başlangıcından bu yana yerel SSD önbelleği G/Ç istatistiklerini döndürür.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Yerel SSD önbellek dosyalarından toplanan okumaların diğer tüm veri dosyalarından toplanan okumalara oranı, yerel SSD önbellek isabet oranıdır. Bu ölçüm, RBPEX cache hit ratio DMV'de bulunan RBPEX cache hit ratio base ve performans sayaçları tarafından sağlanır.

Veri okumaları

  • Okuma işlemleri veritabanı altyapısı tarafından bir hesaplama replikasında verildiğinde, bunlar yerel SSD önbelleği, sayfa sunucuları veya birden fazla sayfa okunuyorsa her ikisinin kombinasyonu tarafından sağlanabilir.

  • İşlem çoğaltması, belirli bir veri dosyasından (örneğin, file_id 1 içeren dosya) bazı sayfaları okuduğunda, eğer bu veriler sadece yerel SSD önbelleğinde bulunuyorsa, bu okuma için tüm GÇ, database_id 0 olan yerel SSD önbellek dosyalarına karşı hesaplanır. Bu verilerin bir bölümü yerel SSD önbelleğinde, bir kısmı da sayfa sunucularındaysa, GÇ kısmen yerel SSD önbellek dosyalarına, kısmen de sayfa sunucularına karşılık gelen veri dosyalarına hesaba eklenir.

  • Hesaplama replikası bir sayfa sunucusundan belirli bir LSN'de bir sayfa istediğinde, sayfa sunucusu istenen LSN'ye henüz yetişmediyse, hesaplama replikasındaki okuma, sayfa geri döndürülmeden önce, sayfa sunucusu yetişene kadar bekler. Hesaplama replikasındaki bir sayfa sunucusundan yapılan herhangi bir okuma için, bu GÇ'yi bekliyorsa bir PAGEIOLATCH_* bekleme türü görürsünüz. Hiper Ölçek'te, bu bekleme süresi hem sayfa sunucusundaki istenen sayfayı gereken LSN'ye yakalama süresini hem de sayfa sunucusundan işlem çoğaltmasına aktarmak için gereken süreyi içerir.

  • Okuma gibi büyük okuma işlemleri genellikledağılım toplama okumaları kullanılarak yapılır. Bu, tek bir okuma işlemi olarak 4 MB'a kadar veriyi okumaya olanak tanır. Ancak, okunan veriler yerel SSD önbelleğinde olduğunda, arabellek havuzu ve yerel SSD önbelleği her zaman 8 KB sayfa kullandığından, bu okumalar tek tek 8 KB'lık birden çok okuma olarak hesaba katılır. Sonuç olarak, yerel SSD önbelleğine karşı görülen okuma G/Ç'lerinin sayısı, motor tarafından gerçekleştirilen gerçek G/Ç sayısından daha fazla olabilir.

Veri yazma işlemleri

  • Ana hesaplama replikası doğrudan sayfa sunucularına yazmaz. Bunun yerine, günlük hizmeti sunucusundan alınan günlük kayıtları ilgili sayfa sunucularında yeniden oynatılır.

  • İşlem çoğaltması üzerindeki yazma işlemleri, çoğunlukla yerel SSD önbelleğine (database_id 0) yapılır. 8 KB'tan büyük veri yazımları için, yani toplama-yazmakullanılarak yapılan yazımlar, arabellek havuzu ve yerel SSD önbelleği her zaman 8 KB sayfa kullandığından, her yazma işlemi yerel SSD önbelleğinde 8 KB'lık pek çok ayrı yazma işlemine dönüştürülür. Sonuç olarak, yerel SSD önbelleğinde görülen yazma G/Ç işlemlerinin sayısı, motor tarafından gerçekleştirilen gerçek G/Ç sayısından daha fazla olabilir.

  • Sayfa sunucularına karşılık gelen database_id 0 dışındaki veri dosyaları da yazma işlemleri gösterebilir. Hyperscale'de, işlem çoğaltmaları hiçbir zaman doğrudan sayfa sunucularına yazmadığı için bu yazma işlemleri simüle edilir. G/Ç istatistikleri, hesaplama replikası üzerinde gerçekleştiğinde hesaba katılır. database_id dışındaki veri dosyaları için hesaplama replikasında görülen IOPS, aktarım hızı ve gecikme süresi, sayfa sunucularındaki yazmaların gerçek G/Ç istatistiklerini yansıtmaz.

Günlük yazma işlemleri

  • Birincil işlem çoğaltmasında günlük yazımları sys.dm_io_virtual_file_stats() altında file_id 2'de dikkate alınır.

  • Kullanılabilirlik gruplarından farklı olarak, bir işlem birincil işlem çoğaltmasında işlendiğinde, günlük kayıtları ikincil çoğaltmada sağlamlaştırılmaz. Hyperscale'de günlük, günlük hizmetinde kaydedilir ve ikincil replikalara eşzamanlı olmayan bir şekilde uygulanır. Günlük yazma işlemleri aslında ikincil çoğaltmalarda gerçekleşmediğinden, ikincil çoğaltmalardaki sys.dm_io_virtual_file_stats() günlük G/Ç'lerin kaydı işlem günlüğü G/Ç istatistikleri şeklinde kullanılmamalıdır.

Kaynak kullanımı istatistiklerinde veri GÇ

Hiper Ölçek olmayan bir veritabanında, kaynak idaresi veri GÇ sınırına göre veri dosyalarına karşı birleştirilmiş okuma ve yazma IOPS, sütunda sys.dm_db_resource_stats ve sys.resource_stats görünümlerinde avg_data_io_percent bildirilir. Elastik havuzlar için karşılık gelen DMV'ler sys.dm_elastic_pool_resource_stats ve sys.elastic_pool_resource_stats. Azure İzleyici ölçümleri olan Veri IO Yüzdesi ile aynı değerler, veritabanları ve elastik havuzlar için bildirilir.

Hiperscale veritabanında, bu sütunlar ve ölçümler yalnızca işlem çoğaltmasındaki yerel SSD depolama sınırına göre veri GÇ kullanımını rapor eder ve bu sınır yerel SSD önbelleği ve tempdb veritabanına yönelik G/Ç'yi içerir. Bu sütundaki %100 değeri, kaynak idarenin yerel depolama IOPS'sini sınırladığını gösterir. Bu bir performans sorunuyla ilişkiliyse, iş yükünü daha az GÇ oluşturacak şekilde ayarlayın veya kaynak idaresini Maksimum Veri IOPSsınırıartırmak için işlem boyutunu artırın. Yerel SSD önbelleği okuma ve yazma işlemleri için sistem, veritabanı motoru tarafından verilebilen daha büyük G/Ç'ler yerine tek tek 8 KB'lık IO'ları sayar.

Sayfa sunucularına yönelik veri GÇ'leri, kaynak kullanımı görünümlerinde veya Azure Monitor ölçümleri aracılığıyla raporlanmaz, ancak daha önce açıklandığı gibi sys.dm_io_virtual_file_stats() içinde raporlanır.

İlgili içerik

  • Last updated on