ניתוח slow query log: היכן האתר מאבד מהירות
חלק מהעמודים מגיבים לאט במידה ניכרת מאחרים: הקטלוג נפתח בשניות, כרטיס המוצר — באופן מיידי, ותחת עומס ההבדל הופך לניתוקי חיבורים. מבחוץ זה נראה כמו חוסר בכוח מחשוב, אף שהמעבד והזיכרון עמוסים בחצי — נקודת הצוואר של מסד הנתונים של האתר מסתתרת בתבנית אחת או שתיים.
ניתוח slow query log עוזר להבין את התמונה. שרת מסד הנתונים כותב לקובץ נפרד כל שאילתה שביצועה חרג מסף זמן מוגדר; הסף ואופן האיסוף נקבעים בהגדרות. בפלט — לא השערות, אלא רשימת שליפות עם תדירות הקריאות והזמן המצטבר לתקופה: היא מראה מה בדיוק מאט את הקטלוג תחת עומס.
התמונה חוזרת מפרויקט לפרויקט: שאילתות כבדות מתבררות כמעט — שליפת מוצרים עם מחירים ומלאי, חישוב מסננים, ספירת פריטים לניווט בין עמודים, הרכבת מאפיינים של הצעות מסחריות. כל אחת מהן מבוצעת בכל הצגת עמוד, ובקטלוג עם מסננים — מספר פעמים בבקשת משתמש אחת.
הסיבות בדרך כלל מבניות: אין אינדקס מורכב לתנאי המסנן, נבחרות כל העמודות במקום הנדרשות, המיון מתבצע לפי שדה ללא אינדקס, אותן שליפות חוזרות בלי מטמון ביניים.
ככל שהקטלוג גדל, הזמן של שאילתות כאלה גדל מהר יותר ממספר המוצרים, ולכן הבעיה מתפרצת בבת אחת — אחרי ייבוא או גידול עונתי בתעבורה.
שאילתות איטיות של מסד הנתונים אינן מתרפאות בהגדלת משאבים: כל עוד שליפה כבדה תלויה על כל הצגה, הכוח רק דוחה את הגבול. בהמשך נפרט כיצד היומן הופך לתיקונים — מקריאת תוכנית הביצוע ועד לבקרת התוצאה במדידה חוזרת.
מה מניב ניתוח שאילתות כבדות באתר
הניתוח מתחיל ביומן השאילתות האיטיות: בוחנים אילו פניות למסד הנתונים חורגות מהסף, באיזו תדירות הן חוזרות ומה הן קוראות — אינדקס או את כל הטבלה. לפי הנתונים הללו רואים היכן בדיוק מתבזבז הזמן: לרוב בשליפות של הקטלוג עם מסננים, בספירת מספר המוצרים ובחישוב מחדש של הנחות בסל הקניות.
התוצאה המדידה הראשונה — זמן התגובה של הקטלוג מפסיק להיות תלוי במורכבות המסנן. כאשר שליפה כבדה עוברת לאינדקס מורכב במקום סריקה מלאה, עמוד הקטגוריה מוגש בזמן יציב גם באלפי פריטים וגם בעשרות אלפים.
בהמשך — הביצועים של סל הקניות והשלמת ההזמנה. פניות מיותרות למסד הנתונים בכל שלב מוסרות או מאוחדות לשאילתה אחת, ולכן הוספת מוצר ומעבר לתשלום אינם נתקלים בהמתנה לתגובה, וחלקם של העמודים האיטיים בכלל התעבורה יורד.
בנפרד בוחנים את העומס על מסד הנתונים: תורי השאילתות מפסיקים לגדול בתעבורת שיא, משום שחלק מהעבודה מוסר על ידי אינדקסים ומטמון שליפות. יחד עם זאת נעלם סוג שלם של כשלים בגלל נעילות — טרנזקציות ההשלמה כבר אינן ממתינות לשחרור שורות, וההזמנות אינן הולכות לאיבוד בשעות המבצעים.
זו בדיוק רשימת הבדיקה שלפיה אנו מקבלים את העבודה: לפני ואחרי משווים את מספר השאילתות האיטיות ליחידת זמן, זמן התגובה של הקטלוג, את חלקם של העמודים המוגשים לזמן ארוך מהסף ואת מספר הכשלים בגלל נעילות. האצת חנות אינטרנט כאן אינה תחושה כללית, אלא ההפרש בין המספרים הללו.
דרכים לאיסוף ולניתוח של סטטיסטיקת שאילתות
סטטיסטיקה של שאילתות נאספת בשלוש דרכים, והבחירה ביניהן נעשית לפי שני קריטריונים: כמה זמן האתר יכול לסבול האטה והאם קיימת עותק מעודכן של מסד הנתונים לניסויים.
הפעלת רישום שאילתות איטיות ב-MySQL — הדרך הזולה ביותר, אך יש לה מחיר: קובץ היומן גדל במהירות, ובתעבורת שיא הרישום מוסיף תקורה לעיבוד כל שאילתה.
ניתוח היומן על עותק של האתר מסיר את הסיכון לסביבת הייצור: שם בודקים אינדקסים ובוחנים את תוכנית הביצוע לפני שמשנים משהו בשרת הפעיל. סקר חיבורים פעילים נותן תמונת מצב "כאן ועכשיו", אך אינו מראה מה התרחש ברגע שיא הלילה או בהתפרצות עומס קצרה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| יומן שאילתות איטיות בשרת הייצור | יש צורך בתמונת מצב לפי עומס אמיתי בלי סטנד נפרד | נפח הקובץ גדל, יש תקורה על הרישום, הסף נקבע באופן עיוור |
| ניתוח על עותק של האתר | יש גיבוי טרי של מסד הנתונים וזמן לניסויים | העותק מפגר בנפח הנתונים, חלק מהאנומליות אינן משוחזרות |
| סקר חיבורים פעילים | אבחון של תקלה מתמשכת ממש עכשיו | רואים רק את השאילתות הנוכחיות, התפרצויות קצרות נשארות בלתי מזוהות |
משלבים, ולא בוחרים
מתחילים בחלון רישום קצר בשרת הייצור כדי לתפוס דפוסים אמיתיים, ואחר כך מעבירים את היומן לעותק ומנתחים אותו שם. השוואה בין הגישות לאבחון מסד הנתונים נותנת תשובה לאילו שאילתות לשנות ראשונות ואיזו הטבה בזמן התגובה של העמודים זה יניב.
סדר העבודה: מאיסוף היומן ועד לבדיקת התוצאה
היומן האיטי של MySQL (slow query log) מתעד סימפטום ולא סיבה: אליו נכנסות שאילתות בודדות ארוכות מהסף שהוגדר, אך משורה אחת לא רואים — האם אין אינדקס, הסטטיסטיקה התיישנה, או שליפה כבדה נקראת מתבנית בכל עמוד.
את שלבי האופטימיזציה של מסד הנתונים בונים כך שכל צעד יצמצם את הרשימה ויסתיים בתוצאה מדידה — זהו בדיוק תוכנית העבודה להאצת האתר.
- אוספים יומן תחת עומס אמיתי — יום עבודה ועוד מרווח שיא. את הסף קובעים כך שיחסוך את הרעש ברקע ולא יאבד שאילתות נדירות אך כבדות.
- מקבצים לפי תבניות: שאילתות זהות במבנה מאחדים לסעיף אחד ומחשבים את תרומתה של כל תבנית לזמן המצטבר.
- מנתחים תוכניות ביצוע: היכן הטבלה נקראת במלואה, היכן המיון עובר דרך טבלה זמנית, היכן סדר החיבורים נבחר שלא בצורה מוצלחת.
- מכינים תיקונים: אינדקסים מורכבים לתנאים ולסדר המיון, כתיבה מחדש של השאילתה בתבנית, מטמון לשליפות חוזרות. אינדקסים מיותרים מסירים — הם מאטים את הכתיבה.
- בודקים על עותק עם אותו נפח נתונים: משווים את הזמן ואת התוכנית לפני ואחרי, ומוודאים שהשליפה מחזירה את אותן שורות.
- מעבירים במנות עם נקודת שחזור: תחילה אינדקסים, ואחר כך תיקוני תבניות — בעת רגרסיה, שחזור צעד אחד לא גורר אחריו את האחרים.
בדיקה לאחר אופטימיזציה של שאילתות
לאחר ההעברה מסירים את אותם מדדים כמו בהתחלה: זמן התגובה של העמודים המרכזיים, מספר השאילתות לעמוד וחלקן של השאילתות מעל הסף. אם המדור לא הואץ, חוזרים לתוכניות הביצוע שלו — בדרך כלל התנאי נכתב מחדש, אך האינדקס עבורו טרם נוצר.
תקנות, סכמות והגדרות: מה נשאר אצלכם
העבודה מסתיימת לא בהאצת עמוד אחד, אלא בחבילת חומרים שלפיה הצוות שלכם ממשיך הלאה בלעדינו. להלן — מה בדיוק מועבר לאחר שלב ניתוח יומן השאילתות האיטיות והתיקונים.
- דוח על נקודות הצוואר של מסד הנתונים: שאילתות כבדות עם תוכנית הביצוע, הסבר מדוע היא כזו, והערכת התרומה לתגובת העמוד הכוללת.
- שינויים בסכמה ובאינדקסים: אילו שדות, אינדקסים מורכבים וחלקיים נוספו, מדוע נבחר בדיוק סט כזה, ומאילו שאילתות ויתרו כבלתי יעילות.
- הגדרות היומן: ספי משך זמן, רוטציה של קבצים, פורמטי ניתוח — כדי ששאילתות איטיות חדשות יתועדו, והדיסק לא יתפח.
- שאילתות בקרה לבדיקה עצמית: די להריץ אותן כדי לראות אם ההידרדרות חזרה, בלי לקרוא את כל היומן.
- תקנון תחזוקה של מסד הנתונים: תדירות הבדיקה, ערכי הסף, סדר הפעולות בעת גידול בעומס לאחר עדכון.
- סדר השחזור: אילו שינויים הפיכים, היכן נמצאים צילומי המצב של המבנה וכיצד להחזיר את ההתנהגות הקודמת בצעד אחד.
- תיעוד לאחר העבודה: מפת הקשרים בין הטבלאות, רשימת קטעי הקוד ה"כבדים" ומה כדאי לכתוב מחדש באיטרציות הבאות.
חבילה כזו הופכת אופטימיזציה חד-פעמית לתהליך מנוהל: אתם רואים היכן מסד הנתונים מאט, ויודעים לבדוק זאת בעצמכם.
מקרה בוחן: הקטלוג תחת עומס לפני ואחרי האופטימיזציה
מקרה הבוחן של האצת חנות אינטרנט החל בכך שיומן השאילתות האיטיות נוהל, אך איש לא הביט בו. הקטלוג — כ-40,000 פריטים, מסנן לפי כמה עשרות מאפיינים.
לפני האופטימיזציה החציון של זמן התגובה של עמוד הקטלוג עמד על כ-2.5 שניות, וכל עמוד חמישי לא הסתיים בתוך שלוש שניות — הקונה עזב מבלי להמתין לתוצאות.
ניתוח היומן חשף שלושה מקורות. שליפת הפריטים עברה על כל הטבלה עם מיון לפי שדה ללא אינדקס; מאפייני המסנן חוברו בלי אינדקסים מורכבים, ולכן שילוב תנאים אחד הוליד עשרות פניות; ההצעות המסחריות נמשכו בשאילתה נפרדת לכל כרטיס במקום קריאה אחת באצווה.
מדדים לפני ואחרי האופטימיזציה
האופטימיזציה של שליפות הקטלוג הצטמצמה לתיקונים קונקרטיים: אינדקסים מורכבים נבנו עבור שילובי המסננים האמיתיים, סט השדות הנקראים צומצם, חיבורים מיותרים הוסרו, וההצעות המסחריות נמשכות באצווה.
הצגת העמודים הועברה לקריאה לפי טווח מפתח במקום היסט, והשליפות הכבדות נשמרו במטמון עם ביטול תוקף בעת שינוי מוצר.
לאחר התיקונים החציון של זמן התגובה של הקטלוג — כ-0.4 שניות, שיעור העמודים האיטיים ירד מ-21% ל-3%, וזמן התגובה תחת שיא הפסיק לגדול יחד עם מספר המבקרים. היומן הושאר פועל והוצמד לו סף התראה: שליפה איטית חדשה מגיעה כאות למהנדסים, ולא כתלונה של קונה. הפרויקט — על 1C-Bitrix, ולכן אותן שיטות ניתנות לחזרה בכל קטלוג של פלטפורמה זו.
במה ניתוח שאילתות שונה מאופטימיזציית קוד האתר?
ניתוח שאילתות ותיקון קוד אינם גישות מתחרות, אלא שני צעדים של אבחון אחד. תחילה יש להבין היכן מתבזבז הזמן: במסד הנתונים או בלוגיקה של היישום שפונה אליו במאות קריאות. כל עוד נקודת הצוואר אינה מאותרת, האופטימיזציה מתבצעת באקראי ולא ניתן לחזות את התוצאה.
בדרך כלל ניתן להבחין בסיבה לפי הסימפטומים. אם תרחיש מסוים מאט — קטלוג עם מסננים, מיון, ניווט בין עמודים — ושאר האתר מגיב כרגיל, הבעיה לרוב בשאילתות: שליפות כבדות בלי אינדקסים, אגרגציות על טבלאות גדולות.
כאשר האתר כולו מגיב לאט או אותם בלוקים בעמודים שונים, השורש בתבניות ובלוגיקה: שליפות חוזרות של אותה קבוצת נתונים, מטמון רכיבים מוגדר שלא כהלכה.
ניתוח שאילתות נותן עובדות: זמן הביצוע, מספר השורות שנסרקו, שיעור השליפות בלי אינדקס, קריאות חוזרות. די בכך כדי להבחין בין שאילתה כבדה אחת לבין מאות מהירות שבדרך כלל אוכלות את תגובת העמוד.
מדידות מתבצעות על תעבורת ייצור — יומן שאילתות איטיות (slow query log) ועוד פרופיל של התרחיש הבעייתי: סטנד עם מסד נתונים ריק אינו משחזר תמונה כזו.
אם השורש במסד הנתונים, תיקון הקוד אינו פותר את הבעיה, אלא רק מסווה אותה. ולהפך: כאשר כל שליפה מבוצעת באופן מיידי, אך יש מאות מהן לעמוד, אינדקסים לא יצילו — יש צורך בעיבוד מחדש של הלוגיקה והמטמון. לכן את הבחירה בין ניתוח שאילתות לתיקון קוד מכריעות המדידות, ולא ההרגל.
סדר העבודה הוא כזה: מבצעים מדידות לפי התרחיש הבעייתי, מפרידים את הזמן בין מסד הנתונים ליישום, מאשרים את ההשערה בשינוי נקודתי, ורק אחר כך מתכננים את התיקונים. בפלט — רשימת שינויים עם האפקט הצפוי לכל סעיף.
ספקות טכניים לפני תחילת העבודה
לפני ההתחלה כמעט תמיד נשאלות אותן שאלות: האם המבקרים ייפגעו מהאבחון המופעל, האם יהיה צורך לעצור את האתר ומה לעשות אם השליפות הכבדות מגיעות לא מהקוד שלנו. אנו עונים לעניין — התשובות הללו הן שקובעות כיצד אנו בונים את העבודה על 1C-Bitrix.
האם איסוף הסטטיסטיקה יאט את האתר עבור המבקרים?
לא. את יומן השאילתות האיטיות מנהל שרת מסד הנתונים עצמו, ולא היישום: התקורה היא רישום שורה לקובץ, שברירי אחוז מזמן התגובה. אנו קובעים סף שמתחתיו שאילתה אינה נכנסת ליומן — תחת מעקב נשארות רק שליפות כבדות באמת. רישום כזה מופעל ומכובה תוך כדי תנועה, בלי להפעיל מחדש את השרת ובלי לעצור את האתר.
האם יהיה צורך לעצור את האתר בזמן הניתוח?
לא. האבחון הראשוני פסיבי: אנו קוראים את היומן שכבר נצבר ואת תוכניות הביצוע של השאילתות, בלי לשנות דבר במערכת הפעילה. התיקונים מוכנסים אחד אחד — שאילתה ששונתה, אינדקס או הגדרה נבדקים תחילה על עותק של הנתונים, אחר כך על חלק קטן מהתעבורה, ומשוחזרים בפקודה אחת. אין צורך בחלון תחזוקה.
שאילתות כבדות מגיעות ממודולים של צד שלישי ומעדכונים — האם תאיצו אותן?
כן, ובדרך כלל זהו החלק הבולט ביותר ביומן. מודולים של צד שלישי, רכיבים ישנים ועדכונים שנערמו מביאים שליפות בלי אינדקסים ועם קשרים מיותרים.
קוד זר אנו לא כותבים מחדש: מוסיפים אינדקסים, מטמון והגדרות ברמת מסד הנתונים והתצורה, ואת המקומות השנויים במחלוקת מתעדים בדוח כדי שעדכון נוסף לא ימחק אותם.
נדון במשימה: ממה נתחיל ומה נדרש להתחלה
כדי שהשיחה על אופטימיזציה תהיה עניינית, יש צורך במינימום נתוני מוצא — בלעדיהם כל הערכה הופכת להשערות. אפשר לאסוף אותם מרחוק: חלק מצילומי המצב של מסד הנתונים אנו מבצעים בעצמנו אם קיימת גישה מרחוק.
מה עוזר להגיע מהר יותר לסיבות להאטה:
- גישות: פאנל האחסון או השרת בערוץ מאובטח, חשבון מנהל עם הרשאות קריאה להגדרות וליומנים.
- יומן שאילתות איטיות למרווח עם עומס שיא. אם הרישום אינו מתבצע — נסביר כיצד להפעיל אותו לכמה ימים בלי להשפיע על עבודת האתר.
- עותק של מסד הנתונים ופרמטרי השרת: מבנה הטבלאות, הנפחים, ערכי המטמון והחיבורים.
- רשימת המקומות הבעייתיים: כתובות העמודים, זמן התגובה, באילו פעולות מתרחשת האטה — קטלוג, חיפוש, השלמת הזמנה, סנכרון עם 1C.
- ציפיות לגבי עומס: מספר המבקרים המקבילים בשיא והתפרצויות מתוכננות מפרסום ודיוור.
- תקנון: מי מהצד שלכם מאשר את התיקונים ובאילו שעות מותר לבצע מדידות.
אם משהו מהרשימה חסר — אין בכך כדי לחסום את ההתחלה. תארו את המשימה בצורה חופשית: נשאל שאלות משלימות ונחזור עם הערכה, תוכנית עבודה ומדדים שלפיהם נמדוד את התוצאה לפני ואחרי התיקונים.