כוונון לינוקס לשיפור ביצועי PostgreSQL. איליה קוסמודמיאנסקי

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

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

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

על מה נדבר? אם אתה מתקשר עם PostgreSQL, אז במידה מסוימת אתה צריך להיות מנהל UNIX. מה זה אומר? אם נשווה את Oracle ו-PostgreSQL, אז ב-Oracle אתה צריך להיות 80% מנהל מסד נתונים של DBA ו-20% מנהל לינוקס.

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

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

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

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

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

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

אתה יכול לכוון:

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

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

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

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

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

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

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

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

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

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

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

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

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

ובואו נעבור על כל אחת מהנקודות הללו.

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

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

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

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

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

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

מה באמת קורה? NUMA ראשי תיבות של Non-Uniform Memory Access. מה הטעם? יש לך מעבד, לידו יש את הזיכרון המקומי שלו. וחיבורי הזיכרון האלה יכולים למשוך זיכרון ממעבדים אחרים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ואיך אפשר להתיידד עם PostgreSQL? ראשית, יש להפעיל דפים ענקיים בליבת לינוקס.

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

ואם כל השרת שלך מוקדש ל-PostgreSQL, אז נקודת התחלה טובה היא להקצות או 25% מה-RAM למאגרים משותפים, או 75% אם אתה בטוח שמסד הנתונים שלך בהחלט יתאים ל-75%. נקודת התחלה אחת. ושקול, אם יש לך 256 GB של זיכרון RAM, אז, בהתאם, יהיו לך 64 GB של חוצצים גדולים. חשבו בקירוב עם קצת שוליים - למה צריך להגדיר את הנתון הזה.

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

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

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

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

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

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

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

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

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

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

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

לכן, כעת ברירת המחדל, עד כמה שאני זוכר, רוב ההפצות הן איפשהו בסביבות 6, כלומר באיזה שלב כדאי להתחיל להשתמש ב-swap בהתאם לכמות הזיכרון שנותר. כעת אנו ממליצים להגדיר vm.swappiness = 1, כי זה כמעט מכבה את זה, אבל לא נותן את אותם אפקטים כמו עם OOM-killer שהגיע באופן בלתי צפוי והרג את כל העניין.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יש שני דברים חדשים יחסית. הם כבר הופיעו בליבות השלישיות. זה הוא sched_migration_cost בננו-שניות ו-sched_autogroup_enabled, שהוא אחד כברירת מחדל.

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

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

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

עמיתי אלכסיי לסובסקי עשה בדיקות עם pgbench פשוט, שם הוא העלה את עלות ההגירה בסדר גודל וביטל את ה-autogroup. ההבדל בחומרה גרועה היה כמעט 10%. יש דיון ברשימת התפוצה של postgres שבו אנשים נותנים תוצאות של שינויים דומים למהירות השאילתה השפיע 50%. יש די הרבה סיפורים כאלה.

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

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

אם אתה משתמש בחומר הזה בשרת עם מסד נתונים בעומס רב, הבחירה שלך היא acpi_cpufreq + permormance. גם עם דרישה יהיו בעיות.

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

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

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

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

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

שאלות:

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

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

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

אם יש לך NGINX באותו שרת, תהיה לך גם אותה בעיה. הוא יילחם על זיכרון משותף. ולא תגיעו לבעיות המתוארות כאן.

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

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

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

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

מדוע לדפי ענק שקופים אין השפעה בהשוואה ל-Huge TLB?

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

מקור: www.habr.com