אפשר ליישם כמה שיטות מומלצות כדי לבצע אופטימיזציה של מכונות Compute Engine שמריצות Microsoft SQL Server. כדי ללמוד איך להגדיר מכונה של SQL Server עם ביצועים גבוהים, אפשר לקרוא את המאמר יצירת מכונה של SQL Server עם ביצועים גבוהים.
שימוש בכלי לניהול עומס העבודה להערכה ולפריסה של SQL Server
הערכת SQL Server ב-כלי לניהול עומס העבודה מאפשרת לסרוק את פריסות SQL Server עם קבוצה של המלצות מוגדרות מראש לביצועים אופטימליים ישירות מהמסוףGoogle Cloud . Google Cloud מידע נוסף זמין במאמר הוראות להגדרת סוכן ל-SQL Server.
הכלי Guided Deployment Automation ב-כלי לניהול עומס העבודה מאפשר לכם להגדיר ולפרוס אפליקציות ארגוניות ב- Google Cloud. אפשר גם להשתמש באוטומציה מודרכת של פריסה כדי להגדיר פריסה לעומס העבודה, ואז ליצור תשתית Terraform ו-Ansible כקוד (IaC) שאפשר לייצא להתאמה אישית נוספת או להשתמש בה בצינור פריסה קיים. מידע נוסף זמין במאמר בנושא אוטומציה מודרכת של פריסה.
הגדרת Windows
בקטע הזה מוסבר איך לבצע אופטימיזציה של מערכת ההפעלה Microsoft Windows לביצועים של SQL Server כשמריצים אותה ב-Compute Engine.
הגדרה של חומת האש ב-Windows
שיטה מומלצת: משתמשים בחומת האש המתקדמת של Windows Server ומציינים את כתובות ה-IP של מחשבי הלקוח.
חומת האש המתקדמת של Windows היא רכיב אבטחה חשוב ב-Windows Server. כשמגדירים את סביבת SQL Server כך שהיא תוכל להתחבר למסד הנתונים ממכונות לקוח אחרות, צריך להגדיר את חומת האש כך שתאפשר תעבורה נכנסת:
netsh advfirewall firewall add rule name="SQL Access" ^ dir=in action=allow ^ program="%programfiles%\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn\sqlservr.exe" ^ remoteip=LOCAL_SUBNET
כשמשתמשים בכלל חומת האש הזה, מומלץ לציין את כתובת ה-IP של מכונות הלקוח. מגדירים רשימה של כתובות IP שמופרדות בפסיקים ללא רווחים בפרמטר remoteip במקום LOCAL_SUBNET. בנוסף, שימו לב שהנתיב של הפרמטר program עשוי להשתנות בהתאם לגרסה של SQL Server שבה אתם משתמשים.
תמונת האפליקציה של SQL Server כוללת SQL Server כלל חומת אש של Windows.
הכלל הזה לא מוגבל במיוחד, ולכן כדאי להשבית אותו לפני שהמערכת עוברת לייצור.
שיפור החיבורים לרשת
שיטה מומלצת: שימוש בהגדרות ברירת המחדל של הרשת במערכת ההפעלה.
הגדרות הרשת שמוגדרות כברירת מחדל ברוב מערכות ההפעלה מיועדות לחיבורים במחשבים קטנים שמחוברים לרשתות מהירות בינונית. בדרך כלל ההגדרות האלה מספיקות. בנוסף, הגדרות ברירת המחדל השמרניות מבטיחות שתעבורת הרשת לא תעמיס יתר על המערכת ולא תגרום לעומס על המחשבים המחוברים לרשת.
ב-Compute Engine, מכונות וירטואליות (VM) מקושרות לרשת שתוכננה על ידי Google ומציעה קיבולת וביצועים גבוהים. השרתים הפיזיים שמריצים את המכונות של Compute Engine מותאמים במיוחד כדי לנצל את קיבולת הרשת הזו. גם מנהלי ההתקנים של הרשתות הווירטואליות במופעים שלכם עוברים אופטימיזציה, ולכן ערכי ברירת המחדל מספיקים לרוב תרחישי השימוש.
התקנת אנטי-וירוס
שיטה מומלצת: כדאי לפעול לפי ההנחיות של מיקרוסופט לגבי תוכנות אנטי-וירוס.
אם אתם משתמשים ב-Windows, כדאי להפעיל תוכנת אנטי-וירוס. תוכנות זדוניות ווירוסים בתוכנה מהווים סיכון משמעותי לכל מערכת שמחוברת לרשת, ותוכנת אנטי-וירוס היא אמצעי פשוט שאפשר להשתמש בו כדי להגן על הנתונים. עם זאת, אם תוכנת האנטי-וירוס לא מוגדרת בצורה נכונה, היא עלולה לפגוע בביצועים של מסד הנתונים. Microsoft מספקת עצות לגבי בחירת תוכנת אנטי-וירוס.
אופטימיזציה לשיפור הביצועים והיציבות
בקטע הזה מוסבר איך לייעל את הביצועים של SQL Server ב-Compute Engine, ומתוארות פעולות תפעוליות שיעזרו לכם לשמור על פעולה חלקה.
העברת קובצי נתונים וקובצי יומן לדיסק חדש
שיטה מומלצת: כדאי להשתמש בדיסק מתמיד שמבוסס על SSD נפרד לקובצי יומן ונתונים.
כברירת מחדל, קובץ האימג' שהוגדר מראש ל-SQL Server כולל את כל מה שמותקן בדיסק האתחול של דיסק אחסון מתמיד (persistent disk), שמוגדר ככונן C:. אפשר לצרף דיסק מתמיד שמבוסס על SSD משני ולהעביר את קובצי היומן וקובצי הנתונים לדיסק החדש.
שימוש ב-SSD מקומי כדי לשפר את IOPS
שיטה מומלצת: כדאי ליצור מכונות חדשות של SQL Server עם כונני SSD מקומיים אחד או יותר כדי לאחסן את tempdb ואת קובצי ההחלפה של Windows.
הטכנולוגיה של SSD מקומי היא זמנית, ולכן היא לא מתאימה לשימוש עם מסדי נתונים קריטיים וקבצים חשובים. עם זאת, קובץ ההחלפה של tempdb
ושל Windows הם קבצים זמניים, ולכן שניהם מועמדים מצוינים להעברה ל-SSD מקומי. כך מתבצעת העברה של מספר משמעותי של פעולות קלט/פלט (I/O)
מדיסקים קבועים של SSD. מידע נוסף על הגדרת TempDB
עיבוד מקביל של שאילתות
שיטה מומלצת: מגדירים את max degree of parallelism לערך 8.
ההגדרה המומלצת כברירת מחדל ל-max degree of parallelism היא להתאים אותה למספר המעבדים בשרת. עם זאת, יש נקודה שבה פיצול שאילתה ל-16 או ל-32 חלקים, הפעלת כולם ב-vCPU שונים ואיחוד הכל בחזרה לתוצאה אחת, לוקח הרבה יותר זמן מאשר אם רק vCPU אחד היה מריץ את השאילתה. בפועל, הערך 8 הוא ערך ברירת מחדל טוב.
שיטה מומלצת: עוקבים אחרי ההמתנות של CXPACKET ומגדילים את cost threshold for parallelism בהדרגה.
ההגדרה הזו קשורה להגדרה max degree of parallelism. כל יחידה מייצגת שילוב של עבודת מעבד (CPU) וקלט/פלט שנדרשת לביצוע שאילתה עם תוכנית הרצה סדרתית לפני שהיא נחשבת לתוכנית הרצה מקבילית. ערך ברירת המחדל הוא 5.
למרות שאנחנו לא נותנים המלצה ספציפית לשנות את ערך ברירת המחדל, כדאי לעקוב אחריו ואם צריך, להגדיל אותו בהדרגה ב-5 במהלך בדיקת העומס. אחד מהאינדיקטורים העיקריים לכך שצריך להגדיל את הערך הזה הוא נוכחות של CXPACKET המתנה. אמנם נוכחות של CXPACKET waits לא בהכרח מצביעה על כך שצריך לשנות את ההגדרה הזו, אבל זה מקום טוב להתחיל בו.
שיטה מומלצת: כדאי לעקוב אחרי סוגים שונים של המתנה, ולשנות את ההגדרות הגלובליות של עיבוד מקביל או להגדיר אותן ברמת מסד הנתונים הספציפי.
יכול להיות שלכל מסד נתונים יהיו צרכים שונים של מקביליות. אפשר להגדיר את ההגדרות האלה באופן גלובלי, ולהגדיר את Max DOP ברמת מסד הנתונים הספציפי. כדאי לבחון את עומסי העבודה הייחודיים, לעקוב אחרי זמני ההמתנה ואז לשנות את הערכים בהתאם.
באתר SQLSkills יש מדריך שימושי לשיפור הביצועים, שכולל נתונים סטטיסטיים על זמני ההמתנה במסד הנתונים. המדריך הזה יעזור לכם להבין מה גורם לעיכובים ואיך אפשר לצמצם אותם.
טיפול ביומני עסקאות
שיטה מומלצת: כדאי לעקוב אחרי הגידול ביומן העסקאות במערכת. כדאי להשבית את הגידול האוטומטי ולהגדיר את קובץ היומן לגודל קבוע, על סמך הצטברות היומן היומית הממוצעת.
אחד המקורות שהכי קל לפספס כשמנסים להבין למה הביצועים יורדים ולמה יש האטה לסירוגין הוא הגידול הלא מנוהל של יומן העסקאות. אם מסד הנתונים מוגדר לשימוש במודל השחזור Full, אפשר לבצע שחזור לכל נקודת זמן, אבל יומני העסקאות מתמלאים מהר יותר. כברירת מחדל, כשקובץ יומן הטרנזקציות מלא, SQL Server מגדיל את גודל הקובץ כדי להוסיף עוד מקום ריק לכתיבת טרנזקציות נוספות, וחוסם את כל הפעילות במסד הנתונים עד לסיום. ב-SQL Server, כל קובץ יומן גדל בהתאם לגודל הקובץ המקסימלי ולהגדרה של גידול הקובץ.
כשהקובץ מגיע למגבלת הגודל המקסימלית שלו ואי אפשר להגדיל אותו, המערכת מציגה שגיאה 9002 ומעבירה את מסד הנתונים למצב קריאה בלבד. אם אפשר להגדיל את הקובץ, SQL Server מגדיל את גודל הקובץ ומאפס את השטח הריק. ההגדרה של File Growth (גידול הקובץ) מוגדרת כברירת מחדל ל-10% מהגודל הנוכחי של קובץ היומן. זו לא הגדרת ברירת מחדל טובה לביצועים, כי ככל שהקובץ גדל, לוקח יותר זמן ליצור את המקום החדש והריק.
שיטה מומלצת: כדאי לתזמן גיבויים קבועים של יומן העסקאות.
בלי קשר להגדרות הגודל המקסימלי והגידול, כדאי לתזמן גיבויים קבועים של יומן העסקאות. כברירת מחדל, הגיבויים האלה חותכים רשומות ישנות ביומן ומאפשרים למערכת לעשות שימוש חוזר בשטח הקובץ הקיים. משימת התחזוקה הפשוטה הזו יכולה לעזור לכם להימנע מירידה בביצועים בשעות העומס.
אופטימיזציה של קובצי יומן וירטואליים
שיטה מומלצת: כדאי לעקוב אחרי הגידול של קובץ היומן הווירטואלי ולנקוט פעולות כדי למנוע פיצול של קובץ היומן.
קובץ יומן הטרנזקציות הפיזי מפולח לקובצי יומן וירטואליים (VLF). קבצים חדשים של יומני טרנזקציות וירטואליים נוצרים בכל פעם שקובץ יומן הטרנזקציות הפיזי צריך לגדול. אם לא השבתתם את הגידול האוטומטי, והגידול מתרחש לעיתים קרובות מדי, נוצרים יותר מדי קבצים וירטואליים של יומני טרנזקציות. הפעילות הזו עלולה לגרום לפיצול של קובץ היומן, בדומה לפיצול של הדיסק, וזה עלול להשפיע לרעה על הביצועים.
ב-SQL Server 2014 הוצג אלגוריתם יעיל יותר לקביעת מספר ה-VLFs שייווצרו במהלך הגדלה אוטומטית. באופן כללי, אם הגידול קטן מ-1/8 מגודל קובץ היומן הנוכחי, SQL Server יוצר VLF אחד בקטע החדש הזה. בעבר, המערכת הייתה יוצרת 8 קבצים לוגיים וירטואליים (VLF) לגידול בין 64 MB ל-1 GB, ו-16 קבצים לוגיים וירטואליים לגידול מעל 1 GB. אפשר להשתמש בסקריפט TSQL שבהמשך כדי לבדוק כמה קבצים וירטואליים של יומן (VLF) יש כרגע במסד הנתונים. אם יש בו אלפי קבצים, כדאי לצמצם את גודל קובץ היומן ולשנות את הגודל שלו באופן ידני.
--Check VLFs substitute your database name below USE YOUR_DB DECLARE @vlf_count INT DBCC LOGINFO SET @vlf_count = @@ROWCOUNT SELECT VLFs = @vlf_count
מידע נוסף על VLFs זמין באתר של Brent Ozar.
איך להימנע מפיצול של אינדקסים
שיטה מומלצת: כדאי לבצע דה-פרגמנטציה של האינדקסים בטבלאות שמשתנות הכי הרבה באופן קבוע.
האינדקסים בטבלאות יכולים להיות מקוטעים, מה שעלול להוביל לביצועים ירודים של שאילתות שמשתמשות באינדקסים האלה. לוח זמנים קבוע לתחזוקה צריך לכלול ארגון מחדש של האינדקסים בטבלאות שמשתנות הכי הרבה.
אפשר להריץ את סקריפט Transact-SQL הבא במסד הנתונים כדי להציג את האינדקסים ואת אחוז הפיצול שלהם. בדוגמה של התוצאות אפשר לראות שהאינדקס PK_STOCK מפוצל ב-95%. בהצהרת ה-SELECT הבאה, מחליפים את YOUR_DB בשם של מסד הנתונים:
SELECT stats.index_id as id, name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(N'YOUR_DB'), NULL, NULL, NULL, NULL) AS stats
JOIN sys.indexes AS indx ON stats.object_id = indx.object_id
AND stats.index_id = indx.index_id AND name IS NOT NULL;
RESULTS
-------------------------------
Id name avg_fragmentation_in_percent
-------------------------------
1 ORDERS_I1 0
2 ORDERS_I2 0
1 ORDER_LINE_I1 0.01
1 PK_STOCK95.5529819557039
1 PK_WAREHOUSE0.8
אם האינדקסים מפוצלים מדי, אפשר לארגן אותם מחדש באמצעות סקריפט בסיסי של ALTER. זו דוגמה לסקריפט שמדפיס את ההצהרות שאפשר להריץ עבור כל אחד מהאינדקסים של הטבלאות:ALTER
SELECT 'ALTER INDEX ALL ON ' + table_name + ' REORGANIZE; GO' FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_CATALOG = 'YOUR_DB'
בוחרים את הטבלאות מתוך קבוצת התוצאות עם הפיצול הכי גבוה, ואז מריצים את ההצהרות האלה באופן מצטבר. כדאי לתזמן את הסקריפט הזה או סקריפט דומה כאחת ממשימות התחזוקה הקבועות שלכם.
פרמוט של דיסקים משניים
שיטה מומלצת: עיצוב דיסקים משניים עם יחידת הקצאה של 64 KB.
ב-SQL Server, הנתונים מאוחסנים ביחידות אחסון שנקראות extents. הגודל של כל extent הוא 64KB, והוא מורכב משמונה דפי זיכרון רציפים שכל אחד מהם הוא בגודל 8KB. פורמט של דיסק עם יחידת הקצאה של 64 KB מאפשר ל-SQL Server לקרוא ולכתוב נתונים בצורה יעילה יותר, וכך לשפר את ביצועי הקלט/פלט מהדיסק.
כדי לפרמט דיסקים משניים עם יחידת הקצאה של 64 KB, מריצים את פקודת PowerShell הבאה, שמחפשת את כל הדיסקים החדשים שלא אותחלו במערכת ומפרמטת את הדיסקים עם יחידת הקצאה של 64 KB:
Get-Disk | Where-Object {$_.PartitionStyle -eq 'RAW'} | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -AllocationUnitSize 65536 -Confirm:$FALSE
גיבוי
שיטה מומלצת: כדי להשיג הגנה אופטימלית, מומלץ לגבות את הנתונים באופן קבוע באמצעות פתרונות הגיבוי וההתאוששות מאסון של Google. מומלץ לגבות את הנתונים לפחות פעם ביום.
פתרונות הגיבוי וההתאוששות מאסון של Google מספקים את היתרונות הבאים ל-Microsoft SQL Server:
- גיבוי מצטבר יעיל עם שחזור אמיתי לנקודת זמן מסוימת, שעוזר לבצע גיבוי בפחות זמן מגיבויים רגילים, תוך צמצום ההשפעה על שרתי הייצור. היא גם מפחיתה את רוחב הפס ואת צריכת האחסון עבור יעד התאוששות מאסון (RPO) נמוך ועבור העלות הכוללת של הבעלות (TCO).
- Mount and migrate recoveries (M&M) לגיבויים שמאוחסנים ב-Cloud Storage, כדי להקטין את זמן ההתאוששות (RTO).
- שילוב מקיף עם יכולות SQL Server, כולל תמיכה באשכולות של קבוצות זמינות של SQL Server ומספר אפשרויות שחזור בתרחישים שונים.
- חלונית ניהול מרכזית כולל יכולות ייעודיות של מעקב, התראות ודיווח לכל הגיבויים.
למידע נוסף:
- סקירה כללית על המוצר שירות Backup and DR
- רשימת התכונות של שירות Backup and DR
- הגנה על מסדי נתונים של Microsoft SQL Server ושחזור שלהם
- תמחור של שירות Backup and DR
- מחשבון תמחור
מעקב
שיטה מומלצת: שימוש ב-Cloud Monitoring.
אפשר להתקין את סוכן Cloud Monitoring עבור Microsoft Windows כדי לשלוח כמה נקודות נתונים של מעקב למערכת Cloud Monitoring.
באמצעות יכולות איסוף הנתונים, אפשר לכוונן את המידע שרוצים לעקוב אחריו ולשלוח אותו אל מחסן הנתונים המובנה לניהול. אפשר להריץ את מחסן נתוני הניהול באותו השרת שאתם מנטרים, או להזרים את הנתונים למופע אחר של SQL Server שמריץ את המחסן.
טעינת נתונים בכמות גדולה
שיטה מומלצת: כדאי להשתמש במסד נתונים נפרד כדי להכין ולשנות נתונים בכמות גדולה לפני שמעבירים אותם לשרתי הייצור.
סביר להניח שתצטרכו לטעון כמויות גדולות של נתונים למערכת לפחות פעם אחת, ואולי באופן קבוע. זו פעולה שדורשת הרבה משאבים, ויכול להיות שתגיעו למגבלת ה-IOPS של דיסק אחסון מתמיד כשאתם מבצעים העלאות בכמות גדולה.
יש דרך פשוטה לצמצם את קלט/פלט הדיסק ואת צריכת המעבד של פעולות טעינה בכמות גדולה, וגם לקצר את זמן הביצוע של משימות אצווה. הפתרון הוא ליצור מסד נתונים נפרד לחלוטין שמשתמש בSimple מודל השחזור, ואז להשתמש במסד הנתונים הזה כדי להכין ולשנות את מערך הנתונים הגדול לפני שמוסיפים אותו למסד הנתונים של הסביבה הפרודקטיבית. אפשר גם לשמור את מסד הנתונים החדש בכונן SSD מקומי, אם יש לכם מספיק מקום. שימוש בכונן SSD מקומי למסד הנתונים של השחזור מצמצם את צריכת המשאבים של הפעולות בכמות גדולה ואת הזמן שנדרש להשלמת העבודות.
היתרון האחרון הוא שעבודת הגיבוי של נתוני הייצור לא תצטרך לגבות את כל הפעולות האלה בכמות גדולה ביומן העסקאות, ולכן היא תהיה קטנה יותר ותפעל מהר יותר.
אימות ההגדרה
שיטה מומלצת: כדאי לבדוק את ההגדרה כדי לוודא שהיא פועלת כמצופה.
בכל פעם שמגדירים מערכת חדשה, מומלץ לתכנן את אימות ההגדרה ולהריץ כמה בדיקות ביצועים. הפרוצדורה המאוחסנת הזו היא משאב מצוין להערכת ההגדרה של SQL Server. אפשר לקרוא על דגלי ההגדרה ולבצע את התהליך מאוחר יותר.
אופטימיזציה של SQL Server Enterprise Edition
מהדורת SQL Server Enterprise כוללת רשימה ארוכה של יכולות נוספות בהשוואה למהדורת Standard. אם אתם מעבירים רישיון קיים אלGoogle Cloud, יש כמה אפשרויות לשיפור הביצועים שכדאי לכם לשקול להטמיע.
שימוש בטבלאות דחוסות
שיטה מומלצת: הפעלת דחיסה של טבלאות ואינדקסים.
יכול להיות שזה נשמע לא הגיוני שדחיסת טבלאות יכולה לשפר את הביצועים של המערכת, אבל ברוב המקרים זה מה שקורה. הפשרה היא שימוש בכמות קטנה של מחזורי מעבד (CPU) כדי לדחוס נתונים ולבטל את קלט/פלט הדיסק הנוסף שנדרש לקריאה ולכתיבה של הבלוקים הגדולים יותר. באופן כללי, ככל שהמערכת משתמשת בפחות קלט/פלט של דיסק, כך הביצועים שלה טובים יותר. הוראות להערכה ולהפעלה של דחיסת טבלאות ואינדקסים מופיעות באתר MSDN.
הפעלה של תוסף מאגר הנתונים הזמני
שיטה מומלצת: כדאי להשתמש בתוסף של מאגר הנתונים הזמני כדי להאיץ את הגישה לנתונים.
מאגר החוצץ הוא המקום שבו המערכת מאחסנת דפים נקיים. במילים פשוטות, הוא שומר עותקים של הנתונים שלכם, שמשקפים את מה שמופיע בדיסק. כשנתונים משתנים בזיכרון, הדף נקרא דף מלוכלך. צריך להעביר דפים עם נתונים מלוכלכים (dirty) לדיסק כדי לשמור את השינויים. אם מסד הנתונים גדול יותר מהזיכרון הזמין, זה יוצר עומס על מאגר הנתונים הזמני, ויכול להיות שדפים נקיים יימחקו. כשדפים נקיים מושלכים, המערכת צריכה לקרוא מהדיסק בפעם הבאה שהיא ניגשת לנתונים שהושלכו.
התכונה buffer pool extension מאפשרת להעביר דפים נקיים ל-SSD מקומי, במקום להסיר אותם. השיטה הזו דומה לשימוש בזיכרון וירטואלי, כלומר באמצעות החלפה, והיא מאפשרת לכם לגשת לדפים הנקיים ב-SSD המקומי, שהגישה אליו מהירה יותר מאשר הגישה לדיסק הרגיל כדי לאחזר את הנתונים.
הטכניקה הזו לא מהירה כמו שיש מספיק זיכרון, אבל היא יכולה להגדיל את קצב העברת הנתונים בצורה מתונה כשהזיכרון הזמין נמוך. באתר של ברנט אוזר אפשר לקרוא מידע נוסף על הרחבות של מאגר נתונים זמני ולעיין בתוצאות של בדיקות השוואה.
אופטימיזציה של רישוי SQL Server
Simultaneous Multithreading (SMT)
שיטה מומלצת: כדאי להגדיר את מספר השרשורים לכל ליבה כ-1 עבור רוב עומסי העבודה של SQL Server
Simultaneous multithreading (SMT), שנקרא בדרך כלל Hyper-Threading Technology (HTT) במעבדי Intel, הוא תכונה שמאפשרת לשתף באופן לוגי ליבת CPU אחת כשני שרשורים. ב-Compute Engine, SMT מופעל ברוב המכונות הווירטואליות כברירת מחדל, מה שאומר שכל vCPU במכונה הווירטואלית פועל בשרשור יחיד, וכל ליבה פיזית של CPU משותפת לשני vCPU.
ב-Compute Engine, אפשר להגדיר את מספר ה-threads לכל ליבה, מה שמשבית למעשה את SMT. כשמספר ה-threads לכל ליבה מוגדר ל-1, מעבדי ה-vCPU לא חולקים ליבות מעבד פיזיות. להגדרה הזו יש השפעה משמעותית על עלויות הרישוי של Windows Server ו-SQL Server. כשמספר השרשורים לכל ליבה מוגדר כ-1, מספר יחידות ה-vCPU במכונה הווירטואלית מצטמצם בחצי, וכך גם מספר הרישיונות של Windows Server ו-SQL Server שנדרשים. הפעולה הזו יכולה להקטין באופן משמעותי את העלות הכוללת של עומס העבודה.
עם זאת, הגדרת מספר השרשורים לכל ליבה משפיעה גם על ביצועי עומס העבודה. אפליקציות שנכתבו כך שהן יכולות להשתמש בכמה תהליכים יכולות לנצל את התכונה הזו על ידי חלוקת עבודת המחשוב לחלקים קטנים יותר שניתנים להרצה במקביל, שמתוזמנים בכמה ליבות לוגיות. ההקבלה הזו של העבודה מגדילה בדרך כלל את התפוקה הכוללת של המערכת, כי היא מאפשרת ניצול טוב יותר של משאבי הליבה הזמינים. לדוגמה, אם תהליך אחד נתקע, התהליך השני יכול להשתמש בליבה.
ההשפעה המדויקת של SMT על SQL Server תלויה במאפייני עומס העבודה ובפלטפורמת החומרה שבה נעשה שימוש, כי ההטמעה של SMT שונה בין דורות החומרה. עומסי עבודה עם נפח גבוה של טרנזקציות קטנות, למשל עומסי עבודה של OLTP, יכולים ליהנות מ-SMT, ולקבל שיפור גדול יותר בביצועים. לעומת זאת, עומסי עבודה שניתן להקביל אותם פחות, למשל עומסי עבודה של OLAP, נהנים פחות מ-SMT. למרות שהדפוסים האלה נצפו באופן כללי, מומלץ להעריך את ההשפעה של SMT על הביצועים בכל עומס עבודה בנפרד, כדי לקבוע את ההשפעה של הגדרת מספר השרשורים לכל ליבה כ-1.
ההגדרה הכי חסכונית לרוב עומסי העבודה של SQL Server היא להגדיר את מספר ה-threads לכל ליבה ל-1. כדי לפצות על ירידה בביצועים, אפשר להשתמש במכונה וירטואלית גדולה יותר. ברוב המקרים, הירידה של 50% בעלות הרישיון גדולה יותר מהעלייה בעלות של המכונה הווירטואלית הגדולה יותר.
דוגמה: נניח ש-SQL Server נפרס בהגדרה n2-standard-16
כברירת מחדל, מספר ליבות המעבד שמוצגות במערכת ההפעלה הוא 16, כלומר נדרשים 16 ליבות מעבד וירטואליות של Windows Server ו-16 ליבות מעבד וירטואליות של רישיונות SQL Server כדי להפעיל את השרת.
PS C:\> Get-WmiObject -Class Win32_processor | Select-Object NumberOfCores, @{Name="Thread(s) per core";Expression={$_.NumberOfLogicalProcessors/$_.NumberOfCores}}
NumberOfCores Thread(s) per core
------------- ------------------
8 2
אחרי שמבצעים את השלבים להשבתת SMT ב-SQL Server, ההגדרה החדשה היא:
PS C:\> Get-WmiObject -Class Win32_processor | Select-Object NumberOfCores, @{Name="Thread(s) per core";Expression={$_.NumberOfLogicalProcessors/$_.NumberOfCores}}
NumberOfCores Thread(s) per core
------------- ------------------
8 1
עכשיו, כשרואים רק 8 ליבות במערכת ההפעלה, השרת צריך רק 8 מעבדים וירטואליים כדי להריץ את Windows Server ואת SQL Server.