پر شدن RAM خود به خود و بدون علت منطقی در Esxi

[NabiKAZ]

سرور مجازی دارم که در بستر مجازی ساز esxi است.
از CentOS 7 استفاده میکنم و فقط PHP روی سرور کمپایل شده و هیچ نرم افزار دیگری روی سرور نصب نیست، حتی وب سرویس و سرور جهت تست است و عملیات خاصی روی آن انجام نمیشود.
1 گیگ رم و 10 گیگ سواپ دارم.
مشکل این است که رم سرور بعد از مدتی خود به خود پر میشود. (چیزی نزدیک به 100%)
تنها با ریست کردن سرور مشکل حل میشود.
PUTTY_m2MSRVO57Z (2).png


با پشتیبانی که از آنها سرور مجازی تهیه شده صحبت کردم، ابتدا موضوع کش را مطرح کردند.
اما من تست کردم دستور:

sync; echo 2 > /proc/sys/vm/drop_caches

کمکی نمیکند چون مسئله مربوط به کش شدن رم نیست.

بعد اشاره به کم بودن 1 گیگ رم شد، درحالی که Recommended minimum requirements CentOS7 طبق مستندات سایت رسمی، 1 گیگ است. در ضمن موقع بالا آمدن سیستم عامل تنها حدود 150 مگ (15%) مصرف شده است.

حالا اگر هم فرض کنیم برنامه ای این وسط رم را میخورد، به هر حال باید قابل شناسایی باشد و راه منطقی تر از ریست وجود داشته باشد.
من تست کردم. عکس 1 را ببینید که همه رم اشغال شده است.
mem1.png

همه پروسه ها را کیل کردم و تقریباً هیچ چیزی باقی نیست! نتیجه شده عکس 2 که بازهم میبینید رم پر است!
mem2.png

ریز پروسه ها هم در زیر آوردم.
جمع رم اشغالی پروسه ها به 2% هم نمیرسد، درحالی که حدود 75% رم من پر شده است. الان شما بفرمائید کدام پروسه رم من را خورده است؟

# ps auxf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 0.0 0.0 0 0 ? S Mar28 0:00 [kthreadd]
root 4 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kworker/0:0H]
root 6 0.0 0.0 0 0 ? S Mar28 0:01 _ [ksoftirqd/0]
root 7 0.0 0.0 0 0 ? S Mar28 0:00 _ [migration/0]
root 8 0.0 0.0 0 0 ? S Mar28 0:00 _ [rcu_bh]
root 9 0.1 0.0 0 0 ? S Mar28 2:07 _ [rcu_sched]
root 10 0.0 0.0 0 0 ? S< Mar28 0:00 _ [lru-add-drain]
root 11 0.0 0.0 0 0 ? S Mar28 0:00 _ [watchdog/0]
root 12 0.0 0.0 0 0 ? S Mar28 0:00 _ [watchdog/1]
root 13 0.0 0.0 0 0 ? S Mar28 0:00 _ [migration/1]
root 14 0.0 0.0 0 0 ? S Mar28 0:00 _ [ksoftirqd/1]
root 16 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kworker/1:0H]
root 18 0.0 0.0 0 0 ? S Mar28 0:00 _ [kdevtmpfs]
root 19 0.0 0.0 0 0 ? S< Mar28 0:00 _ [netns]
root 20 0.0 0.0 0 0 ? S Mar28 0:00 _ [khungtaskd]
root 21 0.0 0.0 0 0 ? S< Mar28 0:00 _ [writeback]
root 22 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kintegrityd]
root 23 0.0 0.0 0 0 ? S< Mar28 0:00 _ [bioset]
root 24 0.0 0.0 0 0 ? S< Mar28 0:00 _ [bioset]
root 25 0.0 0.0 0 0 ? S< Mar28 0:00 _ [bioset]
root 26 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kblockd]
root 27 0.0 0.0 0 0 ? S< Mar28 0:00 _ [md]
root 28 0.0 0.0 0 0 ? S< Mar28 0:00 _ [edac-poller]
root 29 0.0 0.0 0 0 ? S< Mar28 0:00 _ [watchdogd]
root 35 0.0 0.0 0 0 ? S Mar28 0:00 _ [kswapd0]
root 36 0.0 0.0 0 0 ? SN Mar28 0:00 _ [ksmd]
root 37 0.0 0.0 0 0 ? SN Mar28 0:00 _ [khugepaged]
root 38 0.0 0.0 0 0 ? S< Mar28 0:00 _ [crypto]
root 46 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kthrotld]
root 49 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kmpath_rdacd]
root 50 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kaluad]
root 51 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kpsmoused]
root 53 0.0 0.0 0 0 ? S< Mar28 0:00 _ [ipv6_addrconf]
root 66 0.0 0.0 0 0 ? S< Mar28 0:00 _ [deferwq]
root 104 0.0 0.0 0 0 ? S Mar28 0:00 _ [kauditd]
root 241 0.0 0.0 0 0 ? S< Mar28 0:00 _ [ata_sff]
root 242 0.0 0.0 0 0 ? S Mar28 0:00 _ [scsi_eh_0]
root 243 0.0 0.0 0 0 ? S< Mar28 0:00 _ [scsi_tmf_0]
root 244 0.0 0.0 0 0 ? S Mar28 0:00 _ [scsi_eh_1]
root 245 0.0 0.0 0 0 ? S< Mar28 0:00 _ [scsi_tmf_1]
root 247 0.0 0.0 0 0 ? S< Mar28 0:00 _ [mpt_poll_0]
root 248 0.0 0.0 0 0 ? S< Mar28 0:00 _ [mpt/0]
root 270 0.0 0.0 0 0 ? S Mar28 0:00 _ [scsi_eh_2]
root 272 0.0 0.0 0 0 ? S< Mar28 0:00 _ [scsi_tmf_2]
root 276 0.0 0.0 0 0 ? S Mar28 0:00 _ [irq/16-vmwgfx]
root 277 0.0 0.0 0 0 ? S< Mar28 0:00 _ [ttm_swap]
root 292 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kworker/0:1H]
root 299 0.0 0.0 0 0 ? S< Mar28 0:00 _ [bioset]
root 300 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfsalloc]
root 301 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs_mru_cache]
root 302 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-buf/sda3]
root 303 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-data/sda3]
root 304 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-conv/sda3]
root 305 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-cil/sda3]
root 306 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-reclaim/sda]
root 307 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-log/sda3]
root 308 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-eofblocks/s]
root 309 0.0 0.0 0 0 ? S Mar28 0:16 _ [xfsaild/sda3]
root 510 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-buf/sda1]
root 511 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-data/sda1]
root 512 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-conv/sda1]
root 514 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-cil/sda1]
root 515 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-reclaim/sda]
root 516 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-log/sda1]
root 517 0.0 0.0 0 0 ? S< Mar28 0:00 _ [xfs-eofblocks/s]
root 518 0.0 0.0 0 0 ? S Mar28 0:00 _ [xfsaild/sda1]
root 593 0.0 0.0 0 0 ? S< Mar28 0:00 _ [kworker/1:1H]
root 3634 0.0 0.0 0 0 ? S Mar28 0:00 _ [kworker/1:1]
root 3821 0.0 0.0 0 0 ? S 00:57 0:00 _ [kworker/u4:2]
root 3843 0.0 0.0 0 0 ? S 01:01 0:00 _ [kworker/1:0]
root 4155 0.0 0.0 0 0 ? S 03:55 0:00 _ [kworker/0:1]
root 4156 0.0 0.0 0 0 ? S 03:55 0:00 _ [kworker/u4:0]
root 4163 0.0 0.0 0 0 ? S 04:00 0:00 _ [kworker/0:2]
root 4205 0.0 0.0 0 0 ? S 04:05 0:00 _ [kworker/0:0]
root 4308 0.0 0.0 0 0 ? S 04:10 0:00 _ [kworker/1:2]
root 1 0.0 0.5 45920 6040 ? SNs Mar28 0:05 /usr/lib/systemd/systemd --system --deserialize 20
root 4183 0.1 0.5 158932 5752 ? Ss 04:05 0:00 sshd: root@pts/0
root 4186 0.0 0.2 115676 2236 pts/0 Ss 04:05 0:00 _ -bash
root 4447 0.0 0.1 155508 1944 pts/0 R+ 04:12 0:00 _ ps auxf
root 4374 0.0 0.0 110108 856 tty1 SNs+ 04:11 0:00 /sbin/agetty --noclear tty1 linux
root 4376 0.0 0.1 24256 1668 ? SNs 04:11 0:00 /usr/lib/systemd/systemd-logind
root 4379 0.1 0.2 37232 2512 ? SNs 04:11 0:00 /usr/lib/systemd/systemd-journald
root 4383 0.0 0.4 47304 4432 ? SNs 04:11 0:00 /usr/lib/systemd/systemd-udevd
dbus 4384 0.0 0.2 66304 2460 ? SNsl 04:11 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

# free -m
total used free shared buff/cache available
Mem: 991 733 145 9 112 126
Swap: 9214 4 9210

در نهایت هم پشتیبان گفتند که این مورد عادی است و دیگر در این خصوص تیکت ارسال نکنید!!!!!!!!!!
این شد که در اینجا مطرح کردم شاید از تجربه دوستان بتوانم استفاده کنم.

[morteza1200]

سلام

دلیل میتونه اورسل روی سرور اختصاصی باشه.

علاوه برا این

بنده یک سرور اختصاصی با مجازی ساز esxi داشتم و تقریبا سرور کاملا فری بود ، سر یکی از وی پی اس ها این مشکل رخ میداد! رم بی جهت پر میشد ! مجبور شدم مجازی ساز سرور اصلی رو تغییر بدم


یک سرور با مجازی ساز kvm بگیرید و این مشکلات رو فراموش کنید

[farhadhelix]

خروجی free -m چه مقداری رو نشون میده؟

[NabiKAZ]

خروجی free -m چه مقداری رو نشون میده؟

البته بالا گذاشتم، در همین لحظه هم اینطوره:

# free -m
              total        used        free      shared  buff/cache   available
Mem:            991         791          65           6         134          58
Swap:          9214           0        9214

همین دیروز که این پست رو زدم تازه ریست کرده بودم و رم تقریباً آزاد بود، تا یک ساعتی هم که مانیتور میکردم عادی بود.
امروز چک کردم بازم رم پر شده که بالا گذاشتمش.

- - - Updated - - -

حالا اگر چرایی مسئله رو کنار بگذاریم؛ چند سوال مطرحه
1- آیا این موضوع پر بودن رم در چنین سناریویی، میتونه روی عملکرد تاثیر منفی نگذاره؟! (با فرض متأثر بودن از عوامل بیرونی سرور، که ممکنه مهم نباشه)
2- اصولاً اگر فرض کنیم به هر دلیل رم خورده شده، وقتی پروسه ها این رو نشون نمیدن، چطور میشه اون رو ردیابی کرد و فهمید از کجا داره خورده میشه؟
3- آیا بجز ریست کردن راهی برای آزاد سازی رم، در چنین سناریویی وجود دارد؟

[navidz]

سلام
صحبت دوستمون در مورد oversell و مشکلات مجازی سازی قابل توجه است و بهترین راه تعویض سرویس مجازی است
شاد باشید

[farhadhelix]

دوستمون این رو هم اضافه کردن که با ریستارت مشکلشون حل میشه

اگر Oversell باشه نباید حل بشه حتی با ریستارت هم

[ULTRAWEB]

چراپارتیشن swap9گیگ هس؟!
بعدشم لینوکس عادت داره رم بخوره وقتی سیستم داره کارمیکنه کاریش نباید داشته باشی
چرا روی مقداربافر-شیر رو سیاه کردی دیده نمیشه که مقدارش

[NabiKAZ]

چراپارتیشن swap9گیگ هس؟!

آیا علتش کمکی به حل مسئله میکنه؟

بعدشم لینوکس عادت داره رم بخوره وقتی سیستم داره کارمیکنه کاریش نباید داشته باشی

نه چرا باید رم خوردن عادی باشه وقتی پروسه ای هم درگیر نیست! چی رو نباید کاری داشته باشم؟! اصلاً برنامه ای درحال اجرا نیست. لطفاً جزئیات سوال رو دقیقتر مطالعه کنید.

چرا روی مقداربافر-شیر رو سیاه کردی دیده نمیشه که مقدارش

در عکسها چیزی سیاه یا سانسور نشده است.

- - - Updated - - -

درود
vmtools روی سرویستون نصب هست ؟

راستش مطمئن نیستم، لیست همه پروسه های روی سرور رو گذاشتم به نظر میرسه چیزی در این رابطه درحال اجرا نیست.

پر شدن رم زیاد مهم نیست مهم اینه هنگ نکنه آیا هنگ میکنه ؟
اصلا ربطی به این نداره که سرورتون عوض کنید.

یعنی نظر شما اینه که پر بودن رم جنبه نمایشی داره و این روی کارایی تاثیر نمیگذاره؟!
اگر برنامه ای باشه که پر بودن رم رو بررسی کنه که خب میبینه پر هست و حتماً دچار اشکال در کارکرد خواهد شد!

- - - Updated - - -

شما به زودی به ارتقا رم نیازپیدامیکنین

ارتقا؟!!! متوجه موضوع مسئله هستید که رم بی رویه داره خورده میشه و هدف چرایی مسئله هست، یعنی اصلاً برنامه ای از رم استفاده نمیکنه که بگیم اوکی پر شده و باید ارتقا بدیم!

درضمن به نظرمن بهتره اینو هم در نظربگیرین نسخه ی مینیمال سنت او اس 7 نصب شده یا نصب ه ی کامل ایزویی که نصب کردن اگر کامل بود
مینیمال رو نصب کنین و بعدش نیازبه ارتقا هم ندارین
http://mirror.centos.jt.iq/7.8.2003/...nimal-2003.iso

مینیماله.

- - - Updated - - -

مشخصات کامل رم رو میتونید با کد زیر ببینید

less /proc/meminfo
بازهم میبینید که رم پر شده درحالی که برنامه ای یا پروسه خاصی وجود ندارد:

# cat /proc/meminfo
MemTotal:        1014980 kB
MemFree:           70972 kB
MemAvailable:      49984 kB
Buffers:               0 kB
Cached:           138676 kB
SwapCached:          284 kB
Active:           116848 kB
Inactive:          82648 kB
Active(anon):      71220 kB
Inactive(anon):    46520 kB
Active(file):      45628 kB
Inactive(file):    36128 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       9436156 kB
SwapFree:        9435132 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         60568 kB
Mapped:            23208 kB
Shmem:             56920 kB
Slab:              49016 kB
SReclaimable:      19188 kB
SUnreclaim:        29828 kB
KernelStack:        1824 kB
PageTables:         3692 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     9943644 kB
Committed_AS:     305400 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      146308 kB
VmallocChunk:   34359341052 kB
HardwareCorrupted:     0 kB
AnonHugePages:      6144 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       67520 kB
DirectMap2M:      980992 kB

اما در کل تا موقعی که مشکلی در سیستم رخ نده مشکل خاصی نیست
لینوکس اکثر مواقع رم رو میخوره و موقعی که نیاز به رم پیدا کنه خودش جا باز میکنه براش اگر امکانش باشه
اگر هنگی کرشی چیزی روی سرورتون رخ نمیده جای نگرانی فعلا نیست

بله نه تنها لینوکس هر سیستم عاملی طبیعیه که وقتی رم کم میاره از سواپ (یا حافظه های سیستم فایل جایگزین) کمک میگیره و شاید در عمل خیلی کاهش کارایی احساس نشود، اما در هر صورت این فرایند نیاز به یک پردازش مضاعف دارد که وقتی رم کافی باشد دلیلی برای آن نیست.
من بررسی کردم وقتی کار زیادی که رم میخواد انجام میدهم، بلافاصله سراغ سواپ میرود، چون رم کافی نیست. اما روی سیستم دیگر اینطور نیست و تا حد ممکن از رم استفاده میکند. خب طبیعی است که در وضعیت اول کارایی کاهش خواهد داشت.
بنابراین شاید به شکل محصوص هنگی یا اختلال عملکرد رخ ندهد اما از زاویه فنی، این پاک کردن صورت مسئله است و باید توجیح منطقی و فنی دقیق برای مسئله وجود داشته باشد!
اینکه بگیم خب حالا که فعلاً داره کار میکنه پس ولش کن! جواب کارشناسی نیست.

- - - Updated - - -

سلام، وقت بخیر
رم مصرفی vm شما داره به ماشین های دیگه به اشتراک گذاشته میشه

و فکر نمیکنید این روی عملکرد سرور مجازی میتونه تاثیر منفی بگذاره؟


**در ضمن من چندین سرور با کانفیگ یکسان دارم که فقط این اینطور است!**

[k-h]

یعنی نظر شما اینه که پر بودن رم جنبه نمایشی داره و این روی کارایی تاثیر نمیگذاره؟!
اگر برنامه ای باشه که پر بودن رم رو بررسی کنه که خب میبینه پر هست و حتماً دچار اشکال در کارکرد خواهد شد!

ماشا.. خودتون استادین
جواب همه دارید رد میکنید دیگه چه نیازی هست به این تاپیک زدن ها

دوست خوبم در مجازی ساز esxi نبودن vmtools یک مقدار کندی سرویس به دنبال داره چون سخت افزار ها با هم مچ نمیشن

در مورد پر شدن رم ما سرور داریم سنت او اس هست کل رم داره میگیره مشتری هم راحت داره استفاده میکنه بدون اینکه هنگ کنه
شما هم اگر سرویستون هنگ میکنه باید دنبال راه حل باشید اگر هم که هنگ نمیکنه نیازی به بررسی هم نیست

[blueserver]

- - - Updated - - -
و فکر نمیکنید این روی عملکرد سرور مجازی میتونه تاثیر منفی بگذاره؟


**در ضمن من چندین سرور با کانفیگ یکسان دارم که فقط این اینطور است!**

دنبال راهکار یا جواب دیگه ای نباشین، باتوجه به آشنایی به esxi خدمتتون عرض میکنم مشکلتون همین هست ، رم سرور شما داره به ماشین های دیگه که کمبود رم دارن به اشتراک گذاشته میشه، این ویژگی esxi هست و کانفیگ نادرست مجازی سازتون. ربطی به کانفیگ یکسان سایر سرورها و ... نداره، رم شما اشتراکی هست.