Sayfa Yaşam Beklentisi örnek hakkında ne diyor?


9

İzleme yazılımını ortamdaki birkaç SQL Server örneğine yükledim. Darboğazları bulmaya ve bazı performans sorunlarını gidermeye çalışıyorum. Bazı sunucuların daha fazla belleğe ihtiyacı olup olmadığını öğrenmek istiyorum.

Bir sayaçla ilgileniyorum: sayfa ömrü beklentisi. Her makinede farklı görünüyor. Neden bazı durumlarda sık sık değişiyor ve ne anlama geliyor?

Lütfen birkaç farklı makinede toplanan son haftadaki verilere bir göz atın. Her örnek hakkında ne söyleyebilirsiniz?

Çok kullanılan üretim örneği (1): Çok kullanılan üretim örneği (1)

Orta derecede kullanılan üretim miktarı (2) Orta derecede kullanılan üretim miktarı (2)

Nadiren kullanılan test örneği (3)

Nadiren kullanılan test örneği (3)

Sık kullanılan üretim örneği (4) Sık kullanılan üretim örneği (4)

Orta derecede kullanılan test örneği (5) Orta derecede kullanılan test örneği (5)

Ağır kullanılan veri ambarı (6) Ağır kullanılan veri ambarı (6)

DÜZENLEME: Tüm bu sunucular için SELECT @@ VERSION çıktısını ekliyorum:

Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Oct 19 2012 13:38:57 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
    Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr 2 2010 15:48:46 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Ben de makinelerde aşağıdaki sorguyu koştu:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

ve her sunucu için 2 veya 3 satır döndürdü:

Instance 1: 0; 64; 1
Instance 2: 0; 64
Instance 3: 0; 64
Instance 4: 0; 64
Instance 5: 0; 64
Instance 6: 0; 64; 1

Bunun anlamı ne? Bu sunucular NUMA kullanıyor mu?


Örnek 2'de SQL Server 2012 vardır ve diğerleri SQL Server 2008 R2'dir
BuahahaXD

Grafiklerin ölçeği gerçekten yardımcı olmuyor. Meşgul sunucuların gün içinde sıfıra ne kadar yaklaştığını görmek daha ilginç olurdu.
James Z

Keşke daha detaylı veri alabilseydim. Solarwinds Veritabanı Performans İzleyicisi'ni kullandım ve bir dosyaya veri aktarmanın bir yolu yok. Bunu yapmanın tek yolu veritabanını sorgulamaktır, ancak yapı ne normalize edilmiştir ne de kavranması kolaydır.
BuahahaXD

1
Ani düşüşleri anlamanıza yardımcı olmak için: Önbelleğe alınmamış verilerin büyük bir taraması yapıldığında, yeni sayfalara yer açmak için birçok sayfa çıkarılır. Değiştirilmiş bir LRU algoritması. Yeni sayfalar eskilerini bırakır.
usr

Örnek 2 ve 6 NUMA kullanır, diğerleri kullanmaz.
BuahahaXD

Yanıtlar:


8

MSDN'den alınmıştır: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Sayfa ömrü beklentisi - Sayfanın referans olmadan arabellek havuzunda kaç saniye kalacağını gösterir.

SQL her zaman bellekteki veri sayfalarını arar. Bir veri sayfası bellekte değilse, bir isteği yerine getirmek için ihtiyaç duyduğu verileri almak için SQL diske gitmelidir (fiziksel bir IO işlemi gerçekleştirmelidir). PLE sayacınız düşükse, bellekteki veri sayfalarının fiziksel G / Ç işlemlerinden gelen yeni sayfalarla düzenli olarak üzerine yazıldığını gösterir. Fiziksel IO işlemleri pahalıdır, yani SQL örneğinizin performansı olumsuz etkilenir. Böylece PLE sayacınızın mümkün olduğunca yüksek olmasını isteyeceksiniz.

Çevrimiçi olarak 300'den bu sayaç için iyi bir eşik olarak bahsettiğiniz tavsiyeleri göz ardı edin

Bu eşik, belleğin sınırlı olduğu günlerden gelir (32 bit sistemleri düşünün). Şimdi TB'lere RAM sahip olabilecek 64 bit sistemlerimiz var, bu nedenle bu tavsiye çok güncel değil.

İlk olarak, SQL belleğini sınırladınız mı? Öyleyse, ne kadar kullanılabilir bellek kaldı? Sınır artırılabilir mi?

Sunucularınızda aradığım ikinci şey, çalışan herhangi bir bakım işi var mı? Dizin yeniden oluşturma, güncelleme istatistikleri veya DBCC CHECKDB işlemleri gerçekleştiren işleri kontrol edin. Bunlar büyük miktarda okuma yapar ve PLE düz astarınızın nedeni olabilir,

Ardından, SQL Server 2008 + 'ı kullanırken, büyük miktarda okuma gerçekleştiren sorguları yakalamak için bir Genişletilmiş Etkinlik oturumu ayarlayabilirsiniz. İşte bunu yapmak için kod: -

CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
   ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
     WHERE ([logical_reads]>200000))
ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel')
GO

Bu, sunucunuzda 200000'den fazla mantıksal okuma gerçekleştiren tüm sorguları yakalayacaktır. Her sunucuda ne kadar belleğiniz olduğunu bilmiyorum, bu yüzden bu rakamı değiştirmek isteyebilirsiniz. Bu oluşturulduktan sonra çalışmayı başlatarak başlatabilirsiniz: -

ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO

Ve çalıştırarak oturumu sorgulayın: -

WITH CTE_ExecutedSQLStatements AS
(SELECT
[XML Data],
[XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME')    AS [Time],
[XML Data].value('(/event/data[@name=''duration'']/value)[1]','int')                        AS [Duration],
[XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int')                        AS [CPU],
[XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int')                   AS [logical_reads],
[XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int')                  AS [physical_reads],
[XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)')             AS [SQL Statement]
FROM
    (SELECT 
    OBJECT_NAME              AS [Event], 
    CONVERT(XML, event_data) AS [XML Data]
FROM 
    sys.fn_xe_file_target_read_file
('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v)

SELECT
[SQL Statement]     AS [SQL Statement],
SUM(Duration)       AS [Total Duration],
SUM(CPU)            AS [Total CPU],
SUM(Logical_Reads)  AS [Total Logical Reads],
SUM(Physical_Reads) AS [Total Physical Reads]
FROM
CTE_ExecutedSQLStatements
GROUP BY
[SQL Statement]
ORDER BY
[Total Logical Reads] DESC
GO

Bunu çalıştırırken dikkatli olun! Dosya oldukça büyüyebilir, bu yüzden önce bir geliştirme örneğinde test edin. Maks. dosyanın boyutunu ekledim ama buraya eklemedim. Genişletilmiş Etkinlikler için MSDN bağlantısı: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Bu oturumu rutin olarak izleyin ve umarım PLE'nizi düz bir şekilde kaplayan sorguları almalıdır.

Daha fazla okuma -

PLE'de MSDN blogu - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

Genişletilmiş Etkinlikler oluşturma hakkında video - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (Kendi blogumdan utanmaz öz tanıtım için çok üzgünüm )


4

Sayfa ömrü beklentisi, diskten okunan bir sayfanın başka bir şey tarafından dışarı itilmeden veya yok edilmeden önce bellekte takılmasının ne kadar bekleyebileceğinin bir ölçüsüdür. kopyasını RAM'de önbelleğe almak için).

Genel bir önlem olarak, işler ne kadar hızlı saklanırsa yük deseniniz o kadar hızlı işlenir. Çok düşükse bu, bellek açlığının neden olduğu bir performans sorununu gösterebilir.

Okumanın düşük olması her zaman bir sorun olduğu anlamına gelmez: örneğin, çok sayıda sayfa kullanan devasa bir defalık süreçlerden sonra düşük olabilir, bu yüzden onları getirdiler ve daha fazlasına yer açmak için düştüler. Örneğin, her günün sonunda düşmüş gibi görünen grafiğiniz, gece yönetim işlerinden (yedekleme, veri arşivleme, diğer gece işleme) kaynaklanabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.