הגדרת אפשרויות ליבת לינוקס למיטוב PostgreSQL

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

SHMMAX / SHMALL

SHMMAX הוא פרמטר ליבה המשמש לקביעת הגודל המרבי של מקטע זיכרון משותף יחיד שתהליך לינוקס יכול להקצות. לפני גרסה 9.2, PostgreSQL השתמש במערכת V (SysV), הדורשת את הגדרת SHMMAX. לאחר 9.2, PostgreSQL עבר לזיכרון משותף POSIX. אז עכשיו נדרשים פחות בתים של זיכרון משותף של System V.

לפני גרסה 9.3, SHMMAX היה פרמטר הליבה החשוב ביותר. ערך SHMMAX מצוין בבתים.

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

ש.מ.* פרטים - לינוקס

$ ipcs -lm

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1073741824
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1

פרטי SHM* - MacOS X

$ ipcs -M
IPC status from  as of Thu Aug 16 22:20:35 PKT 2018
shminfo:
	shmmax: 16777216	(max shared memory segment size)
	shmmin:       1	(min shared memory segment size)
	shmmni:      32	(max number of shared memory identifiers)
	shmseg:       8	(max shared memory segments per process)
	shmall:    1024	(max amount of shared memory in pages)

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

שגיאות קונפיגורציה שגויות אפשריות

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

initdb כשל
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. 
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

באופן דומה, ייתכן שתקבל שגיאה בעת הפעלת שרת PostgreSQL באמצעות הפקודה pg_ctl.

pg_ctl כשל
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

הבנת ההבדלים בהגדרות

הגדרת הפרמטרים SHMMAX/SHMALL שונה במקצת ב-Linux וב-MacOS X:

• לינוקס: kernel.shmmax, kernel.shmal
• MacOS X: kern.sysv.shmmax, kern.sysv.shmall

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

שינוי הגדרות ליבה ב-MacOS X

# Get the value of SHMMAX
sudo sysctl kern.sysv.shmmax
kern.sysv.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kern.sysv.shmall 
kern.sysv.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kern.sysv.shmmax=16777216
kern.sysv.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kern.sysv.shmall=16777216
kern.sysv.shmall: 4096 -> 16777216

שינוי פרמטרי ליבה בלינוקס

# Get the value of SHMMAX
sudo sysctl kernel.shmmax
kernel.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kernel.shmall
kernel.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kernel.shmmax=16777216
kernel.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kernel.shmall=16777216
kernel.shmall: 4096 -> 16777216

אל תשכח: כדי להפוך שינויים קבועים, הוסף את הערכים האלה ל- /etc/sysctl.conf

דפים ענקיים

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

PostgreSQL תומך רק בדפים גדולים בלינוקס. כברירת מחדל, לינוקס משתמשת בדפי זיכרון של 4 KB, כך שבמקרים בהם יש יותר מדי פעולות זיכרון, יש צורך להגדיר דפים גדולים יותר. שיפורי ביצועים נצפים בעת שימוש בדפים גדולים של 2 MB ועד 1 GB. ניתן להגדיר את גודל העמוד הגדול בזמן האתחול. אתה יכול לבדוק בקלות את פרמטרי העמוד הגדולים ואת השימוש בהם במחשב הלינוקס שלך באמצעות הפקודה cat /proc/meminfo | grep -i ענק.

קבלת מידע על דפים גדולים (לינוקס בלבד)

Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

בדוגמה זו, למרות שגודל העמוד הגדול מוגדר ל-2048 (2 מגה-בייט), המספר הכולל של עמודים גדולים מוגדר ל-0. המשמעות היא שעמודים גדולים מושבתים.

סקריפט לקביעת מספר העמודים הגדולים

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

קבלת מספר הדפים הגדולים הנדרשים

#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid:            $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak:            $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize:   $hps kB"
hp=$((peak/hps))
echo Set Huge Pages:     $hp

פלט הסקריפט נראה כך:

פלט סקריפט

Pid:            12737
VmPeak:         180932 kB
Hugepagesize:   2048 kB
Set Huge Pages: 88

הערך המומלץ עבור דפים גדולים הוא 88, אז כדאי להגדיר אותו ל-88.

התקנת דפים גדולים

sysctl -w vm.nr_hugepages=88

בדוק כעת דפים גדולים, תראה שלא נעשה שימוש בדפים גדולים (HugePages_Free = HugePages_Total).

דפים גדולים שנבדקו מחדש (לינוקס בלבד)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       88
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

כעת הגדר את הפרמטר huge_pages ל-"on" ב-$PGDATA/postgresql.conf והפעל מחדש את השרת.

שוב, מידע על דפים גדולים (לינוקס בלבד)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       81
HugePages_Rsvd:       64
HugePages_Surp:        0
Hugepagesize:       2048 kB

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

חלק מפעולות מסד הנתונים למיחזור דפים גדולים

postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000

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

מידע נוסף בדפים גדולים (לינוקס בלבד)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       18
HugePages_Rsvd:        1
HugePages_Surp:        0
Hugepagesize:       2048 kB

עכשיו אתה יכול לראות שרוב הדפים הגדולים נמצאים בשימוש.

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

vm.swappiness

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

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

הגדרת זה ל-0 על גרעינים חדשים יותר עלולה לגרום ל- OOM Killer (תהליך ניקוי הזיכרון של לינוקס) להרוג את התהליך. אז זה בטוח להגדיר אותו ל-1 אם אתה רוצה למזער את ההחלפה. ערך ברירת המחדל בלינוקס הוא 60. ערך גבוה יותר גורם ל-MMU (יחידת ניהול זיכרון) להשתמש יותר בשטח החלפה מ-RAM, בעוד שערך נמוך יותר שומר יותר נתונים/קוד בזיכרון.

ערך נמוך יותר הוא הימור טוב לשיפור הביצועים ב-PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

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

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

Ссылка: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - אחוז זיכרון RAM זמין לעומס יתר. ערך של 50% במערכת עם 2 GB של זיכרון RAM יכול להקצות עד 3 GB של זיכרון RAM.

ערך של 2 עבור vm.overcommit_memory מספק ביצועים טובים יותר עבור PostgreSQL. ערך זה ממקסם את השימוש ב-RAM של תהליך השרת ללא כל סיכון משמעותי להיהרג על ידי תהליך ה-OOM Killer. האפליקציה תוכל להיטען מחדש, אך רק בגבולות החריפה, מה שמפחית את הסיכון של רוצח OOM להרוג את התהליך. לכן, ערך של 2 נותן ביצועים טובים יותר מערך ברירת המחדל של 0. עם זאת, ניתן לשפר את המהימנות על ידי הבטחת זיכרון מחוץ לטווח לא עומס יתר על המידה. זה מבטל את הסיכון שהתהליך ייהרג על ידי רוצח OOM.

במערכות ללא החלפה, עלולה להתרחש בעיה עם vm.overcommit_memory השווה ל-2.

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio הוא אחוז הזיכרון המלא בדפים מלוכלכים שצריך לכתוב לדיסק. ההדחה לדיסק מתרחשת ברקע. הערך של פרמטר זה נע בין 0 ל-100; עם זאת, ערך מתחת ל-5 עלול להיות לא יעיל וכמה גרעינים לא תומכים בו. 10 הוא ברירת המחדל ברוב מערכות לינוקס. אתה יכול לשפר את הביצועים עבור פעולות עתירות כתיבה על ידי גורם קטן יותר, מה שאומר שלינוקס תשטוף דפים מלוכלכים ברקע.

אתה צריך להגדיר את הערך vm.dirty_background_bytes בהתאם למהירות הנסיעה שלך.

אין ערכים "טובים" עבור שני הפרמטרים הללו מכיוון ששניהם תלויים בחומרה. עם זאת, הגדרת vm.dirty_background_ratio ל-5 ו-vm.dirty_background_bytes ל-25% ממהירות הדיסק משפרת את הביצועים ל-~25% ברוב המקרים.

vm.dirty_ratio/dirty_bytes

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

סך הכל

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

מקור: www.habr.com