Olen lühikese aja jooksul kaks korda kokku puutunud sama olukorraga: SQL Server töötab, kõik näib korras, kuid jõudlus ei vasta sellele, mida riistvara peaks suutma. Mõlemal juhul oli põhjus virtuaalses kihis — server oli valesti konfigureeritud juba enne SQL Serveri paigaldamist.
Virtuaalmasinate puhul on kaks kõige levinumat eksimist: vale CPU topoloogia ja dünaamiline mälu. Mõlemat on lihtne mitte märgata — ja just see teeb need probleemid ohtlikuks.
CPU soketi probleem — Standard Editioni limiit
SQL Server Standard Edition on litsentseeritud soketite arvu ja tuumade koguarvu järgi — mõlemad piirid kehtivad samaaegselt:
- SQL Server kuni 2022: maksimaalselt 4 soketti ja 24 tuuma
- SQL Server 2025: maksimaalselt 6 soketti ja 32 tuuma
Füüsilises serveris on tavaliselt 1–2 päris soketti ja tuumade arv jääb limiitide piiresse, mistõttu see küsimus ei tule üldjuhul kõneks. Virtuaalses kihis võib aga eksida mõlemat moodi.
Vale soketi topoloogia: kui 8 loogilist tuuma jaotatakse 8 virtuaalse soketi vahel (8 × 1 tuuma), näeb SQL Server seda kui 8 eraldi protsessorit. Standard Edition lülitab üle limiidi jäävad soketid täielikult välja — kasutades ainult 4 × 1 tuuma. Pool eraldatud jõudlusest läheb kaduma.
Vale tuumade koguarv: ka õige soketi topoloogiaga VM võib põrkuda tuumade limiidi vastu. Näiteks 4 soketti × 8 tuuma = 32 tuuma — SQL Server 2022 kasutab sellest ainult 24. Õige konfiguratsioon ei ole ainult soketite arv, vaid ka tuumade koguarv tuleb limiidi piiresse mahutada.
Mõlemal juhul on tulemus sama: SQL Server töötab vaikselt alla oma võimekuse, ilma ühegi veateadet andmata.
SQL Server logib selle sündmuse käivitamisel ERRORLOG-i:
SQL Server detected N sockets with X cores per socket and X logical processors;
using X of X total sockets based on SQL Server licensing.
Kui „using X of X total sockets" väärtused ei kattu, on probleem olemas. Täiendavalt saab kontrollida:
SELECT cpu_count, socket_count, cores_per_socket
FROM sys.dm_os_sys_info;
Kui socket_count on oluliselt suurem kui cores_per_socket, tasub VM-i konfiguratsioon üle vaadata.
Dünaamiline mälu — probleem, mida SQL Server ise ei näe
Jagatud keskkondades on levinud praktika anda VM-ile dünaamiline mälu — hüperviisor eraldab mälu vastavalt hetkevajadustele ja jagab vaba ressurss teiste VM-ide vahel. Ressursside kasutuse mõttes on see mõistlik. SQL Serveri jaoks on see aga problemaatiline — ja oluline detail, mida paljud administraatorid ei tea: Microsoft ei toeta Hyper-V Dynamic Memoryt SQL Serveriga ametlikult. See ei tähenda, et see ei tööta, kuid Microsoft ei garanteeri stabiilsust ega jõudlust.
SQL Server eraldab mälu buffer pool'i jaoks käivitamisel ja eeldab, et see mälu on talle stabiilselt kättesaadav. SQL Server ei vabasta buffer pool'i vabatahtlikult — hüperviisor peab mälu balloon driver'i kaudu sunniviisiliselt välja suruma. Kui balloon driver töötab agressiivselt, ei ole tagajärg ainult latentsi kasv — võivad tekkida tõsisemad probleemid:
- IO tormid — buffer pool'i sunniviisiline kahandamine (shrink) surub andmed kettale, mida SQL Server muidu mälus hoidis
- RESOURCE_SEMAPHORE wait'id — päringud jäävad ootama mälueraldust, mis muidu oleks kohene
- Üldine ebastabiilsus koormusepiikide ajal, kui host ise on tihedalt koormatud
Diagnostika on siin sisuliselt võimatu SQL Serveri tasandilt. Erinevalt CPU soketite probleemist ei jäta dünaamiline mälu SQL Serveri logidesse mingit jälge. Ainus viis veenduda on vaadata VM-i konfiguratsiooni hosti tasemel.
Miks need probleemid nii kergesti juhtuvad?
Virtualiseerimisplatvorm ei tea ega hooli, mis tarkvara VM-is töötab. Dünaamiline mälu on just selleks mõeldud, et ressursse efektiivselt jagada — ja tavapärase töökoormuse jaoks see toimibki. SQL Serveri mälukäitumise ja litsentsimisloogika eripärad on aga teema, mis tuleb eraldi läbi mõelda, enne kui VM luuakse.
CPU topoloogia viga on diagnostiline — kui tead, kust vaadata, näed seda ERRORLOG-ist kohe. Mälu vale konfiguratsioon on peidus: probleem tuleb välja alles siis, kui keegi hosti tasandil konfiguratsioonil silma peale viskab, või kui olukord on juba käes.