Alıştırma - İş yükünüzün performansını ölçeklendirme

  • 10 dakika

Bu alıştırmada, ilk alıştırmada karşılaştığınız sorunu ele alacak ve Azure SQL Veritabanı için daha fazla CPU'yu ölçeklendirerek performansı geliştireceksiniz. Önceki alıştırmada dağıtılan veritabanını kullanacaksınız.

Bu alıştırmanın tüm betiklerini kopyaladığınız GitHub deposundaki 04-Performance\monitor_and_scale klasöründe veya indirdiğiniz zip dosyasında bulabilirsiniz.

Azure SQL performansının ölçeğini artırma

CPU kapasitesi sorunu gibi görünen bir sorunda performansı ölçeklendirmek için seçeneklerinizin neler olduğuna karar vermeli ve Azure SQL için sağlanan arabirimleri kullanarak CPU’ları ölçeklendirmelisiniz.

  1. Performansın nasıl ölçeklendirileceğine karar verin. İş yükü CPU'ya bağlı olduğundan performansı artırmanın bir yolu CPU kapasitesini veya hızını artırmaktır. SQL Server kullanıcısının daha fazla CPU kapasitesi elde etmek için farklı bir makineye geçmesi veya sanal makineyi yeniden yapılandırması gerekebilir. Bazı durumlarda, SQL Server yöneticisinin bile bu ölçeklendirme değişikliklerini yapma izni olmayabilir. İşlem zaman alabilir ve hatta veritabanı geçişi gerektirebilir.

    Azure için, kullanıcı tarafında veritabanı geçişi olmadan CPU kapasitesini artırmak için Azure CLI veya Azure portalını kullanabilirsiniz ALTER DATABASE.

  2. Azure portalı kullanarak daha fazla CPU kaynağı elde etmek için ölçeklendirme yapmanızı sağlayacak seçenekleri görebilirsiniz. Veritabanınızın Genel Bakış bölmesinden geçerli dağıtım için Fiyatlandırma katmanını seçin. Fiyatlandırma katmanı, hizmet katmanını ve sanal çekirdek sayısını değiştirmenize olanak tanır.

    Screenshot of changing service tier in the Azure portal.

  3. Burada işlem kaynaklarını değiştirme veya ölçeklendirme seçeneklerini görebilirsiniz. Genel Amaçlı hizmet katmanı için 8 sanal çekirdeğe kadar kolayca ölçeği artırabilirsiniz.

    Screenshot of compute options in the Azure portal.

    İş yükünüzü ölçeklendirmek için farklı bir yöntem de kullanabilirsiniz.

  4. Bu alıştırmada, raporlardaki farkları düzgün bir şekilde görebilmeniz için önce Sorgu Deposunu boşaltmalısınız. SQL Server Management Studio'da (SSMS), AdventureWorks veritabanını seçin ve Dosya>Aç Dosyasını Aç>menüsünü kullanın. SSMS'de Flushhquerystore.sql betiğini AdventureWorks veritabanı bağlamında açın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

    EXEC sp_query_store_flush_db;

    Bu T-SQL toplu işlemini çalıştırmak için Yürüt'e tıklayın.

    Dekont

    Önceki sorgunun çalıştırılması, Sorgu Deposu verilerinin bellek içi bölümünü diske boşaltır.

  5. SSMS'de get_service_objective.sql betiğini açın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

    SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO

    Bu, T-SQL kullanarak hizmet katmanınızı bulma yöntemidir. Fiyatlandırma veya hizmet katmanı, hizmet hedefi olarak da bilinir. T-SQL toplu işlemlerini çalıştırmak için Yürüt'e tıklayın.

    Geçerli Azure SQL Veritabanı dağıtımı için sonuçlarınız aşağıdaki resme benzer olmalıdır:

    Screenshot of service objective results.

    Hizmet hedefi için slo_name teriminin de kullanıldığına dikkat edin. SLO, hizmet düzeyi hedefi anlamına gelir.

    Çeşitli slo_name değerler belgelenmez, ancak dize değerinden bu veritabanının iki sanal çekirdek içeren genel amaçlı bir hizmet katmanı kullandığını görebilirsiniz:

    Dekont

    SQLDB_OP_... dizesi, İş Açısından Kritik için kullanılır.

    ALTER DATABASE belgelerini görüntülediğinizde, doğru söz dizimi seçeneklerini elde etmek için hedef SQL Server dağıtımınızı seçebileceğinize dikkat edin. SQL Veritabanı tek veritabanı/elastik havuz seçeneğini belirleyerek Azure SQL Veritabanı için seçenekleri görüntüleyin. Portalda bulduğunuz işlem ölçeğini eşleştirmek için hizmet hedefine 'GP_Gen5_8'ihtiyacınız vardır.

  6. Veritabanı için hizmet hedefini daha fazla CPU ölçeklendirecek şekilde değiştirin. SSMS'de modify_service_objective.sql betiğini açın ve T-SQL toplu işlemini çalıştırın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

    ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');

    Bu deyim hemen geri döner, ancak işlem kaynaklarını ölçeklendirme işlemi arka planda gerçekleştirilir. Bu kadar küçük bir ölçeğin bir dakikadan kısa sürmesi beklenir ve değişikliğin geçerlilik kazanması için veritabanı kısa bir süre çevrimdışı kalır. Azure portalı kullanarak bu ölçeklendirme etkinliğinin ilerleme durumunu izleyebilirsiniz.

    Screenshot of update in the Azure portal.

  7. Nesne Gezgini’nde, Sistem Veritabanları klasörünün altında ana veritabanına sağ tıklayın ve Yeni Sorgu’yu seçin. SSMS sorgu düzenleyicisi penceresinde şu sorguyu çalıştırın:

    SELECT * FROM sys.dm_operation_status;

    Bu, Azure SQL Veritabanı'nda hizmet hedefine yönelik değişikliğin ilerleme durumunu izlemek için bir diğer yol sağlar. Bu dinamik yönetim görünümü (DMV), hizmet hedefinde ALTER DATABASE ile veritabanında yapılan değişikliklerin geçmişini ortaya koyar. Değişikliğin etkin ilerleme durumunu gösterir.

    Burada, yukarıdaki ALTER DATABASE deyimi yürütüldükten sonra bu DMV’nin tablo biçimindeki çıkışının bir örneği yer alır:

    Ürün Değer
    session_activity_id 97F9474C-0334-4FC5-BFD5-337CDD1F9A21
    resource_type 0
    resource_type_desc Veritabanı
    major_resource_id AdventureWorks
    minor_resource_id
    operation ALTER DATABASE
    semt 1
    state_desc IN_PROGRESS
    percent_complete 0
    error_code 0
    error_desc
    error_severity 0
    error_state 0
    start_time [tarih saat]
    last_modify_time [tarih saat]

    Hizmet hedefi değişikliği sırasında, son değişiklik uygulanana kadar veritabanında sorgulara izin verilir. Uygulama çok kısa bir süre için bağlantı kuramaz. Azure SQL Yönetilen Örneği’nde bir katman değişikliği, sorgulara ve bağlantılara olanak sağlar, ancak yeni veritabanı oluşturulması gibi tüm veritabanı işlemlerini engeller. Bu durumlarda, şu hata iletisini alırsınız: "'[sunucu]' yönetilen örneği için bir hizmet katmanı değişikliği devam ettiğinden işlem tamamlanamadı. Lütfen devam eden işlemin tamamlanmasını bekleyin ve yeniden deneyin."

  8. Bu işlem tamamlandığında, SSMS'deki get_service_objective.sql dosyasında listelenen önceki sorguları kullanarak 8 sanal çekirdekten oluşan yeni hizmet hedefinin veya hizmet katmanının geçerli olduğunu doğrulayın.

Ölçeği artırdıktan sonra iş yükünü çalıştırma

Artık veritabanının daha fazla CPU kapasitesi olduğundan, önceki alıştırmadan iş yükünü çalıştıralım ve bir performans geliştirmesi olup olmadığını gözlemleyelim.

  1. Artık ölçeklendirme tamamlandığına göre şimdi iş yükü süresinin kısalıp kısalmadığını ve CPU kaynaklarında bekleme sürelerinin kısalıp kısalmadığını kontrol edin. Önceki alıştırmada çalıştırdığınız sqlworkload.cmd komutunu kullanarak iş yükünü yeniden çalıştırın.

  2. SQL Server Management Studio’yu kullanarak dmdbresourcestats.sql betiğinden bu modülün ilk alıştırmasındaki sorgunun aynısını çalıştırın ve sonuçları gözlemleyin:

    SELECT * FROM sys.dm_db_resource_stats;

    Önceki alıştırmada neredeyse yüzde 100 olan ortalama CPU kaynağı kullanımının düştüğünü görmeniz gerekiyor. Normalde, sys.dm_db_resource_stats bir saatlik etkinliği görüntüler. Veritabanını yeniden boyutlandırmak sıfırlamaya neden olur sys.dm_db_resource_stats .

  3. SQL Server Management Studio’yu kullanarak dmexecrequests.sql betiğinden bu modülün ilk alıştırmasındaki sorguyu çalıştırın ve sonuçları gözlemleyin.

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

    Durumu RUNNING olan daha fazla sorgu olduğunu görürsünüz. Bunun anlamı çalışanlarımızı yürütmek için daha fazla CPU kapasitesi olduğudur.

  4. Yeni iş yükü süresini gözlemleyin. sqlworkload.cmd komutundan elde edilen iş yükü süresi çok daha kısa, yaklaşık 25-30 saniye olmalıdır.

Sorgu Deposu raporlarını gözlemleme

Önceki alıştırmada baktığımız Sorgu Deposu raporlarına şimdi yeniden bakalım.

  1. Bu modülde ilk alıştırmayla aynı teknikleri kullanarak SSMS'den En Çok Kaynak Tüketen Sorgular raporuna bakın:

    Screenshot of top query results running faster.

    Şimdi iki sorgu (query_id) göreceksiniz. Ölçeklendirme işlemi yeniden başlatma gerektirdiğinden ve sorgunun yeniden derlenmesi gerektiğinden, bunlar aynı sorgudur, ancak Sorgu Deposu’nda farklı query_id değerleri olarak gösterilir. Raporda toplam ve ortalama sürenin oldukça kısaldığını görebilirsiniz.

  2. Ayrıca Sorgu Bekleme İstatistikleri raporuna bakın ve CPU bekleme çubuğunu seçin. Sorgu için genel ortalama bekleme süresinin daha kısa olduğunu ve genel süre yüzdesinin daha düşük olduğunu görebilirsiniz. Bu, veritabanında sanal çekirdek sayısı daha düşük olduğunda CPU’nun o kadar büyük bir kaynak sorununa yol açmadığının iyi bir göstergesidir:

    Screenshot of top wait statistics results running faster.

  3. Tüm raporları ve sorgu düzenleyicisi pencerelerini kapatabilirsiniz. Sonraki alıştırmada ihtiyaç duyacağınız için SSMS'yi bağlı bırakın.

Azure Ölçümleri'nden gelen değişiklikleri gözlemleme

  1. Azure portalında AdventureWorks veritabanına gidin ve İşlem Kullanımı için Genel Bakış bölmesindeki İzleme sekmesine yeniden bakın:

    Screenshot of compute comparison in the Azure portal.

    Yüksek CPU kullanımında sürenin daha kısa olduğuna dikkat edin. Başka bir deyişle, iş yükünü çalıştırmak için CPU kaynaklarında genel bir düşüş gerekir.

  2. Bu grafik biraz yanıltıcı olabilir. İzleme menüsünden Ölçümler'i kullanın ve ardından Ölçümü CPU sınırına ayarlayın. CPU karşılaştırma grafiği, şuna benzer şekilde görünür:

    Screenshot of query comparison in the Azure portal.

Bahşiş

Bu veritabanı için sanal çekirdek sayısını artırmaya devam ederseniz, tüm sorgularının yeterince fazla CPU kaynağına sahip olduğu bir eşiğe kadar performansı geliştirebilirsiniz. Bu, sanal çekirdek sayısını iş yükünüzdeki eşzamanlı kullanıcı sayısına uydurmanız gerektiği anlamına gelmez. Buna ek olarak, Fiyatlandırma Katmanı'nı Sağlanan yerine Sunucusuz İşlem Katmanı'nı kullanacak şekilde değiştirebilirsiniz. Bu, bir iş yüküne yönelik daha otomatik ölçekli bir yaklaşım elde etmenize yardımcı olur. Örneğin, bu iş yükü için en az 2 sanal çekirdek değeri ve en fazla 8 sanal çekirdek değeri seçerseniz, bu iş yükü hemen 8 sanal çekirdek olarak ölçeklendirilir.

Sonraki alıştırmada bir performans sorunu gözlemleyip uygulama performansı için en iyi yöntemleri uygulayarak sorunu çözeceksiniz.