שגיאות אופייניות ביישומים שמובילות לנפיחות ב-postgresql. אנדריי סלניקוב

אני מציע לך לקרוא את תמליל הדו"ח מתחילת 2016 מאת אנדריי סלניקוב "טעויות אופייניות ביישומים שמובילים לנפיחות ב-postgresql"

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

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

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

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

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

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

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

ובמצב הזה אנחנו רואים שבאמת יש לנו שלט קטן. האינדקס קטן ב-2 מגה-בייט. זהו הגרף הראשון משמאל.

גם זמן התגובה הממוצע בשרת יציב וקצר. זהו הגרף הימני העליון.

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

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

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

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

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

לאן דברים כאלה מובילים?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה קרה במהלך התאונה? איך התהליך הזה קרה שם?

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

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

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

וכאשר אנו מבצעים שאילתה, בסיס הנתונים צריך לעבור על כל השורות: גם אדום וגם ירוק, כדי למצוא את השורה הרצויה. וההשפעה של התנפחות טבלה עם נתונים חסרי תועלת נקראת "נפיחות", שגם גוזלת את שטח הדיסק שלנו. זוכרים, זה היה 2 מגה-בייט, זה הפך ל-300 מגה-בייט? כעת שנה מגה-בייט לג'יגה-בייט ותאבד במהירות את כל משאבי הדיסק שלך.

אילו השלכות עלולות להיות לנו?

• בדוגמה שלי, הטבלה והאינדקס גדלו פי 150. לחלק מהלקוחות שלנו היו מקרים קטלניים יותר כשהם פשוט התחילו להיגמר שטח הדיסק.
• גודל השולחנות עצמם לעולם לא יקטן. ואקום אוטומטי במקרים מסוימים יכול לחתוך את זנבו של השולחן אם יש רק דד-ליין. אבל מכיוון שיש סיבוב קבוע, קו ירוק אחד עלול לקפוא בסוף ולא להתעדכן, בעוד שכל השאר יירשמו איפשהו בתחילת הצלחת. אבל זה אירוע כל כך לא סביר שהשולחן שלך עצמו יתכווץ בגודלו, אז אתה לא צריך לקוות לזה.
• מסד הנתונים צריך למיין חבורה שלמה של שורות חסרות תועלת. ואנחנו מבזבזים משאבי דיסקים, אנחנו מבזבזים משאבי מעבד וחשמל.
• וזה משפיע ישירות על האפליקציה שלנו, כי אם בהתחלה בילינו 10 מילישניות על הבקשה, 10 מילישניות על הקוד שלנו, אז במהלך הקריסה התחלנו לבזבז שנייה על הבקשה ו-10 מילישניות על הקוד, כלומר הזמנה של היקף ביצועי האפליקציה ירד. וכשהתאונה נפתרה, התחלנו לבזבז 20 מילישניות על בקשה, 10 מילישניות על קוד. זה אומר שעדיין ירדנו פי אחד וחצי בתפוקה. וכל זה בגלל עסקה אחת שקפאה, אולי באשמתנו.
• והשאלה: "איך אפשר להחזיר הכל?" כדי שהכל יהיה בסדר אצלנו והבקשות יגיעו מהר כמו לפני התאונה.

לשם כך ישנו מחזור עבודה מסוים שמתבצע.

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

לאחר שמצאת את הטבלאות הללו, עליך לדחוס אותן. יש כבר כלים לזה. בחברתנו אנו משתמשים בשלושה כלים. הראשון הוא ה-VACUUM FULL המובנה. הוא אכזרי, קשוח וחסר רחמים, אבל לפעמים הוא מאוד שימושי. Pg_repack и pgcompacttable - אלו הם כלי עזר של צד שלישי לדחיסת טבלאות. והם מתייחסים למסד הנתונים בזהירות רבה יותר.

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

לאחר שתיקנו הכל ווידאנו שהכל בסדר, עלינו לדעת כיצד למנוע את המצב הזה בעתיד:

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

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

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

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

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

הסיפור השני, בו אנו מפיצים את העומס ומייעלים את משאבי השרת

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

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

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

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

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

אנחנו נכנסים לאינטרנט ומתחילים לקרוא למה זה קורה. ואנחנו מוצאים פתרון.

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

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

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

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

איך זה ייראה אם ​​לא נדע על מה דיברתי קודם?

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

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

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

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

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

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

• האם אינך מאפשר משוב_המתנה_חם? כן, לא מומלץ להפעיל אותו ללא סיבות חזקות במיוחד. כי הטוויסט הזה משפיע ישירות על שרת המאסטר ומשהה את פעולת השואב האוטומטי שם. על ידי הפעלתו בהעתק כלשהו ושכחה ממנו, תוכלו להרוג את המאסטר ולקבל בעיות גדולות עם האפליקציה.
• להגדיל את max_standby_streaming_delay? כן, לגבי דיווחים זה נכון. אם יש לך דוח של שלוש שעות ואתה לא רוצה שהוא יקרוס בגלל התנגשויות שכפול, אז פשוט הגביר את העיכוב. דוח לטווח ארוך אף פעם לא מצריך נתונים שהגיעו למאגר עכשיו. אם יש לך את זה לשלוש שעות, אז אתה מפעיל את זה לתקופת נתונים ישנה. ומבחינתכם, אם יש איחור של שלוש שעות או איחור של שש שעות לא יעשה שום הבדל, אבל תקבלו דוחות באופן עקבי ולא תהיה לכם בעיה עם נפילה.
• באופן טבעי, אתה צריך לשלוט בהפעלות ארוכות על העתקים, במיוחד אם אתה מחליט לאפשר משוב חם_המתנה על עותק. כי הכל יכול לקרות. נתנו את העתק הזה למפתח כדי שיוכל לבדוק את הבקשות. הוא כתב בקשה מטורפת. הוא השיק אותו ויצא לשתות תה, וקיבלנו את המאסטר שהוקם. או אולי שמנו שם את האפליקציה הלא נכונה. המצבים מגוונים. יש לפקח בקפידה על הפעלות על העתקים כמו על המאסטר.
• ואם יש לך שאילתות מהירות וארוכות על העתקים, אז במקרה זה עדיף לפצל אותם כדי לפזר את העומס. זהו קישור ל-streaming_delay. עבור אלה מהירים, יש העתק אחד עם עיכוב שכפול קטן. עבור בקשות דיווח ארוכות טווח, יש עותק שיכול לפגר ב-6 שעות או ביום. זהו מצב נורמלי לחלוטין.

אנו מבטלים את ההשלכות באותו אופן:

• אנחנו מוצאים שולחנות נפוחים.
• ואנחנו דוחסים אותו עם הכלי הכי נוח שמתאים לנו.

הסיפור השני מסתיים כאן. נעבור לסיפור השלישי.

גם די נפוץ אצלנו בו אנחנו עושים הגירה.

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

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

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

ביצענו את ההגירה ושוב נתקלנו בבעיות.

ההעברה הצליחה, אבל:

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

וזו שוב נפיחות, ששוב הורסת את חיינו.

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

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

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

• הגירות כה גדולות אינן מתרחשות אוטומטית. הם חייבים להיות תמיד בשליטה.
• נדרשת השגחה של אדם בעל ידע. אם יש לך DBA בצוות שלך, אז תן ל-DBA לעשות את זה. זה העבודה שלו. אם לא, אז תנו לאדם המנוסה ביותר לעשות זאת, שיודע לעבוד עם מסדי נתונים.
• סכימת מסד נתונים חדשה, גם אם נעדכן עמודה אחת, אנו תמיד מתכוננים בשלבים, כלומר מראש לפני יציאת הגרסה החדשה של האפליקציה:
• מתווספים שדות חדשים בהם נרשום את הנתונים המעודכנים.
• אנו מעבירים נתונים מהשדה הישן לשדה החדש בחלקים קטנים. למה אנחנו עושים את זה? ראשית, אנו תמיד שולטים בתהליך של תהליך זה. אנחנו יודעים שכבר העברנו כל כך הרבה אצוות ונשארו לנו כל כך הרבה.
• והאפקט החיובי השני הוא שבין כל אצווה כזו אנחנו סוגרים את העסקה, פותחים אחת חדשה, וזה מאפשר לשאוב האוטומטי לעבוד לפי הלוח, לסמן דד-ליין לשימוש חוזר.
• עבור השורות שיופיעו בזמן שהאפליקציה פועלת (עדיין פועלת האפליקציה הישנה), אנו מוסיפים טריגר שכותב ערכים חדשים לשדות חדשים. במקרה שלנו, מדובר בכפל במאה מהערך הישן.
• אם אנחנו עקשנים לחלוטין ורוצים את אותו שדה, אז עם השלמת כל ההגירות ולפני פרסום גרסה חדשה של האפליקציה, אנחנו פשוט משנים את שמות השדות. הישנים מקבלים שם מומצא כלשהו, ​​והשדות החדשים משתנים לישנים.
• ורק לאחר מכן אנו משיקים גרסה חדשה של האפליקציה.

ויחד עם זאת לא נקבל נפיחות ולא נסבול מבחינת ביצועים.

כאן מסתיים הסיפור השלישי.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

ועכשיו קצת יותר פירוט על הכלים שהזכרתי בסיפור הראשון.

לפני חיפוש bloat, עליך להתקין את התוסף pgstattuple.

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

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

הבנו איך לזהות טבלאות נפוחות עם נתונים חסרי תועלת.

עכשיו לגבי איך לתקן נפיחות:

• אם יש לנו טאבלט קטן ודיסקים טובים, כלומר בטאבלט עד גיגה-בייט, בהחלט אפשרי להשתמש ב-VACUUM FULL. הוא ייקח ממך מנעול בלעדי על השולחן לכמה שניות וזה בסדר, אבל הוא יעשה הכל במהירות ובחומרה. מה עושה ואקום מלא? זה לוקח מנעול בלעדי על השולחן ומשכתב שורות חיות מהשולחנות הישנים לטבלה החדשה. ובסוף הוא מחליף אותם. זה מוחק קבצים ישנים ומחליף את הישנים בחדשים. אבל במשך כל עבודתו, הוא לוקח מנעול בלעדי על השולחן. משמעות הדבר היא שאינך יכול לעשות דבר עם הטבלה הזו: לא לכתוב אליה, לא לקרוא לתוכה, ולא לשנות אותה. ו-VACUUM FULL דורש שטח דיסק נוסף כדי לכתוב נתונים.
• הכלי הבא pg_repack. בעקרון שלו הוא דומה מאוד ל-VACUUM FULL, מכיוון שהוא גם משכתב נתונים מקבצים ישנים לחדשים ומחליף אותם בטבלה. אבל יחד עם זאת, הוא לא לוקח מנעול בלעדי על השולחן ממש בתחילת עבודתו, אלא לוקח אותו רק ברגע שבו כבר יש לו נתונים מוכנים על מנת להחליף את הקבצים. דרישות משאבי הדיסק שלו דומות לאלו של VACUUM FULL. אתה צריך שטח דיסק נוסף, וזה לפעמים קריטי אם יש לך טבלאות טרה-בייט. והוא די רעב למעבד מכיוון שהוא עובד באופן פעיל עם I/O.
• כלי השירות השלישי הוא pgcompacttable. זה יותר זהיר עם משאבים כי זה עובד על פי עקרונות קצת שונים. הרעיון המרכזי של pgcompacttable הוא שהוא מעביר את כל השורות החיות לתחילת הטבלה באמצעות עדכונים בטבלה. ואז זה מפעיל ואקום על השולחן הזה, כי אנחנו יודעים שיש לנו שורות חיות בהתחלה ושורות מתות בסוף. והוואקום עצמו מנתק את הזנב הזה, כלומר הוא לא דורש הרבה שטח דיסק נוסף. ויחד עם זאת, זה עדיין יכול להיסחט מבחינת משאבים.

הכל עם כלים.

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

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - זה דיווח של עמיתי. זה כללי לאן הולך החלל של Postgres במהלך עבודתו וחייו. ויש קטע טכני גדול ומפורט מאוד למנהלי מסדי נתונים על bloat.
• https://github.com/dataegret/pg-utils - זהו קישור למאגר שלנו, שבו אנו מאחסנים חבורה של סקריפטים שימושיים לבדיקת מצב מסד הנתונים. שם אתה יכול למצוא סקריפטים לחיפוש נפיחות.
• Третья и רביעי קישורים לכלים שיעזרו לך לכווץ סימנים.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - זה פוסט של עמיתי. שם הוא די ברצינות וטכנית מנתח נפיחות בפירוט ברמה הקרובה למנהלים.

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

שאלות

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

במקרה זה, מדובר במשימה למנהלי החברה שלך, לאו דווקא ל-DBA.

אני מנהל.

ל-PostgreSQL יש תצוגה בשם pg_stat_activity המציגה שאילתות משתלשלות. ואתה יכול לראות כמה זמן זה תלוי שם.

האם אני צריך להיכנס ולהסתכל כל 5 דקות?

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

האם יש סיבות ברורות למה זה קורה?

רשמתי כמה. עוד דוגמאות מורכבות יותר. ויכולה להיות שיחה לאורך זמן.

תודה על הדיווח! רציתי להבהיר לגבי כלי השירות pg_repack. אם היא לא עושה מנעול בלעדי, אז...

היא עושה מנעול בלעדי.

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

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

כלומר, הוא בעצם עושה את זה בסוף?

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

האם זה יהיה מהיר יותר מאשר ואקום מלא?

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

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

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

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

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

תודה על הדיווח! האם מקובל להשתמש בשאילתות פסק זמן של הצהרות כדי להגביל את משך הזמן?

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

תודה על הדיווח! אני מנסה ליישם את הדוח שלך על הבקשות שלי. ונראה כאילו אנחנו מתחילים עסקה בכל מקום, וברור משלימים אותה בכל מקום. אם יש חריג כלשהו, ​​אז החזרה לאחור עדיין מתרחשת. ואז התחלתי לחשוב. הרי ייתכן שהעסקה לא תתחיל במפורש. זה כנראה רמז לילדה. אם רק אעדכן רשומה, האם העסקה תתחיל ב-PostgreSQL ותסתיים רק כשהחיבור יתנתק?

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

כלומר, הוא נסגר מיד לאחר העדכון?

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

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

יש לנטר את השטח בשרת כראוי.

לדוגמה, ה-DBA הלך לשתות תה, היה באתר נופש וכו'.

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

מה אם זה לגמרי מתחת לאפס?

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

האם יש כלים נוספים?

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

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

הם אורזים גם אותם.

אבל הוואקום לא משפיע על המדד?

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

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

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

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

זהו שירות אוקמטר.

האם זה מוצר מסחרי?

כן. זהו מוצר מסחרי.

מקור: www.habr.com