כן, המחשב הנייד הישן שלי חזק פי כמה משרת הייצור שלך

אלו בדיוק התלונות ששמעתי מהמפתחים שלנו. הדבר המעניין ביותר הוא שזה התברר כנכון, מה שהוליד חקירה ארוכה. נדבר על שרתי SQL שפועלים על VMware.

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

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

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

(בהערות הסתבר ששיקרתי - היו לי עמידות עיכוב בשני המקומות. ללא עמידות עיכוב מסתבר:
שולחן עבודה - 39 שניות, 15K tr/sek, 0.065ms /io הלוך ושוב
PROD - 360 שניות, 1600 tr/sek, 0.6ms
הייתי צריך לשים לב שזה היה מהיר מדי)

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

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
GO

אם הכל בסדר, בדיקת ראשוניותו של מספר תיקח 6-7-8 שניות. זה קרה במספר שרתים. אבל בחלק מהבדיקה נמשכה 25-40 שניות. מעניין לציין שלא היו שרתים שבהם הביצוע היה לוקח, נניח, 14 שניות - הקוד עבד או מהר מאוד או לאט מאוד, כלומר, הבעיה הייתה, נניח, שחור ולבן.

מה אני עשיתי? השתמשו במדדי VMware. הכל היה בסדר שם - היה שפע של משאבים, זמן מוכן = 0, היה מספיק מהכל, במהלך הבדיקה על שרתים מהירים ואיטיים כאחד. CPU = 100 ב-vCPU אחד. עשיתי מבחן לחישוב המספר Pi - הבדיקה הראתה את אותן תוצאות בכל שרת. ריח הקסם השחור נעשה חזק יותר ויותר.

ברגע שהגעתי לחוות ה-DEV, התחלתי לשחק עם השרתים. התברר ש-vMotion מארח למארח יכולה "לרפא" שרת, אבל היא גם יכולה להפוך שרת "מהיר" לשרת "איטי". נראה שזהו - לחלק מהמארחים יש בעיה... אבל... לא. איזו מכונה וירטואלית הייתה איטית על מארח, נגיד A, אבל עבדה מהר על מארח B. ומכונה וירטואלית אחרת, להיפך, עבדה מהר על A והאטה על B! גם מכונות "מהירות" וגם מכונות "איטיות" הסתובבו לעתים קרובות על המארח!

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

מתוך ייאוש, הפעלתי את Process Explorer מ-Sysinternals והסתכלתי על מחסנית ה-SQL. במכונות איטיות הקו מיד תפס את עיני:

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
... דילג
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

זה כבר היה משהו. התוכנית נכתבה:

    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);
                }
            }
        }
    }

תוכנית זו הפגינה האטה בולטת עוד יותר - במכונות "מהירות" היא מציגה 16-18 מיליון מחזורים בשנייה, בעוד שבמכונות איטיות היא מציגה מיליון וחצי, או אפילו 700 אלף. כלומר, ההבדל הוא פי 10-20 (!!!). זה כבר היה ניצחון קטן: בכל מקרה, לא היה איום להיתקע בין תמיכת מיקרוסופט ל-VMware כדי שהן יפנו חיצים זה על זה.

ואז נעצרה ההתקדמות - חופשות, עניינים חשובים, היסטריה ויראלית ועלייה חדה בעומס העבודה. לא פעם הזכרתי את בעיית הקסם לעמיתיי, אבל לפעמים נראה שהם אפילו לא תמיד האמינו לי - האמירה ש-VMware מאטה את הקוד פי 10-20 הייתה מפלצתית מדי.

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

לבסוף, עמיתיי האמריקאים מצאו לפתע את הסיבה.

המארחים היו שונים בתדירות!

• ככלל, זה לא עניין גדול. אבל: כאשר עוברים ממארח ​​'מקורי' למארח עם תדר 'שונה', VMware חייבת להתאים את תוצאת GetTimePrecise.
• ככלל, זו לא בעיה, אלא אם כן יש אפליקציה שמבקשת את הזמן המדויק מיליוני פעמים בשנייה, כמו שרת SQL.
• אבל זה לא מפחיד, מכיוון ששרת SQL לא תמיד עושה זאת (ראה מסקנה)

אבל יש מקרים שבהם הגריפה הזו מכה חזק. ובכל זאת, כן, על ידי הקשה על ההגה (על ידי שינוי משהו בהגדרות ה-VM) הכרחתי את VMware 'לחשב מחדש' את התצורה, והתדר של המארח הנוכחי הפך לתדר 'המקורי' של המכונה.

החלטה

www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf

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

בקיצור, צריך להוסיף את הפרמטר

monitor_control.virtual_rdtsc = FALSE

מסקנה

בטח יש לך שאלה: מדוע SQL מתקשר ל-GetTimePrecise לעתים קרובות כל כך?

אין לי את קוד המקור של שרת SQL, אבל ההיגיון אומר את זה. SQL היא כמעט מערכת הפעלה עם שיתוף פעולה במקביל, שבה כל חוט חייב "להיכנע" מעת לעת. איפה הכי טוב לעשות את זה? איפה שיש המתנה טבעית - מנעול או IO. אוקיי, אבל מה אם אנחנו מסובבים לולאות חישוביות? ואז המקום המובן מאליו וכמעט היחיד הוא בפרשן (זה לא באמת מתורגמן), לאחר ביצוע ההצהרה הבאה.

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

אגב, אם עוטפים את הפונקציה ב-NATIVELY COMPILED, אז היא מפסיקה לבקש זמן, והמהירות שלה עולה פי 10. מה לגבי ריבוי משימות שיתופית? אבל עבור קוד מקורי היינו צריכים לעשות MULTITASKING PREEMPTIVE ב-SQL.

מקור: www.habr.com