למה בסיס הנתונים שלי זז לאט פתאום? 

מאת גיא גלנצר, Madeira Data Solutions, שותף אזטק ל- SQL ו- BI

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

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

יכולות להיות לזה כל מיני סיבות, כמובן, אבל אני מדבר על סיבה ספציפית שנעוצה באופן שבו SQL Server עובד. הרשו לי להסביר…

כל פעולה במערכת שצריכה לקרוא או לעדכן נתונים מתורגמת לשאילתה מול בסיס הנתונים. לכל שאילתה, SQL Server צריך לייצר תוכנית ביצוע (Execution Plan). התוכנית הזאת אומרת ל-SQL Server איך לבצע את השאילתה בצורה הטובה ביותר. יש המון אפשרויות והמון שיקולים – באיזה סדר לגשת לטבלאות, באיזה אינדקסים להשתמש, איך לבצע את ה-Join בין הטבלאות, ועוד.

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

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

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

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

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

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *