יסודות ניטור PostgreSQL. אלכסיי לסובסקי

אני מציע לך לקרוא את תמליל הדו"ח של אלכסיי לסובסקי מ-Data Egret "יסודות ניטור PostgreSQL"

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

שמי אלכסיי לסובסקי, אני מייצג את חברת Data Egret.

כמה מילים על עצמי. התחלתי לפני זמן רב כמנהל מערכת.

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

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

עכשיו אני עובד על PostgreSQL. אני כבר כותב עוד דבר שמאפשר לך לעבוד עם סטטיסטיקות PostgreSQL. זה נקרא pgCenter (מאמר על Habré - סטטיסטיקות שלאחר נסיעות ללא עצבים ומתח).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

האם כולם מבינים שכמה בקשות יכולות להתאים לעסקה אחת? לכן TPS ו-QPS שונים במקצת.

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

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

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

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

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

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

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

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

מידע על לקוחות מחוברים חשוב מכיוון שמנקודת מבט של PostgreSQL, לקוחות שונים. יש לקוחות טובים ויש לקוחות רעים.

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

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

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

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

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

בהתאם לכך, כדי להוסיף מידע זה לניטור, עליך לגשת לתצוגת מערכת pg_stat_activity. אם אתה מבלה הרבה זמן ב-PostgreSQL, אז זו תצוגה טובה מאוד שאמורה להפוך לחבר שלך, מכיוון שהיא מציגה את הפעילות הנוכחית ב-PostgreSQL, כלומר מה קורה בה. לכל תהליך ישנה שורה נפרדת המציגה מידע על תהליך זה: מאיזה מארח בוצע החיבור, באיזה משתמש, באיזה שם, מתי החלה העסקה, איזו בקשה פועלת כרגע, איזו בקשה בוצעה לאחרונה. ובהתאם לכך, אנו יכולים להעריך את מצב הלקוח באמצעות השדה הסטטיסטי. באופן יחסי, אנחנו יכולים לקבץ לפי שדה זה ולקבל את הנתונים הסטטיסטיים שנמצאים כרגע במסד הנתונים ואת מספר החיבורים שיש להם את הנתון הזה במסד הנתונים. ואנחנו יכולים לשלוח את המספרים שכבר התקבלו לניטור שלנו ולצייר גרפים על סמך אותם.
חשוב גם להעריך את משך העסקה. כבר אמרתי שחשוב להעריך את משך הוואקום, אבל עסקאות מוערכות באותה צורה. ישנם שדות xact_start ו-query_start. הם, יחסית, מציגים את שעת ההתחלה של העסקה ואת שעת ההתחלה של הבקשה. אנחנו לוקחים את הפונקציה now() שמציגה את חותמת הזמן הנוכחית, ומחסירים את העסקה ומבקשת חותמת זמן. ונקבל את משך העסקה, את משך הבקשה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אתה יכול לעקוב אחר השאילתות הארוכות ביותר, כלומר, אותן שאילתות שלוקח להן הכי הרבה זמן להשלים. הם פועלים על המעבד, הם צורכים I/O. אנו יכולים גם להעריך זאת באמצעות השדות total_time, mean_time, blk_write_time ו-blk_read_time.

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

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

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

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

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

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

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

בהתאם לכך, באמצעות pg_stat_bgwriter באמצעות השדות שצוינו נוכל לנטר את מספר המחסומים המתרחשים. ואם יש לנו הרבה מחסומים בפרק זמן מסוים (ב-10-15-20 דקות, בחצי שעה), למשל, 3-4-5, אז זו כבר יכולה להיות בעיה. וכבר צריך להסתכל במסד הנתונים, להסתכל בתצורה, מה גורם לשפע כזה של מחסומים. אולי יש איזושהי הקלטה גדולה. אנחנו כבר יכולים להעריך את עומס העבודה, כי כבר הוספנו גרפי עומס. אנחנו כבר יכולים לשנות את פרמטרי המחסום ולוודא שהם לא משפיעים מאוד על ביצועי השאילתות.

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

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

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

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

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

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

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

בגרסה 10, שם הפונקציה הזו שונה ל-pg_wal_lsn_diff(). באופן כללי, בכל הפונקציות, התצוגות וכלי השירות שבהם נמצאה המילה "xlog", היא הוחלפה בערך "wal". זה חל הן על תצוגות והן על פונקציות. זה כזה חידוש.

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

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

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

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

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

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

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

וכמה נקודות מפתח:

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

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

בקשות לדוגמא:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

שאלות

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

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

PS1 אם אתה משתמש ב-postgres_exporter, באיזה לוח מחוונים אתה משתמש? יש כמה מהם. הם כבר מיושנים. אולי הקהילה תיצור תבנית מעודכנת?

PS2 הוסר pganalyze מכיוון שזוהי הצעת SaaS קניינית המתמקדת בניטור ביצועים והצעות כוונון אוטומטיות.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

איזה ניטור postgresql באירוח עצמי (עם לוח מחוונים) לדעתך הכי טוב?

• 30,0%Zabbix + תוספות מאלכסיי לסובסקי או zabbix 4.4 או libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze הוא SaaS קנייני - אני לא יכול למחוק אותו1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 משתמשים הצביעו. 26 משתמשים נמנעו.

מקור: www.habr.com