גישה תעשייתית לכוונון PostgreSQL: ניסויים עם מסדי נתונים." ניקולאי סמוקהלוב

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

Shared_buffers = 25% - האם זה הרבה או מעט? או בדיוק נכון? איך אתה יודע אם ההמלצה - המיושנת למדי - מתאימה במקרה הספציפי שלך?

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

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

שימוש ב-Nancy CLI (https://gitlab.com/postgres.ai/nancy), נסתכל על דוגמה ספציפית - shared_buffers הידועים לשמצה - במצבים שונים, בפרויקטים שונים וננסה להבין כיצד לבחור את ההגדרה האופטימלית עבור התשתית, מסד הנתונים והעומס שלנו.

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

מעט עלי. ניסיון עם Postgres יותר מ-14 שנים. מספר חברות רשתות חברתיות ייסדו. Postgres היה ומשמש בכל מקום.

גם קבוצת RuPostgres ב-Meetup, מקום 2 בעולם. אנחנו מתקרבים לאט לאט ל-2 איש. RuPostgres.org.

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

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

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

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

דוח זה לא יכלול:

• "כדורי כסף" והצהרות כמו - הגדר 8 GB או 25% shared_buffers ואתה תהיה בסדר. לא יהיה הרבה על shared_buffers.
• הארדקור "קרביים".

ומה יקרה?

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

איך כל זה מתפתח?

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

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

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

לכל גישה יש חסרונות רציניים. בגישה הראשונה, זרקנו את כל הפרמטרים. ואם נראה את הקבוצות SELECT * FROM הטבלה שבה העמודה שווה ל-"?" או "$" מאז Postgres 10. אנחנו לא יודעים אם זו סריקת אינדקס או סריקת seq. זה מאוד תלוי בפרמטר. אם תחליף שם ערך נדיר שנתקל בו, זו תהיה סריקת אינדקס. אם תחליף שם ערך שתופס 90% מהטבלה, סריקת ההמשך תהיה ברורה, כי Postgres יודע את הסטטיסטיקה. וזה חסרון גדול של pg_stat_statements, למרות שחלק מהעבודה מתבצעת.

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

איך DBAs פותרים את הבעיות שהם מוצאים?

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

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

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

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

דוגמאות מהחיים האמיתיים

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

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

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

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

אנחנו פותחים ניסוי. הנה pg_stat_statements. בצד שמאל זה מה שקרה. מימין - מה קרה.

משמאל default_statistics_target = 100, מימין = 1. אנחנו רואים שזה עזר לנו. בסך הכל, הכל השתפר ב-000%.

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

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

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

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

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

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

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

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

ננסי CLI - הבסיס של "מעבדת מסדי הנתונים"

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

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

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

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

ויש גם הזדמנות לרוץ מרחוק באמזון ב-EC2 Instance, בנקודות. וזו הזדמנות מגניבה מאוד. לדוגמה, אתמול ערכנו יותר מ-500 ניסויים במופע i3, החל מהצעיר ביותר וכלה ב-i3-16-xlarge. ו-500 ניסויים עלו לנו 64 דולר. כל אחד נמשך 15 דקות. כלומר, בשל העובדה שמשתמשים שם בספוטים, זה מאוד זול - 70% הנחה, החיוב של אמזון לשנייה. אתה יכול לעשות הרבה. אתה יכול לעשות מחקר אמיתי.

ושלוש גרסאות עיקריות של Postgres נתמכות. זה לא כל כך קשה לסיים כמה ישנים וגם את הגרסה ה-12 החדשה.

אנו יכולים להגדיר אובייקט בשלוש דרכים. זֶה:

• קובץ dump/sql.
• הדרך העיקרית היא לשכפל את ספריית PGDATA. ככלל, זה נלקח משרת הגיבוי. אם יש לך גיבויים בינאריים רגילים, אתה יכול לעשות שיבוטים משם. אם יש לך עננים, משרד ענן כמו אמזון וגוגל יעשה זאת עבורך. זוהי הדרך החשובה ביותר לשבט ייצור אמיתי. כך אנו מתפתחים.
• והשיטה האחרונה מתאימה למחקר כשרוצים להבין איך משהו עובד ב-Postgres. זה pgbench. אתה יכול ליצור באמצעות pgbench. זו רק אפשרות אחת של "db-pgbench". תגיד לו באיזה קנה מידה. והכל יווצר בענן, כאמור.

וטען:

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

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

• מגיעה ספרייה עם חבורה של קבצים שונים, החל מתצלומי מצב של pgstat***. והדבר הכי מעניין שיש זה pg_stat_statements, pg_stat_kcacke. אלו שתי הרחבות שמנתחות בקשות. ו-pg_stat_bgwriter מכיל לא רק סטטיסטיקה של pgwriter, אלא גם על המחסום וכיצד ה-backends עצמם מחליפים חוצצים מלוכלכים. וכל זה מעניין לראות. לדוגמה, כאשר אנו מגדירים shared_buffers, מעניין מאוד לראות כמה כולם החליפו.
• גם יומני Postgres מגיעים. שני יומנים - יומן הכנה ויומן השמעה לטעינה.
• תכונה חדשה יחסית היא FlameGraphs.
• כמו כן, אם השתמשת באפשרויות pgreplay או pgbench להפעלת העומס, הפלט שלהם יהיה מקורי. ותראה חביון ו-TPS. אפשר יהיה להבין איך הם ראו את זה.
• מידע מערכת.
• בדיקות מעבד ו-IO בסיסיות. זה יותר עבור מופע EC2 באמזון, כאשר אתה רוצה להשיק 100 מופעים זהים בשרשור ולהריץ שם 100 ריצות שונות, אז יהיו לך 10 ניסויים. ואתה צריך לוודא שאתה לא נתקל במופע פגום שכבר מדוכא על ידי מישהו. אחרים פעילים ברכיב החומרה הזה ונשאר לך משאב מועט. עדיף להשליך תוצאות כאלה. ובעזרת sysbench של Alexey Kopytov, אנחנו עושים כמה בדיקות קצרות שיגיעו וניתן יהיה להשוות אותן עם אחרות, כלומר תבינו איך המעבד מתנהג ואיך מתנהג ה-IO.

מהם הקשיים הטכניים בהתבסס על הדוגמה של חברות שונות?

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

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

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

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

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

אנו יכולים לראות ש-802 פעמים בשנייה הבקשה הזו מבוצעת. ואנחנו רואים ש-bytes_per sec – 300 kB/s ייכתבו פלוס או מינוס. וככלל, אנו יכולים להרשות לעצמנו זרימה כזו.

אבל! העובדה היא שיש מערכות רישום שונות. וברירת המחדל של אנשים היא בדרך כלל "syslog".

ואם יש לך syslog, אז אולי יש לך תמונה כזו. ניקח את pgbench, נפעיל רישום שאילתות ונראה מה קורה.

ללא רישום - זו העמודה משמאל. קיבלנו 161 TPS. עם syslog - זה באובונטו 000 באמזון, אנחנו מקבלים 16.04 TPS. ואם נשנה לשתי שיטות רישום אחרות, אז המצב הרבה יותר טוב. כלומר, ציפינו שזה יירד, אבל לא באותה מידה.

וב-CentOS 7, שגם journald משתתפת בו, הפיכת יומנים לפורמט בינארי לחיפוש קל וכו', אז זה סיוט שם, אנחנו יורדים 44 פעמים ב-TPS.

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

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

יש לנו pg_stat_statements. כפי שאמרתי, זה חייב להיות שם. ונוכל לקחת ולתאר כל קבוצת בקשות בצורה מיוחדת בקובץ. ואז נוכל להשתמש בתכונה נוחה מאוד ב-pgbench - זוהי היכולת להוסיף מספר קבצים באמצעות אפשרות "-f".

הוא מבין הרבה "-f". ואתה יכול לדעת בעזרת "@" בסוף איזה שיתוף צריך להיות לכל קובץ. כלומר, ניתן לומר שעושים זאת ב-10% מהמקרים, וזה ב-20%. וזה יקרב אותנו למה שאנחנו רואים בהפקה.

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

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

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

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

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

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

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

איסוף קבוצות השאילתות "המשפיעות" ביותר - דווח על K003 ב-Postgres-checkup

ויש קבוצת דוחות ק' שלושה דוחות עד כה. ויש דוח כזה K003. יש את החלק העליון מ-pg_stat_statements, ממוין לפי total_time.

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

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

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

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

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

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

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

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

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

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

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

והמחרוזת הרביעית בכל שורה היא כמה אחוז מהסך הכל. יש לנו שיחות. נניח 1. ואנחנו יכולים להבין איזו תרומה לקבוצה הזו תורמת. אנו רואים שבמקרה זה הקבוצה הראשונה תורמת פחות מ-000%. כלומר, זה כל כך איטי שאנחנו לא רואים את זה בתמונה הכוללת. והקבוצה השנייה היא 000% על שיחות. כלומר, 0,01% מכלל השיחות הן הקבוצה השנייה.

גם Total_time מעניין. השקענו 14% מזמן העבודה הכולל שלנו בקבוצת הבקשות הראשונה. ולשני - 11% וכו'.

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

אחר כך נחזור לנושא שלנו. אנחנו צריכים לעצב את עומס העבודה. אנחנו לוקחים את זה מלמעלה למטה והולכים עד שנגיע ל-80% או 90%. בדרך כלל מדובר על 10-20 קבוצות. ואנחנו עושים קבצים עבור pgbench. אנחנו משתמשים באקראי שם. לפעמים זה, למרבה הצער, לא מסתדר. וב-Postgres 12 יהיו הזדמנויות נוספות להשתמש בגישה זו.

ואז אנחנו מרוויחים 80-90% ב-total_time בדרך זו. מה עלי לשים אחרי "@"? אנחנו מסתכלים על השיחות, רואים כמה עניין יש ומבינים שאנחנו חייבים כאן כל כך הרבה ריבית. מהאחוזים הללו נוכל להבין כיצד לאזן כל אחד מהקבצים. אחרי זה אנחנו משתמשים ב-pgbench והולכים לעבודה.

יש לנו גם K001 ו-K002.

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

K002 זה מה שאני מכנה מחלקות שאילתות, כלומר SELECT, INSERT, UPDATE, DELETE. ובנפרד SELECT FOR UPDATE, כי זה מנעול.

וכאן נוכל להסיק ש-SELECT הוא קוראים רגילים - 82% מכלל השיחות, אך במקביל - 74% ב-total_time. כלומר, הם נקראים הרבה, אבל צורכים פחות משאבים.

ואנחנו חוזרים לשאלה: "איך נוכל לבחור את ה-shared_buffers הנכונים?" אני מבחין שרוב המדדים מבוססים על הרעיון - בוא נראה מה תהיה התפוקה, כלומר מה תהיה התפוקה. זה נמדד בדרך כלל ב-TPS או QPS.

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

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

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

ולבסוף, המלצות:

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

שאלות

תודה רבה! דבר מאוד מעניין.

שתי חתיכות.

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

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

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

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

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

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

ברגע שנבנה את המעבדה, אולי יהיה משוב. בוא נראה. תודה!

שלום! תודה על הדיווח! ראיתי שיש תמיכה באמזון. האם יש תוכניות לתמוך ב-GSP?

שאלה טובה. התחלנו לעשות את זה. והקפאנו את זה לעת עתה כי אנחנו רוצים לחסוך כסף. כלומר, יש תמיכה באמצעות run on localhost. אתה יכול ליצור מופע בעצמך ולעבוד באופן מקומי. אגב, זה מה שאנחנו עושים. אני עושה את זה ב-Getlab, שם ב-GSP. אבל אנחנו עדיין לא רואים את הטעם לעשות רק תזמור כזה, כי לגוגל אין מקומות זולים. יש ??? מקרים, אבל יש להם מגבלות. ראשית, תמיד יש להם רק 70% הנחה ואי אפשר לשחק עם המחיר שם. בספוטים, אנחנו מעלים את המחיר ב-5-10% כדי להפחית את הסבירות שתבעטו. כלומר, אתה שומר כתמים, אך ניתן לקחת אותם ממך בכל עת. אם תציע קצת יותר גבוה ממה שמציעים אחרים, תהרגו אותך מאוחר יותר. לגוגל יש פרטים שונים לחלוטין. ויש עוד מגבלה גרועה מאוד - הם חיים רק 24 שעות. ולפעמים אנחנו רוצים להפעיל ניסוי במשך 5 ימים. אבל אתה יכול לעשות זאת בנקודות; כתמים לפעמים נמשכים חודשים.

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

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

אתה לא מפחד שהוא יסתובב לשם פעמיים או שלוש במהלך הזמן שבין התמונות?

כלומר, הם נרשמו שוב או מה?

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

שאלה טובה, נצטרך להסתכל.

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

כן כן.

אבל אני לא מבין איך אחרת לעשות את זה בצורה מהימנה.

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

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

עם אותו תעודת זהות?

כן.

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

זה, כמובן, מקרה נדיר, אבל הייתי בהלם כשגיליתי ש-stat_statemetns יכולים לעקור שם.

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

כן, כמובן.

ואם יש לך Java hibernate, שהוא אקראי, אז טבלת ה-hash מתחילה להיות ממוקמת שם. וברגע שאתה מכבה אפליקציה עמוסה מאוד, אתה מגיע ל-50-100 קבוצות. והכל שם פחות או יותר יציב. אחת הדרכים להילחם בזה היא להגדיל את pg_stat_statements.max.

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

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

בדרך כלל כן.

וידאו:

נ.ב בשמי, אוסיף שאם Postgres מכיל נתונים סודיים ולא ניתן לכלול אותם בסביבת הבדיקה, אז אתה יכול להשתמש PostgreSQL Anonymizer. התכנית היא כדלקמן:

מקור: www.habr.com