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, Azure SQL Veritabanı işlem düğümündeki genel performans ayarlama yöntemleri bir performans araştırması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.
Günlük hızı azaltma beklemeleri
Her Azure SQL Veritabanı hizmet hedefi, günlük hızı idaresi aracılığıyla zorunlu kılınan günlük oluşturma hızı sınırlarına sahiptir. Hiper Ölçek'te, hizmet düzeyinden bağımsız olarak günlük idare sınırı 105 MB/sn olarak ayarlanır. Bu değer sys.dm_user_db_resource_governance sütununda gösterilirprimary_max_log_rate
.
Ancak, kurtarılabilirlik SLA'larını korumak için birincil işlem çoğaltması üzerindeki günlük oluşturma hızının kısıtlanması gereken zamanlar vardır. Bu azaltma, bir sayfa sunucusu veya başka bir işlem çoğaltması günlük hizmetinden yeni günlük kayıtlarının uygulanmasının önemli ölçüde gerisinde olduğunda gerçekleşir. Geride hiçbir sayfa sunucusu veya çoğaltma yoksa, azaltma mekanizması günlük oluşturma hızının 100 MB/sn'ye ulaşmasını sağlar. Bu, tüm Hiper Ölçek hizmeti hedeflerinde etkin en yüksek günlük oluşturma hızıdır. 150 MB/sn günlük oluşturma hızı, bir kabul önizleme özelliği olarak kullanılabilir. Daha fazla bilgi edinmek ve 150 MB/sn'yi kabul etmek için bkz . Blog: Kasım 2024 Hiper Ölçek geliştirmeleri.
Aşağıdaki bekleme türleri ( sys.dm_os_wait_stats) günlük hızının birincil işlem çoğaltmasında kısıtlanmasının nedenlerini açıklar:
Bekleme Türü | Açıklama |
---|---|
RBIO_RG_STORAGE | Hiper Ölçek veritabanı birincil işlem düğümü günlük oluşturma hızı, bir veya daha fazla sayfa sunucusu tarafından günlük tüketiminin gecikmesi nedeniyle kısıtlandığında oluşur. |
RBIO_RG_DESTAGE | Hiper Ölçek veritabanı işlem düğümü günlük oluşturma hızı, uzun süreli günlük depolama alanı tarafından günlük tüketiminin gecikmesi nedeniyle kısıtlandığında gerçekleşir. |
RBIO_RG_REPLICA | Hiper Ölçek veritabanı işlem düğümü günlük oluşturma hızı, bir veya daha fazla okunabilir ikincil çoğaltma tarafından gecikmeli günlük tüketimi nedeniyle kısıtlandığında gerçekleşir. |
RBIO_RG_GEOREPLICA | Hiper Ölçek veritabanı işlem düğümü günlük oluşturma hızı Coğrafi ikincil çoğaltma tarafından gecikmeli günlük tüketimi nedeniyle kısıtlandığında gerçekleşir. |
RBIO_RG_LOCALDESTAGE | Hiper Ölçek veritabanı işlem düğümü günlük oluşturma hızı, günlük hizmeti tarafından gecikmeli günlük tüketimi nedeniyle kısıtlandığında gerçekleşir. |
Sayfa sunucusu okur
İşlem çoğaltmaları veritabanının tam kopyasını yerel olarak önbelleğe almaz. İşlem çoğaltmasının yerel verileri arabellek havuzunda (bellekte) ve veri sayfalarının kısmi (kapsamayan) önbelleği olan yerel dayanıklı arabellek havuzu uzantısı (RBPEX) önbelleğinde depolanır. Bu yerel RBPEX önbelleği işlem boyutuyla orantılı olarak boyutlandırılır ve işlem katmanının belleğinin üç katıdır. RBPEX, en sık erişilen verilere sahip olduğu arabellek havuzuna benzer. Öte yandan her sayfa sunucusu, veritabanının koruduğu bölümü için kapsayan bir RBPEX önbelleğine sahiptir.
İşlem çoğaltmasında okuma yapıldığında, veriler arabellek havuzunda veya yerel RBPEX önbelleğinde yoksa, bir getPage(pageId, LSN) işlev çağrısı verilir ve sayfa ilgili sayfa sunucusundan getirilir. Sayfa sunucularından okumalar uzaktan okumadır ve bu nedenle yerel RBPEX'ten okumalardan daha yavaştır. GÇ ile ilgili performans sorunlarını giderirken, göreli olarak daha yavaş uzak sayfa sunucusu okumaları aracılığıyla kaç GÇ 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ı istatistiklerinin bir parçası olarak uzak okumaları da yakalar.
Rapor sayfası sunucusu okumalarına yönelik sütunlar yürütme DMV'lerinde ve katalog görünümlerinde kullanılabilir; örneğin:
Sayfa sunucusu okumaları aşağıdaki genişletilmiş olaylara eklenir:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query-store_execution_runtime_info
Gerçek planlar için sorgu planı XML'sine ActualPageServerReads/ActualPageServerReadAheads eklenir. Örneğin:
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />
Not
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ı'da sys.dm_io_virtual_file_stats() DMF, SQL Veritabanı GÇ'yi izlemenin birincil yoludur. Hiper Ölçek'teki GÇ özellikleri, dağıtılmış mimarisinden dolayı farklıdır. Bu bölümde, bu DMF'de görüldüğü gibi veri dosyalarına GÇ (okuma ve yazma) odaklanacağız. Hiper Ölçek'te, bu DMF'de görünen her veri dosyası bir uzak sayfa sunucusuna karşılık gelir. Burada bahsedilen RBPEX önbelleği, işlem çoğaltması üzerinde kapsamayan bir önbellek olan yerel SSD tabanlı bir önbellektir.
Yerel RBPEX önbellek kullanımı
Yerel RBPEX önbelleği, işlem çoğaltması üzerinde, yerel SSD depolamada bulunur. Bu nedenle, bu önbelleğe karşı GÇ, uzak sayfa sunucularında GÇ'den daha hızlıdır. Şu anda, hiper ölçek veritabanındaki sys.dm_io_virtual_file_stats() işlem çoğaltmasında yerel RBPEX önbelleğine karşı GÇ'yi bildiren özel bir satıra sahiptir. Bu satır hem hem de database_id
file_id
sütunlar için 0 değerine sahiptir. Örneğin, aşağıdaki sorgu veritabanı başlangıcından bu yana RBPEX kullanım istatistiklerini döndürür.
select * from sys.dm_io_virtual_file_stats(0,NULL);
RBPEX üzerinde yapılan okumaların diğer tüm veri dosyalarında yapılan toplu okumalara oranı, RBPEX önbellek isabet oranı sağlar. Sayaç RBPEX cache hit ratio
, DMV sys.dm_os_performance_counters
performans sayaçlarında da kullanıma sunulur.
Veri okumaları
- Okumalar sql server veritabanı altyapısı tarafından bir işlem çoğaltması üzerinde verildiğinde, bunlar yerel RBPEX önbelleği veya uzak sayfa sunucuları tarafından ya da birden çok sayfa okuyorsa ikisinin bir bileşimi tarafından sunulabilir.
- İşlem çoğaltması belirli bir dosyadan bazı sayfaları okuduğunda (örneğin file_id 1), bu veriler yalnızca yerel RBPEX önbelleğinde yer alıyorsa, bu okuma için tüm GÇ file_id 0 (RBPEX) için hesaba eklenir. Bu verilerin bir bölümü yerel RBPEX önbelleğindeyse ve bir kısmı uzak sayfa sunucusundaysa GÇ, RBPEX'ten sunulan parça için file_id 0'a, uzak sayfa sunucusundan sunulan bölüm ise file_id 1'e doğru hesaba eklenir.
- İşlem çoğaltması bir sayfa sunucusundan belirli bir LSN'de sayfa istediğinde, sayfa sunucusu istenen LSN'ye yetişmezse, işlem çoğaltması üzerindeki okuma, sayfa işlem çoğaltmasına döndürülmeden önce sayfa sunucusuna ulaşana kadar bekler. İşlem çoğaltması üzerindeki bir sayfa sunucusundan yapılan herhangi bir okuma için, bu GÇ'yi bekliyorsa PAGEIOLATCH_* bekleme türünü 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 okumalar genellikle "Dağılım-Toplama" Okumaları kullanılarak yapılır. Bu, SQL Server veritabanı altyapısında tek bir okuma olarak kabul edilen tek seferde en fazla 4 MB sayfa okumasına olanak tanır. Ancak, okunan veriler RBPEX'de olduğunda, arabellek havuzu ve RBPEX 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, RBPEX'de görülen okuma GÇ'lerinin sayısı, altyapı tarafından gerçekleştirilen gerçek GÇ sayısından daha fazla olabilir.
Veri yazma işlemleri
- Birincil işlem çoğaltması doğrudan sayfa sunucularına yazmaz. Bunun yerine, günlük hizmetinden günlük kayıtları ilgili sayfa sunucularında yeniden oynatılır.
- İşlem çoğaltması üzerinde gerçekleşen yazma işlemleri genellikle yerel RBPEX'e (file_id 0) yazılır. Arabellek havuzu ve RBPEX her zaman 8 KB'lık sayfalar kullandığından, 8 KB'tan büyük mantıksal dosyalardaki yazma işlemleri için, başka bir deyişle Toplama-yazma kullanılarak yapılan yazma işlemleri RBPEX'e 8 KB'lık tek tek birden çok yazma işlemine çevrilir. Sonuç olarak, RBPEX'e karşı görülen yazma GÇ'lerinin sayısı, altyapı tarafından gerçekleştirilen gerçek GÇ sayısından daha büyük olabilir.
- RBPEX olmayan dosyalar veya sayfa sunucularına karşılık gelen file_id 0 dışındaki veri dosyaları da yazmaları gösterir. İşlem çoğaltmaları hiçbir zaman doğrudan sayfa sunucularına yazmadığından Hiper Ölçek hizmet katmanında bu yazma işlemleri simülasyonu yapılır. Yazma IOPS'si ve aktarım hızı, işlem çoğaltması üzerinde gerçekleşirken hesaba katılır, ancak file_id 0 dışındaki veri dosyaları için gecikme süresi sayfa sunucusu yazmalarının gerçek gecikme süresini yansıtmaz.
Günlük yazma işlemleri
- Birincil işlemde günlük yazma, sys.dm_io_virtual_file_stats file_id 2'de hesaba eklenir. Birincil işlemde günlük yazma, günlük Giriş Bölgesi'ne yazma işlemidir.
- Günlük kayıtları, bir işlemedeki ikincil çoğaltmada sağlamlaştırılmaz. Hiper Ölçek'te günlük, günlük hizmeti tarafından ikincil çoğaltmalara zaman uyumsuz olarak uygulanır. Günlük yazma işlemleri aslında ikincil çoğaltmalarda gerçekleşmediğinden, ikincil çoğaltmalardaki günlük GÇ'lerinin hesaplanmaları yalnızca izleme amaçlıdır.
Kaynak kullanımı istatistiklerinde veri GÇ
Hiper Ölçek olmayan bir veritabanında, kaynak idaresi veri IOPS sınırına göre veri dosyalarına karşı birleştirilmiş okuma ve yazma IOPS'leri sütunda sys.dm_db_resource_stats ve sys.resource_stats görünümlerinde avg_data_io_percent
bildirilir. Azure portalında Veri GÇ Yüzdesi ile aynı değer bildirilir.
Hiper Ölçek veritabanında, bu sütun yalnızca işlem çoğaltması üzerindeki yerel depolama sınırına göre veri IOPS kullanımını bildirir; özellikle RBPEX ve tempdb
ile GÇ. 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 idaresi Maksimum Veri IOPS sınırını artırmak için veritabanı hizmeti hedefini artırın. RBPEX okuma ve yazma işlemleri için sistem, SQL Server veritabanı altyapısı tarafından verilebilen daha büyük GÇ'ler yerine tek tek 8 KB GÇ'leri sayar.
Uzak sayfa sunucularına yönelik veri GÇ'leri kaynak kullanımı görünümlerinde veya portalda raporlanmaz, ancak daha önce belirtildiği gibi sys.dm_io_virtual_file_stats() DMF'de bildirilir.
Ek kaynaklar
- Hiper Ölçek tek veritabanı için sanal çekirdek kaynak sınırları için bkz. Hiper Ölçek hizmet katmanı sanal çekirdek Sınırları
- İzleme Azure SQL Veritabanı için veritabanı izleyicisini etkinleştirin
- Azure SQL Veritabanı performans ayarlaması için bkz. Azure SQL Veritabanı'de sorgu performansı
- Sorgu Deposu kullanarak performans ayarlaması için bkz . Sorgu deposu kullanarak performans izleme
- DMV izleme betikleri için bkz. Dinamik yönetim görünümlerini kullanarak performans Azure SQL Veritabanı izleme