Soru ESXI tarafından barındırılan ortamda çok zayıf performans gösteren belirli SQL sorguları


Yakın zamanda 8 adet çift çekirdekli işlemci, 20 GB RAM ve 3 adet 1 TB'lık yeni bir makine kurduk. Buradaki donanım adamı. Bir ESXi ana bilgisayarı olarak kurulmuş ve içinde kurulmuş bir dizi test ortamımız var. Geçerli sınamalar, Windows 2003 64-bit SQL Server 2005 Standard 64-bit SP3 ile çalışıyor. Tüm raporlardan bu sistem, önceki kurulumumuzdan daha iyi performans gösteren ortamları barındırmalı ve bazı görevler çok daha kötü performans gösteriyor. Belli koşullarda çok yavaş bir şekilde çalışabilen ve anlayamadığım bir SQL betiğini buldum. SQL betiği, şu şekilde başlayan 1700+ UPDATE ifadesinin basit bir serisidir:

UPDATE SrfItem SET fkSrfItem = 5 WHERE id = 4
UPDATE SrfItem SET fkSrfItem = 8 WHERE id = 7
UPDATE SrfItem SET fkSrfItem = 10 WHERE id = 9

Bu sanal ortamlardan birinde aşağıdaki yordamı uygularsam, komut dosyasını çalıştırmanın 9-12 saniye sürdüğünü buldum:

Test Örneği # 1

  1. Test veritabanını sanal SQL Server ortamında bir yedeklemeden geri yükleme
  2. Veritabanına yerel olarak bağlan
  3. Komut dosyası çalıştır - bu adım 9 saniye sürüyor

Masaüstümde aynı prosedür 1 saniyeden daha kısa sürede adım 3'ü çalıştırdı.

Test Çantası # 2

  1. Test veritabanını fiziksel SQL Server ortamında bir yedeklemeden geri yükleme
  2. Veritabanına yerel olarak bağlan
  3. Komut Dosyası Çalıştır - bu adım 1 saniyeden az sürer

Ancak komut dosyasını bir işlemde çalıştırmak hızlıca gider

Test Çantası # 3

  1. Test veritabanını sanal SQL Server ortamında bir yedeklemeden geri yükleme
  2. Veritabanına yerel olarak bağlan
  3. Komut dosyasının başına "BEGIN TRAN" yazın
  4. Komut dosyasının sonuna "COMMIT TRAN" yazın
  5. Komut dosyası çalıştır - bu adım 1 saniyeden az sürer

İlginç bulduğum şey, bir kez işlem yaptıktan ve geri aldırdıktan sonra bile hala yavaş çalışıyor olmasıdır.

Test Çantası # 4

  1. Test veritabanını sanal SQL Server ortamında bir yedeklemeden geri yükleme
  2. Veritabanına yerel olarak bağlan
  3. Komut dosyasının başına "BEGIN TRAN" yazın
  4. Komut dosyasının sonuna "ROLLBACK TRAN" yazın
  5. Komut dosyası çalıştır - bu adım 1 saniyeden az sürer
  6. Yalnızca işlemin içermediği komut dosyasının yürütülmesini sağlayın - bu adım 9 saniye sürüyor.

Windows 2003 32-bit ve SQL 2005 32-bit ve Windows 2008 64-bit ve SQL 2008 64-bit ile sanal bir sistem ile sanal bir sistemde testleri çalıştırdım. Windows 2003 ve SQL 2005 ile fiziksel bir sistemde ve Windows 7 64-bit ve SQL 2008 R2 64-bit ile fiziksel bir sistem üzerinde testler yaptım. Denediğim tüm sanal sistemler bu yavaşlığı sergiliyor ve yeni ESXi ortamında barındırılıyor. Tüm fiziksel sistemler bu yavaşlığı göstermez.

Burada neler olup bittiğini anlamama yardım edebilir mi? Benzer performans sorunlarının diğer alanları etkilediğinden ve host veya konuk ortamlarında bir şeyi yeniden yapılandırmamız gerektiğinden korkuyorum. Şimdiye kadar düşünebildiğimiz tek şey, başka bir sanal ortamın ve yavaş davranışı göremediğimiz ana bilgisayarın konfigürasyonuna uyacak şekilde ana makinenin BIOS'unda hiper iş parçacığını devre dışı bırakmaktır. diğer sanal ortam ve yavaş olmadığı ana bilgisayar. Bu büyük bir performans farkı yaratabilir mi?

Düzenle: Sorularımın ve ilk cevabın gözden geçirilmesinden sonra, göstermeyi başardığımın, fiziksel ve sanal ortamlarımız arasındaki G / Ç gecikmesinin performansında bir farklılık olabileceğine katılıyorum. Ayrıca diğer bazı ayrıntıları sağladığımı da biliyorum: bu görüntüler zayıf provizyon kullanıyor ve bunların altında iki veya üç anlık görüntü var. Bu istatistiği önemli ölçüde etkiler mi? Şimdi soru şu, bu istatistiklerin sanal ortamlar ve fiziksel ortamlar arasında çok farklı olması normal midir? Çevrede veya SQL konfigürasyonunda optimizasyon yapabilmeli miyim, yoksa aşırı I / O gecikmeli sanal sistemler için daha uygun bir şekilde yazılacak yazılıma kadar mı?

vSphere istemcisi, sanal diskteki yazma gecikmesinin ortalama 21 ms ile 11 ila 40 ms olduğunu bildirir. Bu yararlı bir istatistik mi? Bu aşırı mı?

Düzenle: Donanımımızın (DL380 G6) açıklandığı gibi performans sorunları olduğu görülmektedir. http://laez.nl/vmware-bad-performance-on-hp-proliant-dl380-g6-with-esxi-3-5-u4/ ve performansı yükseltmek için yeniden yapılandırma yapmamız gerekiyor. Bizi, disk G / Ç gecikmesinin sorun olduğunu görmek için doğru yönde yönlendiren cevabı kabul edeceğim.


5
2017-09-18 15:20


Menşei


Bu, yavaş disk performansından kaynaklanabilir - lütfen bir hız testi çalıştırın - sourceforge.net/projects/iometer. - Andreas Rehm
Ne üzerinde koştun? ESXi sunucusunda işleri yapmak bile mümkün mü? ESXi'yi kaldırmak ve bir işletim sistemi kurmak zorunda değil miydik? - BlueMonkMN
Desteklenmeyen moda geçme ve smartctl --all / dev / sda smartctl --all / dev / sdb yazmanın sonuçları nedir? - ŹV -
Bu ana makinede çalıştırılacak bir şey mi? Eğer öyleyse, bir süre beklemek zorunda kalacak çünkü donanımı kendim görmemiştim ve ona erişimim yok (yardıma ihtiyacım var). Ana bilgisayar ve konuk ortamları çalışırken bunu yapmak güvenli midir? - BlueMonkMN
RAID5'i 1 TB diskler arasında çalıştırıyorsunuz. SQL log depolama için tam olarak önerilen yapılandırma değildir. - pauska


Cevaplar:


Sonuç olarak:

  • Gerçek sunucunuzda, bir saniyeden daha az 1700 tablo güncellemesi + 1700 taahhütte bulunabilirsiniz.
  • sanal sunucunuzda 1700 tablo güncellemelerini + 1700 işleminizi 9 saniyede yapabilirsiniz.
  • sanal sunucunuzda, 1700 tablo güncellemelerini + 1 işleminizi bir saniyeden daha kısa sürede yapabilirsiniz.

Öyleyse bana göre sorun, "bir sunucuda bir saniyeden daha az 1700 işlem yapabildiğim gerçek bir sunucuda, ancak sanal sunucumda on kat azaltılabilir" şeklinde yeniden tanımlanabilir.

1700 tablo güncellemeleri ve 1700 taahhüt arasındaki fark nedir? Tablo güncellemeleri tamamen önbelleğe alınmış ve disk G / Ç'larına bağlı değildir. İşlemlerle bu oldukça farklı. İşlem veritabanlarının doğası gereği, veritabanı motoru emin olmalı işlemek olmuştur aslında diske kaydedildi Bir sonraki işlemi yapmaya başlamadan önce (bir kayıt dosyasına kaydedilir). Yani bu 1700 işleminin her biri için, tüm G / Ç gidiş gelişini beklemek zorunda. Özetle, senaryonuzda G / Ç gecikmesi çok önemli bir rol oynar ve analiz edilmelidir (bayt cinsinden I / O oranı veya çıktısı ile gecikme hatası yapmayın, bu üçünün tamamen farklı hayvanları vardır; her zaman ayrı ayrı ayarlanmış).

Depolama alanınızı IOMeter ile test etmek için iyi bir plan. Tüm diskinizi test dosyasıyla doldurmaya çalıştığı için başlangıçta kilitleniyor. Sadece dosya önemli miktarda büyüyene kadar bekleyin ve IOMeter'ı yeniden başlatın, "eksik" test dosyasıyla düzgün şekilde çalışacaktır.


5
2017-09-19 10:03



Özet için +1; Muhtemelen BEGIN TRAN / COMMIT'in kaldırılmasının esasen her UPDATE'den önce ima edilen bir BEGIN TRAN'ı ve sonradan bir COMMIT eklediğini ve 1700 taahhütte bulunduğunu ve disklerin hızına fiziksel veya sanal olarak çok daha fazla bağımlı olduğunu belirtmeye değer. - SqlACID
Sonuçlarımı inceledikten sonra böyle bir şeyden şüphe ettim. Öyleyse soru, "sanal ortamlarda G / Ç gecikmesinde böyle büyük bir fark olması normal mi, yoksa bu ortamları optimize edebilmem gerekir mi?" Sorumu bu ve diğer detaylarla güncelleyeceğim. - BlueMonkMN
@blue - Sanal ortam depolamasının, ana sunuculardaki yerel disklerden ziyade bir SAN üzerinde bulunması çok yaygın. Bu disklerin bir çok VM arasında paylaşılması da yaygındır. Paraveniual SCSI'yi etkinleştirmekten, VM / VM'leri VM'nize ayırarak, ek disk önbellekleri, ağ / fiber geliştirmeleri ve SSD'ler ve / veya yerel depolama alanı ekleyerek olası iyileştirmelere yakından bakıyorum. Yaklaşık olarak bu sırayla. - Chris Thorpe
Bizi bu kadar şaşkına çeviren şey, biz Hangi yerel depolama alanı kullanıyor ve bir SAN üzerinde bulunan sanal sistemlerden daha kötü performans gösteriyor. Sanırım kullanılan sürücülerin ve belki de RAID konfigürasyonunun donanım istatistiklerine bakmamız gerekiyor. Umarım şimdi bir iş günümüz var, bazılarını gözden geçirebiliriz. - BlueMonkMN
Görüldüğü gibi, performansın nedeninin nedeni, en son düzenlemede anlattığım gibi sunucu modelimize özgüdür. Bizi doğru yola yönlendirdiğiniz için teşekkürler. - BlueMonkMN


Açıklıklarınız bu konuya biraz ışık tutuyor.

3 sürücü SATA RAID 5 paketi, yazma performansı için en uygun disk yapılandırması değildir. Her yazma IO, 4 diske kadar IO'ya sahiptir (mevcut bloğu oku, mevcut parite oku, yeni blok yaz, yeni parite yaz). Aslında bu, üç 7200 rpm diskinizi, temel sürücülerinizin 7200 rpm olduğu varsayılarak, tek bir 5400rpm sürücü gibi performans gösteren bir diske dönüştürür.

İkinci olarak, SQL VM'lerde bir dizi etkin anlık görüntünüz olduğunu söylüyorsunuz. VMware ESXi Snapshot'lar önemsiz olmayan bir yüke maruz kalıyor - aktif fotoğraflarınız olduğunda ne yaptığınıza bağlı olarak% 50-100 IO ek yük olacak. Bu hem okumaları hem de yazıları etkiler.

Üçüncü olarak, zayıf bir provizyon kullandığınızı söylüyorsunuz - bunun IO performansı üzerinde etkisi var, ancak diğer ikisi kadar önemli değil.

Son olarak, ESXi ana bilgisayarında başka bir VM'nin çalışıp çalışmadığını söyleyemezsiniz - eğer açıkçası, özellikle de bu RAID5 x 1TB SATA disk kurulumuyla genel performansı etkileyeceklerse.


3
2017-09-19 19:45





Sanallaştırılmış sistemde bir sorun olduğunu belirlemek için testlerinizin gerçekten sağlam olduğunu düşünmüyorum. Bir saniyelik bir test, sistemi herhangi bir gerçek darboğaz ortaya çıkarmaya zorlamak için yeterli zaman vermez.

Sanallaştırılmış bir dünyada ve SQL Server'da birçok hareketli parça vardır. Bence disk IO burada önemli bir oyuncu ama aynı zamanda RAM. ESX, talep üzerine konuklardan RAM alıp alabilir ve bazen ESX'in tepki göstermesi için birkaç saniye sürebilir, kısa duraksamalar üretir. Bir sunucu belirli bir sabit yükün altındaysa, ESX RAM'ı stablize eder, ancak eğer test kısasa ve patlarsa o zaman rampa yapmak zaman alabilir.

Bebeği banyo suyuna atmaya başlamadan önce, daha uzun testler yapın ve ESX ile izleyin ve RAM kullanımı, disk IO gecikmeleri, CPU kuyruk uzunlukları vb. Perfone edin. İyi bir test, fiziksel makinede 30 ila 60 saniye sürecektir. ve sanal makinenin bunun% 150'sinde olmasını beklerdim.


0
2017-09-19 20:56



Bu performans sorununun kaynağını haftalar boyunca araştırıyor ve zaten RAM'e ve bir takım başka etkenlere baktık. Bu test, çok güçlü olmasa da, bizi neye götürdü? hissetmek sorunun kaynağıdır - G / Ç gecikmesi. Olması gerekenden daha büyük bir büyüklük sırası gibi görünüyor, ki bu da tüm gözlemlere uyuyor gibi görünüyor. Elbette, daha fazla test yapmak da iyi bir fikir olabilir, ama zaten çalıştığım testin neye işaret ettiğini anlayamadım. Şimdi anladım. - BlueMonkMN