שיטות מומלצות למופעים של SQL Server

אפשר ליישם כמה שיטות מומלצות כדי לבצע אופטימיזציה של מכונות Compute Engine שמריצות Microsoft SQL Server. כדי ללמוד איך להגדיר מכונה של SQL Server עם ביצועים גבוהים, אפשר לקרוא את המאמר יצירת מכונה של SQL Server עם ביצועים גבוהים.

שימוש בכלי לניהול עומס עבודה כדי להעריך ולפרוס את SQL Server

הערכת SQL Server ב-כלי לניהול עומס העבודה מאפשרת לסרוק את פריסות SQL Server עם קבוצה של המלצות מוגדרות מראש Cloud de Confiance by S3NS לביצועים אופטימליים ישירות מהמסוףCloud de Confiance . מידע נוסף זמין במאמר הוראות להגדרת סוכן ל-SQL Server.

הכלי Guided Deployment Automation ב-כלי לניהול עומס העבודה מאפשר להגדיר ולפרוס אפליקציות ארגוניות ב- Cloud de Confiance by S3NS. אפשר גם להשתמש באוטומציה מודרכת של פריסה כדי להגדיר פריסה של עומס העבודה, ואז ליצור תשתית 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, מכונות מחשוב מצורפות לרשת שתוכננה על ידי Google ומציעה קיבולת וביצועים גבוהים. השרתים הפיזיים שמריצים את המכונות של Compute Engine מותאמים במיוחד כדי לנצל את קיבולת הרשת הזו. גם מנהלי ההתקנים של הרשת הווירטואלית במופעים שלכם עוברים אופטימיזציה, ולכן ערכי ברירת המחדל מספיקים לרוב תרחישי השימוש.

התקנת אנטי-וירוס

שיטה מומלצת: כדאי לפעול לפי ההנחיות של מיקרוסופט לגבי תוכנות אנטי-וירוס.

אם אתם משתמשים ב-Windows, כדאי להפעיל תוכנת אנטי-וירוס. תוכנות זדוניות ווירוסים בתוכנה מהווים סיכון משמעותי לכל מערכת שמחוברת לרשת, ותוכנת אנטי-וירוס היא אמצעי פשוט שאפשר להשתמש בו כדי להגן על הנתונים. עם זאת, אם תוכנת האנטי-וירוס לא מוגדרת בצורה נכונה, היא עלולה לפגוע בביצועים של מסד הנתונים. Microsoft מספקת עצות לגבי בחירת תוכנת אנטי-וירוס.

אופטימיזציה לפי ביצועים ויציבות

בקטע הזה מוסבר איך לייעל את הביצועים של SQL Server ב-Compute Engine, ומתוארות פעולות תפעוליות שיעזרו לכם לשמור על פעולה חלקה.

העברת קובצי נתונים וקובצי יומן לדיסק חדש

שיטה מומלצת: כדאי להשתמש בדיסק מתמיד שמבוסס על SSD נפרד לקובצי יומן ונתונים.

כברירת מחדל, קובץ האימג' שהוגדר מראש ל-SQL Server מגיע עם כל מה שמותקן בדיסק האתחול הקבוע, שמוטען ככונן 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 לא בהכרח מצביעה על כך שצריך לשנות את ההגדרה הזו, זה מקום טוב להתחיל בו.

שיטה מומלצת: כדאי לעקוב אחרי סוגים שונים של המתנה, ולשנות את ההגדרות הגלובליות של עיבוד מקביל או להגדיר אותן ברמת מסד הנתונים הספציפי.

יכול להיות שלכל מסד נתונים יהיו צרכים שונים של מקביליות. אפשר להגדיר את ההגדרות האלה באופן גלובלי, ולהגדיר את Max DOP ברמת מסד הנתונים הספציפי. כדאי לבחון את עומסי העבודה הייחודיים, לעקוב אחרי זמני ההמתנה ואז לשנות את הערכים בהתאם.

באתר SQLSkills יש מדריך שימושי לשיפור הביצועים, שכולל נתונים סטטיסטיים על זמן ההמתנה במסד הנתונים. המדריך הזה יעזור לכם להבין מה גורם לעיכובים ואיך אפשר לצמצם אותם.

טיפול ביומני טרנזקציות

שיטה מומלצת: כדאי לעקוב אחרי הגידול ביומן העסקאות במערכת. כדאי להשבית את הגידול האוטומטי ולהגדיר את קובץ היומן לגודל קבוע, על סמך הצטברות היומן היומית הממוצעת.

אחד המקורות שהכי קל לפספס כשמנסים להבין למה הביצועים יורדים או למה יש האטה לסירוגין הוא הגידול הלא מנוהל של יומן העסקאות. אם מסד הנתונים מוגדר לשימוש במודל השחזור Full, אפשר לבצע שחזור לכל נקודת זמן, אבל יומני העסקאות מתמלאים מהר יותר. כברירת מחדל, כשקובץ יומן העסקאות מלא, SQL Server מגדיל את גודל הקובץ כדי להוסיף עוד מקום ריק לכתיבת עסקאות נוספות, וחוסם את כל הפעילות במסד הנתונים עד לסיום הפעולה. גודל כל קובץ יומן ב-SQL Server גדל בהתאם לגודל הקובץ המקסימלי ולהגדרה של גידול הקובץ.

כשהקובץ מגיע למגבלת הגודל המקסימלית שלו ולא יכול לגדול יותר, המערכת מציגה שגיאה 9002 ומעבירה את מסד הנתונים למצב קריאה בלבד. אם הקובץ יכול לגדול, SQL Server מגדיל את גודל הקובץ ומאפס את השטח הריק. ההגדרה של File Growth (גידול הקובץ) מוגדרת כברירת מחדל ל-10% מהגודל הנוכחי של קובץ היומן. זו לא הגדרת ברירת מחדל טובה לביצועים, כי ככל שהקובץ גדל, לוקח יותר זמן ליצור את המקום החדש והריק.

שיטה מומלצת: כדאי לתזמן גיבויים קבועים של יומן העסקאות.

בלי קשר להגדרות הגודל המקסימלי והגידול, כדאי לתזמן גיבויים קבועים של יומן העסקאות. כברירת מחדל, הגיבויים האלה חותכים רשומות ישנות ביומן ומאפשרים למערכת לעשות שימוש חוזר במקום בקובץ הקיים. משימת התחזוקה הפשוטה הזו יכולה לעזור לכם להימנע מירידה בביצועים בשעות העומס.

אופטימיזציה של קובצי יומן וירטואליים

שיטה מומלצת: כדאי לעקוב אחרי הגידול של קובץ היומן הווירטואלי ולנקוט פעולות כדי למנוע פיצול של קובץ היומן.

קובץ יומן הטרנזקציות הפיזי מפולח לקובצי יומן וירטואליים (VLF). קבצים חדשים של יומן טרנזקציות וירטואלי (VLF) נוצרים בכל פעם שקובץ יומן הטרנזקציות הפיזי צריך לגדול. אם לא השבתתם את הגידול האוטומטי, והגידול מתרחש בתדירות גבוהה מדי, נוצרים יותר מדי קבצים וירטואליים של יומנים. הפעילות הזו עלולה לגרום לפיצול של קובץ היומן, בדומה לפיצול של הדיסק, וזה עלול לפגוע בביצועים.

ב-SQL Server 2014 הוצג אלגוריתם יעיל יותר לקביעת מספר ה-VLFs שצריך ליצור במהלך הגדלה אוטומטית. בדרך כלל, אם הגידול קטן מ-1/8 מגודל קובץ היומן הנוכחי, SQL Server יוצר VLF אחד בקטע החדש הזה. בעבר, המערכת הייתה יוצרת 8 קובצי VLF לצמיחה בין 64MB ל-1GB, ו-16 קובצי VLF לצמיחה מעל 1GB. אפשר להשתמש בסקריפט 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 ומספר אפשרויות שחזור בתרחישים שונים.
  • חלונית מרכזית לניהול, כולל יכולות ייעודיות למעקב, להתראות ולדיווח על כל הגיבויים.

למידע נוסף:

מעקב אחרי נתונים

שיטה מומלצת: שימוש ב-Cloud Monitoring.

אתם יכולים להתקין את סוכן Cloud Monitoring עבור Microsoft Windows כדי לשלוח כמה נקודות נתונים של מעקב למערכת Cloud Monitoring.

באמצעות יכולות איסוף הנתונים, תוכלו לכוונן את המידע שאתם רוצים לעקוב אחריו ולשלוח אותו אל מחסן הנתונים המובנה לניהול. אפשר להריץ את מחסן הנתונים לניהול באותו שרת שאתם מנטרים, או להזרים את הנתונים למופע אחר של SQL Server שמריץ את מחסן הנתונים.

טעינת נתונים בכמות גדולה

שיטה מומלצת: כדאי להשתמש במסד נתונים נפרד כדי להכין ולשנות נתונים בכמות גדולה לפני שמעבירים אותם לשרתי הייצור.

סביר להניח שתצטרכו לטעון כמויות גדולות של נתונים למערכת לפחות פעם אחת, ואולי באופן קבוע. זו פעולה שדורשת הרבה משאבים, ויכול להיות שתגיעו למגבלת ה-IOPS של דיסק קשיח מתמשך כשמבצעים העלאות בכמות גדולה.

אתם יכולים להפחית את צריכת הקלט/פלט בדיסק ואת צריכת ה-CPU של פעולות טעינה בכמות גדולה, וגם לקצר את זמן הביצוע של עבודות אצווה. כדי לעשות את זה, יוצרים מסד נתונים נפרד לחלוטין שמשתמש במודל השחזור Simple, ואז משתמשים במסד הנתונים הזה כדי להכין את מערך הנתונים הגדול ולהמיר אותו לפני שמוסיפים אותו למסד הנתונים של הייצור. אפשר גם לשמור את מסד הנתונים החדש בכונן SSD מקומי, אם יש לכם מספיק מקום. שימוש ב-SSD מקומי למסד הנתונים של השחזור מפחית את צריכת המשאבים של הפעולות בכמות גדולה ואת הזמן שנדרש להשלמת המשימות. היתרון האחרון הוא שעבודת הגיבוי של נתוני הייצור לא תצטרך לגבות את כל הפעולות האלה בכמות גדולה ביומן העסקאות, ולכן היא תהיה קטנה יותר ותפעל מהר יותר.

אימות ההגדרה

שיטה מומלצת: כדאי לבדוק את ההגדרה כדי לוודא שהיא פועלת כמצופה.

בכל פעם שמגדירים מערכת חדשה, מומלץ לתכנן את אימות ההגדרה ולהריץ כמה בדיקות ביצועים. הפרוצדורה המאוחסנת הזו היא משאב מצוין להערכת ההגדרה של SQL Server. אפשר לקרוא על דגלי ההגדרה ולבצע את התהליך מאוחר יותר.

אופטימיזציה של SQL Server Enterprise Edition

למהדורת SQL Server Enterprise יש רשימה ארוכה של יכולות נוספות בהשוואה למהדורת Standard. אם אתם מעבירים רישיון קיים אלCloud de Confiance, יש כמה אפשרויות לשיפור הביצועים שכדאי לכם לשקול להטמיע.

שימוש בטבלאות דחוסות

שיטה מומלצת: הפעילו דחיסה של טבלאות ואינדקסים.

יכול להיות שזה נראה לא הגיוני שדחיסת טבלאות יכולה לשפר את הביצועים של המערכת, אבל ברוב המקרים זה מה שקורה. הפשרה היא שימוש בכמות קטנה של מחזורי CPU כדי לדחוס את הנתונים ולבטל את קלט/פלט הדיסק הנוסף שנדרש לקריאה ולכתיבה של הבלוקים הגדולים יותר. באופן כללי, ככל שהמערכת משתמשת בפחות קלט/פלט של דיסק, כך הביצועים שלה טובים יותר. הוראות להערכה ולהפעלה של דחיסת טבלאות ואינדקסים זמינות באתר MSDN.

הפעלת הרחבת מאגר הנתונים הזמני

שיטה מומלצת: כדאי להשתמש בתוסף של מאגר הנתונים הזמני כדי להאיץ את הגישה לנתונים.

מאגר הנתונים הזמני הוא המקום שבו המערכת מאחסנת דפים נקיים. במילים פשוטות, הוא מאחסן עותקים של הנתונים שלכם, שמשקפים את מה שמופיע בדיסק. כשנתונים משתנים בזיכרון, הדף נקרא דף לא נקי. צריך לרוקן דפים עם נתונים מלוכלכים לדיסק כדי לשמור את השינויים. אם מסד הנתונים גדול יותר מהזיכרון הזמין, עומס על מאגר הנתונים הזמני עלול לגרום להשמטה של דפים נקיים. כשדפים נקיים מושלכים, המערכת צריכה לקרוא מהדיסק בפעם הבאה שהיא ניגשת לנתונים שהושלכו.

התכונה 'הרחבת מאגר הנתונים הזמני' מאפשרת להעביר דפים נקיים ל-SSD מקומי במקום להשליך אותם. השיטה הזו דומה לזיכרון וירטואלי, כלומר היא מבוססת על החלפה, ומאפשרת לכם לגשת לדפים הנקיים ב-SSD המקומי, שהוא מהיר יותר מהדיסק הרגיל שבו מאוחסנים הנתונים.

הטכניקה הזו לא מהירה כמו שיש מספיק זיכרון, אבל היא יכולה להגדיל את קצב העברת הנתונים בצורה מתונה כשאין הרבה זיכרון פנוי. באתר של ברנט אוזר אפשר לקרוא מידע נוסף על הרחבות של מאגר הנתונים הזמני ולעיין בתוצאות של בדיקות השוואה.

אופטימיזציה של עלויות הרישוי של SQL Server

כדי להפחית את עלויות הרישוי, צריך להקטין את מספר ליבות ה-vCPU שבהן נעשה שימוש במופע. אפשר להתאים אישית את מספר ליבות המעבד שגלויות או להשבית את SMT עבור המופע.

השבתת ריבוי נימים סימולטני (SMT)

שיטה מומלצת: מגדירים את מספר ה-threads לכל ליבה ל-1 עבור רוב עומסי העבודה של SQL Server

‫Simultaneous multithreading (‏SMT), שנקרא בדרך כלל Hyper-Threading Technology (‏HTT) במעבדי Intel, הוא תכונה שמאפשרת לשתף באופן לוגי ליבת CPU אחת כשני שרשורים. ב-Compute Engine,‏ SMT מופעל ברוב מכונות החישוב כברירת מחדל, מה שאומר שכל vCPU במכונה פועל בשרשור יחיד, וכל ליבה פיזית של CPU משותפת לשני vCPU.

ב-Compute Engine, אפשר להגדיר את מספר השרשורים לכל ליבה, וכך למעשה להשבית את SMT. כשמספר השרשורים לכל ליבה מוגדר ל-1, מעבדים וירטואליים לא חולקים ליבות פיזיות של מעבד. להגדרה הזו יש השפעה משמעותית על עלויות הרישוי של Windows Server ו-SQL Server. כשמספר השרשורים לכל ליבה מוגדר ל-1, מספר המעבדים הווירטואליים במופע של Compute Engine מצטמצם בחצי, וכך גם מספר הרישיונות ל-Windows Server ול-SQL Server שנדרשים. הפעולה הזו יכולה להפחית באופן משמעותי את העלות הכוללת של עומס העבודה.

עם זאת, הגדרת מספר השרשורים לכל ליבה משפיעה גם על ביצועי עומס העבודה. אפליקציות שנכתבו כך שהן יכולות להשתמש בכמה תהליכים יכולות לנצל את התכונה הזו על ידי חלוקת עבודת המחשוב לחלקים קטנים יותר שאפשר להריץ במקביל, שמתבצעת תזמון שלהם בכמה ליבות לוגיות. ההקבלה הזו של העבודה בדרך כלל מגדילה את התפוקה הכוללת של המערכת, כי היא מאפשרת ניצול טוב יותר של משאבי הליבה הזמינים. לדוגמה, אם תהליך אחד נתקע, התהליך השני יכול להשתמש בליבה.

ההשפעה המדויקת של SMT על SQL Server תלויה במאפייני עומס העבודה ובפלטפורמת החומרה שבה נעשה שימוש, כי ההטמעה של SMT שונה בין דורות החומרה. עומסי עבודה עם נפח גבוה של טרנזקציות קטנות, למשל עומסי עבודה של OLTP, יכולים לרוב להפיק תועלת מ-SMT וליהנות משיפור גדול יותר בביצועים. לעומת זאת, עומסי עבודה שניתן להקביל אותם פחות, למשל עומסי עבודה של OLAP, מפיקים פחות תועלת מ-SMT. למרות שהדפוסים האלה נצפו באופן כללי, כדאי להעריך את השפעת ה-SMT על הביצועים לפי עומס עבודה, כדי לקבוע את ההשפעה של הגדרת מספר השרשורים לכל ליבה כ-1.

ההגדרה הכי חסכונית לרוב עומסי העבודה של SQL Server היא להגדיר את מספר השרשורים לכל ליבה כ-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.

הפחתת מספר הליבות שגלויות

שיטה מומלצת: כדאי להתאים אישית את מספר ליבות ה-CPU שגלויות כדי לנהל את עלויות הרישוי של SQL Server.

בנוסף להשבתת SMT, אפשר להתאים אישית את מספר ליבות ה-CPU שגלויות במופע החישוב. כברירת מחדל, מופעים של Compute מציגים למערכת ההפעלה את כל ליבות ה-vCPU הזמינות. אם מציינים מספר מותאם אישית של ליבות גלויות, מערכת ההפעלה רואה רק את הליבות שמציינים. ההגדרה הזו מצמצמת את מספר הרישיונות הנדרשים ל-SQL Server, כי צריך רישיונות רק עבור הליבות הגלויות.

אם אתם מתאימים אישית את הליבות הגלויות, אתם יכולים לבצע אופטימיזציה של עלויות הרישוי בלי לשנות את סוג המכונה. התכונה הזו שימושית אם נפח העבודה שלכם דורש כמות מסוימת של זיכרון, אבל לא צריך את כל ליבות ה-vCPU שכלולות בסוג המכונה.

מידע נוסף זמין במאמר בנושא התאמה אישית של ליבות גלויות.

המאמרים הבאים