Ieu mangrupikeun klaim anu kuring kadéngé ti pamekar urang. Hal anu paling pikaresepeun nyaéta ieu tétéla leres, nyababkeun panalungtikan anu panjang. Urang bakal ngobrol ngeunaan server SQL anu ngajalankeun on VMware.
Sabenerna, meunang server produksi hopelessly balik laptop gampang. Jalankeun (henteu dina tempdb sareng henteu dina pangkalan data sareng Delayed Durability diaktipkeun) kodeu:
set nocount on
create table _t (v varchar(100))
declare @n int=300000
while @n>0 begin
insert into _t select 'What a slowpoke!'
delete from _t
set @n=@n-1
end
GO
drop table _t
Butuh 5 detik dina desktop kuring sareng 28 detik dina server produksi. Kusabab SQL kudu ngadagoan tungtung fisik nulis ka log urus, sarta kami ngalakonan transaksi pisan pondok dieu. Diomongkeun kasarna, urang drove a treuk kuat badag kana lalulintas kota, sarta kami ningali kumaha pangiriman pizza jalma on skuter kasohor overtaking eta - throughput teu penting di dieu, ngan latency penting. Na teu hiji gudang jaringan tunggal, euweuh urusan sabaraha enol aya dina harga na, bakal tiasa outperform a SSD lokal dina watesan latency.
(dina komentar tétéla yén kuring ngabohong - Kuring kungsi nyangsang durability dina duanana tempat. Tanpa durability nyangsang tétéla:
Desktop - 39 detik, 15K tr/detik, 0.065ms/io roundtrip
PROD - 360 detik, 1600 tr / detik, 0.6ms
Abdi kedah perhatikeun yén éta gancang teuing)
Sanajan kitu, dina hal ieu urang keur kaayaan enol trivial tina fungsi Riemann zeta kalawan conto trivial. Dina conto yén pamekar dibawa kuring, éta béda. Kuring éta yakin yén maranéhanana éta katuhu, sarta mimiti ngabersihan kaluar sagala specifics maranéhanana patali jeung logika bisnis tina conto. Dina sababaraha waktos, kuring sadar yén kuring tiasa ngalungkeun kode na, sareng nyerat sorangan - anu nunjukkeun masalah anu sami - dina produksi éta 3-4 kali langkung laun:
create function dbo.isPrime (@n bigint)
returns int
as
begin
if @n = 1 return 0
if @n = 2 return 1
if @n = 3 return 1
if @n % 2 = 0 return 0
declare @sq int
set @sq = sqrt(@n)+1 -- check odds up to sqrt
declare @dv int = 1
while @dv < @sq
begin
set @dv=@dv+2
if @n % @dv = 0 return 0
end
return 1
end
GO
declare @dt datetime set @dt=getdate()
select dbo.isPrime(1000000000000037)
select datediff(ms,@dt,getdate()) as ms
GOUpami sadayana henteu kunanaon sareng anjeun, teras mariksa kesederhanaan nomer bakal nyandak 6-7-8 detik. Ieu lumangsung dina sababaraha server. Tapi dina sababaraha, cék nyandak 25-40 detik. Narikna, teu aya server dimana palaksanaan bakal nyandak, sebutkeun, 14 detik - kode digarap boh gancang pisan atawa lambat pisan, nyaeta, masalahna éta, hayu urang sebutkeun, hideung bodas.
Naon anu kuring lakukeun? Gaduh kana métrik VMware. Sagalana éta rupa aya - aya nyatu sumberdaya, waktos Siap = 0, aya cukup sagalana, salila uji duanana dina gancang jeung slow server CPU = 100 on hiji vCPU. Kuring nyokot test keur ngitung jumlah Pi - test némbongkeun hasil anu sarua dina sagala server. Bau sihir hideung beuki kuat.
Sanggeus kaluar dina tegalan DEV, kuring mimiti maénkeun kalayan server. Tétéla yén vMotion ti host ka host tiasa "cageur" server, tapi ogé tiasa janten server "gancang" janten "slow". Sigana mah ieu téh - sababaraha host boga masalah ... tapi ... euweuh. Sababaraha mesin virtual ngalambatkeun dina host, sebutkeun, A, tapi digawé gancang dina host B. Jeung mesin virtual séjén, sabalikna, digawé gancang dina A jeung kalem dina B! Duanana "gancang" jeung "slow" mobil mindeng spinning on host!
Ti moment éta, aya bau béda walirang dina hawa. Barina ogé, masalahna teu tiasa dikaitkeun kana mesin virtual naon waé (contona, patches windows) - saatosna, éta janten "gancang" sareng vMotion. Tapi masalahna oge teu bisa attributed ka host - sanggeus kabeh, éta bisa boga duanana mesin "gancang" jeung "slow". Éta ogé henteu aya hubunganana sareng beban - kuring junun kéngingkeun mesin "lambat" dina host, dimana teu aya nanaon salian ti éta.
Kusabab desperation, abdi dipecat nepi Sysinternals 'Proses Explorer jeung nempo tumpukan SQL. Dina mesin laun, garis langsung narik panon kuring:
ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 < - !!!
ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
ntoskrnl.exe!KeSynchronizeExecution+0x2de2
sqllang.dll!CDiagThreadSafe::PxlvlReplace+0x1a20
… dilewatan
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Ieu geus hal. Program ieu ditulis:
class Program
{
[DllImport("kernel32.dll")]
static extern void GetSystemTimePreciseAsFileTime(out FILE_TIME lpSystemTimeAsFileTime);
[StructLayout(LayoutKind.Sequential)]
struct FILE_TIME
{
public int ftTimeLow;
public int ftTimeHigh;
}
static void Main(string[] args)
{
for (int i = 0; i < 16; i++)
{
int counter = 0;
var stopwatch = Stopwatch.StartNew();
while (stopwatch.ElapsedMilliseconds < 1000)
{
GetSystemTimePreciseAsFileTime(out var fileTime);
counter++;
}
if (i > 0)
{
Console.WriteLine("{0}", counter);
}
}
}
}Program ieu némbongkeun hiji slowdown malah leuwih dibaca - dina mesin "gancang" nembongkeun 16-18 juta siklus per detik, sedengkeun dina slow - hiji satengah juta, atawa malah 700 sarébu. Hartina, bédana 10-20 kali (!!!). Ieu parantos kameunangan leutik: dina sagala hal, teu aya ancaman pikeun macét antara dukungan Microsoft sareng VMware supados aranjeunna ngalihkeun panah ka silih.
Lajeng kamajuan dieureunkeun - pakansi, hal penting, histeria viral sarta ngaronjat seukeut dina workload. Kuring sering nyarios masalah magis ka kolega, tapi sakapeung sigana aranjeunna henteu percanten ka kuring - pernyataan yén VMware ngalambatkeun kode ku 10-20 kali teuing monstrous.
Kuring diusahakeun ngagali kaluar sorangan naon slows eta handap. Kadang-kadang sigana kuring mendakan solusi - ngaktipkeun sareng mareuman colokan Hot, ngarobih jumlah mémori atanapi jumlah prosesor sering janten mesin janten "gancang". Tapi teu salawasna. Tapi naon tétéla leres téh nya éta cukup kaluar jeung sambel on kabayang - nyaeta, ngarobah sagala parameter mesin virtual
Tungtungna, kolega Amérika kuring ujug-ujug mendakan akar sabab.
Host béda dina frékuénsi!
- Sakumaha aturan, ieu teu pikasieuneun. Tapi: nalika pindah ti host 'asli' ka host kalayan frekuensi 'béda', VMware kedah nyaluyukeun hasil GetTimePrecise.
- Sakumaha aturan, ieu teu masalah, iwal aya hiji aplikasi nu requests waktu pasti jutaan kali per detik, kawas SQL server.
- Tapi ieu ogé henteu pikasieuneun, sabab pangladén SQL henteu salawasna ngalakukeun ieu (tingali Kacindekan)
Tapi aya kasus nalika rake ieu nyeri. Na enya, ku knocking on roda (ku ngarobah hiji hal dina setélan VM), Kuring maksa VMware ka 'recalculate' konfigurasi, sarta frékuénsi host ayeuna jadi frékuénsi 'pribumi' mesin.
kaputusan
Nalika anjeun nganonaktipkeun virtualisasi TSC, maca TSC ti jero mesin virtual ngabalikeun nilai TSC mesin fisik, sareng nyerat TSC tina jero mesin virtual teu aya pangaruhna. Migrasi mesin virtual ka host sejen, neruskeun deui tina kaayaan ditunda, atawa balik ka snapshot a ngabalukarkeun TSC luncat discontinuously. Sababaraha sistem operasi tamu gagal boot, atawa némbongkeun masalah timekeeping séjén, lamun virtualization TSC ditumpurkeun. Baheula, fitur ieu kadang disarankeun pikeun ningkatkeun kinerja aplikasi anu sering maca TSC, tapi kinerja TSC maya geus ningkat substansi dina produk ayeuna. Fitur ieu ogé disarankeun pikeun dianggo nalika ngalakukeun pangukuran anu peryogi sumber waktos nyata dina mesin virtual.
Pondokna, anjeun kedah nambihan parameter
monitor_control.virtual_rdtsc = PALSU
kacindekan
Anjeun panginten gaduh patarosan: naha SQL sering nyauran GetTimePrecise?
Kuring teu boga sumber server SQL, tapi logika nyebutkeun kieu. SQL ampir mangrupa sistem operasi kalawan concurrency koperasi, dimana unggal thread kedah "masihan jalan" ti jaman ka jaman. Dimana tempat pangalusna pikeun ngalakukeunana? Dimana aya ekspektasi alam - konci atanapi IO. Oké, tapi kumaha lamun urang spinning siklus komputasi? Lajeng atra sarta ampir hijina tempat aya dina juru (ieu teu cukup juru), sanggeus dijalankeunnana operator salajengna.
Sakumaha aturan, server SQL henteu dianggo pikeun komputasi murni sareng ieu sanés masalah. Tapi siklus kalawan gawé kalawan sagala sorts tabel samentara (anu langsung sindangan) ngarobah kodeu kana runtuyan pernyataan pisan gancang dieksekusi.
Ngomong-ngomong, upami fungsina dibungkus ku NATIVELY COMPILED, teras lirén nyuhunkeun waktos, sareng kagancanganna ningkat ku 10 kali. Tapi kumaha upami multitasking koperasi? Tapi pikeun kode anu disusun sacara asli, kuring kedah ngalakukeun PREEMPTIVE MULTITASKING dina SQL.
sumber: www.habr.com