כיצד לתקן דליפת זיכרון בשרת?

[ע"ה דכו"ע]

@ivrtikshoret כתב בכיצד לתקן דליפת זיכרון בשרת?:

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

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

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

אין פה תוכנה יחידה, יש פה כמה.

יש שם עוד תוכנה אחת פועלת שצורכת מינימום משאבים (חוץ מהתוכנה והמסד נתונים שכתבתי בפוסט הראשון), ואין לי כל כך אפשרות לעצור שום דבר שם, כי הכל פחות או יותר בייצור, חוץ מאלו הכל זה רק שירותי מערכת וכדו'.
למעשה התוכנות הרציניות זה השלושה שבמעלה הרשימה, וחוץ מזה יש את התוכנה הנוספת בשם the-channel-bin שהיא צורכת פחות מכמה מ"ב.

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

גם על caddy אפשר לוותר אבל זה תלוי בצרכים שלך.

כנ"ל, אני לא יכול לעצור אותו כרגע.

[dovid]

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

[ע"ה דכו"ע]

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

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

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

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

אגב הCaddy אמור להיות כמה מגה בודדים, אז אתה יכול להתמקד בו.

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

לפי איך שזה נראה בלוגים של fail2ban אני לא תחת מתקפה (למרות שלפני שהתקנתי אותו והחלפתי פורט לSSH כנראה כן היה איזו שהיא מתקפה, אבל זה היה מזמן).

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

יש חומת אש שאתה יכול להפעיל לפני השרת?

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

[חגי]

אתה יכול לשתף פה את הפלט של free -m?

אני פשוט חושד שהבעיה שלך היא זו - https://www.linuxatemyram.com/

[ע"ה דכו"ע]

@חגי כתב בכיצד לתקן דליפת זיכרון בשרת?:

אתה יכול לשתף פה את הפלט של free -m?

➜  ~ free -m
               total        used        free      shared  buff/cache   available
Mem:            7941        6691         897           1         736        1250
Swap:           4095           0        4095

@חגי כתב בכיצד לתקן דליפת זיכרון בשרת?:

אני פשוט חושד שהבעיה שלך היא זו - https://www.linuxatemyram.com/

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

[Jabberwock]

שים לב שה-Virtual Memory שלך גדל בתהליך שנקרא "the-channel-bin".
בין צילומי המסך של האחרי והלפני שהעלאת יש גדילה של 1.71GB בסה"כ.
התהליך המדובר גדל רק ב-524MB. כלומר יש עוד דליפה ממקור אחר, או שיש תהליכים חדשים חבואים?
בהתחלה ציינת שיש גם מסד נתונים, איפה הוא? הוא לא ברשימה של htop.
שים לב שיש הבדלים בין זיכרון פרטי ולזיכרון Commit Size, לדוגמה:

כאן ניתן לראות שבתהליך של MariaDB יש הקצאת זיכרון HEAP של יותר מ-2GB.
תבדוק אצלך אולי זה מה שקורה.

[ע"ה דכו"ע]

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

שים לב שה-Virtual Memory שלך גדל בתהליך שנקרא "the-channel-bin".
בין צילומי המסך של האחרי והלפני שהעלאת יש גדילה של 1.71GB בסה"כ.
התהליך המדובר גדל רק ב-524MB. כלומר יש עוד דליפה ממקור אחר, או שיש תהליכים חדשים חבואים?

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

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

בהתחלה ציינת שיש גם מסד נתונים, איפה הוא? הוא לא ברשימה של htop.

זה redis והוא השלישי ברשימה.

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

תבדוק אצלך אולי זה מה שקורה.

כנ"ל התפיסת זיכרון הזו לא אמורה להיות באמת תפוסה.

[Jabberwock]

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

[ע"ה דכו"ע]

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

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

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

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

וגם, תוכל להריץ cat /proc/meminfo

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

➜  ~ cat /proc/meminfo | grep -E "MemTotal|MemAvailable|Slab|SUnreclaim|Shmem|VmallocUsed"
MemTotal:        8132124 kB
MemAvailable:    1031840 kB
Shmem:              1268 kB
Slab:             175276 kB
SUnreclaim:       145920 kB
VmallocUsed:       21232 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB

כרגע זה הפלט:

➜  ~ cat /proc/meminfo
MemTotal:        8132128 kB
MemFree:         5281020 kB
MemAvailable:    5787144 kB
Buffers:           23760 kB
Cached:           612268 kB
SwapCached:            0 kB
Active:          1628768 kB
Inactive:         242760 kB
Active(anon):    1245380 kB
Inactive(anon):        0 kB
Active(file):     383388 kB
Inactive(file):   242760 kB
Unevictable:       27444 kB
Mlocked:           27444 kB
SwapTotal:       4194300 kB
SwapFree:        4194300 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                36 kB
Writeback:             0 kB
AnonPages:       1262968 kB
Mapped:           339568 kB
Shmem:              1128 kB
KReclaimable:     185396 kB
Slab:             294532 kB
SReclaimable:     185396 kB
SUnreclaim:       109136 kB
KernelStack:        3584 kB
PageTables:         8328 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8260364 kB
Committed_AS:    2428964 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       20436 kB
VmallocChunk:          0 kB
Percpu:             2096 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
Unaccepted:            0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      169832 kB
DirectMap2M:     8218624 kB

[Jabberwock]

על פניו, ולפי המידע שנתת, אין שום בעיה בזיכרון. האם כאשר חווית איטיות, הופיע ב-HTOP שימוש בזיכרון קובץ החלפה (SWAP)? אם לא, ייתכן והיה עומס על השרת בו מאוחסן ה-VPS.

[ע"ה דכו"ע]

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

על פניו, ולפי המידע שנתת, אין שום בעיה בזיכרון. האם כאשר חווית איטיות, הופיע ב-HTOP שימוש בזיכרון קובץ החלפה (SWAP)? אם לא, ייתכן והיה עומס על השרת בו מאוחסן ה-VPS.

כן, הקובץ SWAP בא לידי שימוש בזמן העומס, והRAM היה בשימוש של 100%

בעיה ודאי שיש, השאלה במה