🥇 צלילה עמוקה לתוך הסטטיסטיקה הפנימית של PostgreSQL. אלכסיי לסובסקי

תמלול הדו"ח של אלכסיי לסובסקי לשנת 2015 "צלילה עמוקה לתוך סטטיסטיקה פנימית של PostgreSQL"

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

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

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

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

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

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

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

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

ובואו נדבר על איזה סטטיסטיקה לבחור כדי לפתור בעיות.

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

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

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

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

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

אילו בעיות יש בסטטיסטיקה?

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

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

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

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

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

מקורות הסטטיסטיקה מוצגים כדלקמן:

בזיכרון משותף (buffers shared) יש קטע לאחסון נתונים סטטיים, ישנם גם אותם מונים שמוגדלים כל הזמן כאשר מתרחשים אירועים מסוימים, או מתעוררים רגעים מסוימים בפעולת בסיס הנתונים.
כל המונים הללו אינם נגישים למשתמש ואף אינם נגישים למנהל המערכת. אלו דברים ברמה נמוכה. כדי לגשת אליהם, PostgreSQL מספקת ממשק בצורה של פונקציות SQL. אנו יכולים לבצע זריקות נבחרות באמצעות הפונקציות הללו ולקבל איזשהו מדד (או קבוצה של מדדים).
עם זאת, השימוש בפונקציות אלו אינו תמיד נוח, ולכן הפונקציות הן הבסיס לתצוגות (VIEWs). אלו טבלאות וירטואליות המספקות נתונים סטטיסטיים על תת-מערכת ספציפית, או על סט מסוים של אירועים במסד הנתונים.
תצוגות מוטמעות אלו (VIEWS) הן ממשק המשתמש העיקרי לעבודה עם סטטיסטיקה. הם זמינים כברירת מחדל ללא הגדרות נוספות, אתה יכול מיד להשתמש בהם, להסתכל עליהם ולקחת מהם מידע. ואז יש תרומות. התרומות הן רשמיות. אתה יכול להתקין את חבילת postgresql-contrib (לדוגמה, postgresql94-contrib), לטעון את המודול הנדרש בתצורה, לציין פרמטרים עבורו, להפעיל מחדש את PostgreSQL ותוכל להשתמש בו. (הערה. בהתאם להפצה, בגרסאות האחרונות חבילת התרומה היא חלק מהחבילה הראשית).
ויש תרומות לא רשמיות. הם אינם כלולים בהפצה הסטנדרטית של PostgreSQL. יש להרכיב אותם או להתקין אותם כספרייה. האפשרויות יכולות להיות שונות מאוד, תלוי במה שהמפתח של התרומה הלא רשמית הזו הגיע.

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

עם זאת, אם ניקח את התמונה הקודמת Как тратится время на PostgreSQL ותואם לרשימה זו, אנו מקבלים את התמונה הזו. אנו יכולים להשתמש בכל תצוגה (VIEWs) או בכל פונקציה למטרה זו או אחרת כדי לקבל את הסטטיסטיקה המתאימה כאשר PostgreSQL פועל. ואנחנו כבר יכולים לקבל קצת מידע על פעולת תת-המערכת.

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

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

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

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

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

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

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

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

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

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

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

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

Pg_stat_bgwriter - תצוגה זו מתארת את פעולתן של שתי תת-מערכות רקע PostgreSQL: checkpointer и background writer.

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

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

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

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

וכדי להתאים את המחסום יש שלושה פרמטרים:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

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

Внимание: הגרסה 9.4 הנדונה בדוח אינה רלוונטית עוד. בגרסאות מודרניות של PostgreSQL הפרמטר checkpoint_segments מוחלפים בפרמטרים min_wal_size и max_wal_size.

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

בשביל מה זה עוד נחוץ? זה מספק את הצורך בדפים ריקים במאגרים משותפים אם הם נדרשים פתאום (בכמויות גדולות ומיד) כדי להכיל נתונים. נניח שנוצר מצב שבו נדרשו דפים ריקים להשלמת בקשה והם כבר היו במאגרים המשותפים. Postgresive backend הוא פשוט מרים אותם ומשתמש בהם, הוא לא צריך לנקות שום דבר בעצמו. אבל אם פתאום אין דפים כאלה, הקצה האחורי משהה את העבודה ומתחיל לחפש דפים כדי לזרוק אותם לדיסק ולקחת אותם לצרכיו שלו - מה שמשפיע לרעה על זמן הבקשה שבוצעה כעת. אם אתה רואה שיש לך פרמטר maxwritten_clean גדול, זה אומר שכותב הרקע לא עושה את העבודה שלו ואתה צריך להגדיל את הפרמטרים bgwriter_lru_maxpages, כדי שיוכל לעשות יותר עבודה במחזור אחד, נקה עוד דפים.

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

Внимание: _הטקסט הבא מתאר את התצוגות הסטטיסטיות הקשורות לשכפול. רוב שמות התצוגה והפונקציות שונו ב-Postgres 10. המהות של שינוי השם הייתה להחליף xlog על wal и location על lsn בשמות פונקציות/תצוגה וכו'. דוגמה מיוחדת, פונקציה pg_xlog_location_diff() שונה שם ל pg_wal_lsn_diff()._

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

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

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

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

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

יש שלוש סיבות לפיגור:

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

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

הערה: _במקום pg_xlog_locationהפונקציה diff() יכולה להשתמש באופרטור החיסור ולהחסיר מיקום אחד מאחר. נוֹחַ.

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

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

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

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

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

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

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

ניתן לקבל גדלי טבלה גם באמצעות טבלה זו ובאמצעות פונקציות נוספות pg_total_relation_size(), pg_relation_size().

באופן כללי, יש מטא-פקודות dt и di, שבו ניתן להשתמש ב-PSQL וגם להציג את הגדלים של טבלאות ואינדקסים.

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

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

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

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

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

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

ALTER TABLE table_name SET (fillfactor = 70);

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

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

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

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

הערה: _החל מ-Postgres 10, המצב עם מעקב Vatovac השתפר מאוד - תצוגת pg_stat_progress הופיעהואקום, מה שמפשט משמעותית את נושא הניטור על שואב הרכב.

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

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

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

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

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

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

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

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

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

שני קישורים:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

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

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

מה עוד כדאי לסכם באמצעות מדדים?

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

אם נסיר אינדקסים שאינם בשימוש, רק נשפר את מסד הנתונים.

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

אילו דברים שימושיים נוכל לקחת משם?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

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

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

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

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

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

עסקאות גרועות הן עסקאות במצב סרק בטרנזקציה ובמצב סרק בטרנזקציה (בוטלה).

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

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

אם אתה רואה שיש לך יותר מ-5-10-20 מהם במסד הנתונים שלך, אז אתה צריך לדאוג ולהתחיל לעשות איתם משהו.

כאן אנו משתמשים גם לזמן החישוב clock_timestamp(). אנו מצלמים עסקאות ומייעלים את האפליקציה.

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

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

Внимание: _החל משדה Postgres גרסה 9.6 waiting הוסר ובמקום זאת נוספו שני שדות אינפורמטיביים נוספים wait_event_type и wait_event._

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

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

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

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

והקישור הראשון הוא טקסט הבקשה עצמו. זה די ארוך.

והקישור השני הוא מאמר על מנעולים. זה שימושי לקריאה, זה מאוד מעניין.

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

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

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

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

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

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

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

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

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

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

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

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

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

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

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

המודול הבא - pg_stat_kcache. זה גם משתמש בשיחת מערכת getrusage(). והוא מבצע אותו לפני ואחרי ביצוע הבקשה. ובנתונים הסטטיסטיים המתקבלים, זה מאפשר לנו להעריך כמה הבקשה שלנו הוציאה על קלט/פלט של דיסק, כלומר, פועלת עם מערכת הקבצים ומסתכלת על השימוש במעבד. עם זאת, המודול צעיר (שיעול) ובשביל פעולתו הוא דורש PostgreSQL 9.4 ו-pg_stat_statements, אותם הזכרתי קודם.

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