بعد اكتشاف إصدار 3.3.0-beta1، قمت على الفور بتحديث نسخة Discourse الخاصة بي من واجهة الويب.
ومع ذلك، أثناء عملية التحديث، توقفت سجلات واجهة الويب لمدة تزيد عن خمس عشرة دقيقة دون أي مخرجات إضافية (أتذكر أن آخر مخرج كان سلسلة من النقاط المتنامية؟ ربما، أنا غير متأكد قليلاً). بعد حوالي ساعتين، تحققت من حالة الخادم من منصة السحابة واشتبهت في أنه قد تجمد، لذلك قمت بإعادة تشغيل ناعمة من منصة السحابة.
بعد إعادة التشغيل، قمت على الفور بتشغيل نسخة احتياطية من Discourse من سطر الأوامر، وقمت بتنزيل النسخة الاحتياطية وملف app.yml محليًا، ثم قمت بإعادة تثبيت Discourse بالكامل (بالطبع، أحدث إصدار). بعد ذلك، قمت بتحميل النسخة الاحتياطية وبدأت عملية الاستعادة من سطر الأوامر.
كانت الاستعادة ناجحة، ولكن الآن تواجه Discourse الخاصة بي مشاكل أداء خطيرة. في السابق، لم يتجاوز استخدام وحدة المعالجة المركزية أثناء الاستخدام العادي 10٪، ولكنه الآن يصل إلى حوالي 30٪ حتى خلال ساعات الذروة، وقراءات القرص مرتفعة نسبيًا أيضًا. والأسوأ من ذلك، أن الخادم يتعطل أحيانًا بشكل غير مفهوم، حيث تصل قراءات القرص إلى حوالي 1900 في الثانية (هذه هي حدود خادم السحابة الخاص بي)، وتكون وحدة المعالجة المركزية أكثر من 40٪ في حالة انتظار. تفشل صفحات الويب في التحميل، وتظهر مهلات الاتصال. في الوقت الحالي، أقوم بتشغيل vmstat و top، ولكن للأسف، لم أحتفظ بالمخرجات. أتذكر أن إدخال/إخراج المبادلة كان شبه معدوم، مما يشير إلى قراءات قرص بحتة. تجاوز عدد الخيوط المحظورة 100.
أشتبه في أن هذا التحديث الفاشل قد تسبب في بعض الأضرار، ربما للبيانات داخل النسخة الاحتياطية، بدلاً من البرنامج نفسه. هل هناك أي طريقة لـ - آه، لست متأكدًا؟ - تحديث أو حذف بعض ذاكرة التخزين المؤقت أو عمليات مماثلة؟ أو ربما… تشغيل التحديث مرة أخرى؟ (بعد كل شيء، تحديثات Discourse متكررة جدًا، ويمكن تحديثها في أي وقت تقريبًا.)
كحل مؤقت، قمت بتثبيت برنامج مراقبة (watchdog) لإعادة التشغيل تلقائيًا أثناء الأحمال العالية. ومع ذلك، هذا ليس حلاً طويل الأمد في نهاية المطاف، ولم أجد مشاكل مماثلة هنا؛ من الواضح أنه ليست مشكلة في برنامج Discourse نفسه. أتساءل كيف يمكن معالجة هذا.
إذا كنت بحاجة إلى تنفيذ بعض الأوامر على الخادم للتحقق من حالته أثناء الأحمال العالية، فلا تتردد في السؤال. سأبذل قصارى جهدي للحفاظ على اتصال SSH الخاص بي والحصول على هذه البيانات دون إعادة التشغيل.
كيف تبدو طابور Sidekiq الخاص بك؟ قد يكون مجرد إعادة خبز جميع المنشورات وتهدأ الأحمال في النهاية بمجرد الانتهاء من قائمة الانتظار. أي أن الوضع يجب أن يكون مؤقتًا.
لقد حدث هذا لي عدة مرات مؤخرًا. في كل مرة قمت فيها بإعادة التشغيل يدويًا ثم قمت بإعادة بناء سطر الأوامر. من الواضح أنها ليست حلاً جيدًا على المدى الطويل وخطير.
هذه علامة على أن جهازك لم يعد لديه ذاكرة كافية. ضع في اعتبارك زيادة مساحة المبادلة للتعامل مع الارتفاعات.
أجد أنني بحاجة إلى جهاز بسعة 4 جيجابايت بالإضافة إلى 3 جيجابايت من مساحة المبادلة الآن لتنفيذ التحديثات عبر الإنترنت: كم لديك من الذاكرة؟
حسنًا… في الواقع، لم يكن يعاني من أحمال عالية جدًا بعد الاستعادة مباشرة، وهو أمر طبيعي على ما أعتقد. ولكن في حالتي، بعد انخفاض الحمل إلى حوالي 2٪ بعد الاستعادة، وعندما كنت أقوم ببعض التعديلات على الواجهة الرسومية، توقفت الصفحة فجأة عن التحميل بعد إجراء واحد. عند التحقق من منصة الخادم السحابي، كانت قراءات وحدة المعالجة المركزية والقرص مرتفعة جدًا. لا أعتقد أن هذه مشكلة في إعادة خبز جميع المشاركات.
نظرًا لأن خادمي في حالة طبيعية حاليًا، إليك واجهة Sidekiq:
لدي 2 جيجابايت من الذاكرة الفعلية و 2 جيجابايت من الذاكرة المبادلة. يبدو أن الذاكرة المبادلة تم تمكينها تلقائيًا أثناء عملية تثبيت Discourse؟ على أي حال، لم أقم بتكوينها يدويًا.
لقد أضفت يدويًا ذاكرة مبادلة ليصبح المجموع 6 جيجابايت الآن.
حسنًا، هذه هي مشكلتك.
من تجربتي الأخيرة، يبدو أن عملية تجميع الويب تستهلك موارد أكثر بكثير، ويمكنك تجربة مساحة تبديل أكبر بكثير أو الترحيل إلى خادم أكبر.
بالمناسبة، في محاولاتي السابقة لإجراء النسخ الاحتياطي عبر الواجهة الرسومية للويب، كانت السجلات تتوقف أحيانًا. الآن، أقوم بتنفيذ جميع عمليات النسخ الاحتياطي والاستعادة من سطر الأوامر (باستثناء النسخ الاحتياطي التلقائي، الذي لم يفشل أبدًا ويعمل بشكل جيد). أنا فضولي لمعرفة ما إذا كانت هذه مشكلة شائعة؟ هل هناك أمر لإجراء التحديث؟ هل يجب أن أستمر في إجراء التحديثات عبر سطر الأوامر في المستقبل؟ هل سيؤدي ذلك إلى زيادة معدل النجاح؟
في الاستخدام اليومي، ألاحظ أيضًا زيادة كبيرة في تأخير تحميل صفحات الويب مقارنة بما كان عليه الحال من قبل، ومن المحتمل جدًا ألا تكون مشكلة شبكة ولكن مشكلة أداء. إليك بيانات الأداء عند تحميل الصفحة الرئيسية:
The server freezed again. (watchdog is stopped manually to get full log without reboot) Here’s the top and vmstat output:
Note that the top output here hasn’t updated much since the server freeze, unlike vmstat, so it may not reflect the latest data.
top - 21:53:16 up 2:19, 3 users, load average: 19.20, 4.89, 1.90
Tasks: 164 total, 1 running, 163 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 7.2 sy, 0.0 ni, 0.0 id, 91.8 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 1668.6 total, 75.9 free, 1473.1 used, 119.6 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 36.8 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
92 root 20 0 0 0 0 S 2.8 0.0 0:08.01 kswapd0
2504 root 10 -10 123496 6932 0 D 1.6 0.4 2:59.44 AliYunDunMonito
90 root 0 -20 0 0 0 I 1.0 0.0 0:01.10 kworker/1:1H-kblockd
1320 root 20 0 1236124 2116 0 S 0.8 0.1 0:00.96 containerd-shim
2493 root 10 -10 87652 1744 0 S 0.6 0.1 0:44.69 AliYunDun
1008 root 20 0 1276372 2160 0 S 0.5 0.1 0:43.62 argusagent
725 root 20 0 689584 3860 0 S 0.3 0.2 0:08.16 aliyun-service
1964 message+ 20 0 74800 12512 0 D 0.3 0.7 0:19.97 redis-server
1973 www-data 20 0 56840 4872 472 D 0.3 0.3 0:01.36 nginx
2081 admin 20 0 519788 263284 4 S 0.3 15.4 0:07.88 ruby
2214 admin 25 5 5338856 495356 0 S 0.3 29.0 0:31.95 ruby
2227 admin 20 0 5246956 484488 4 S 0.3 28.4 0:33.31 ruby
2467 systemd+ 20 0 215196 15052 11348 D 0.3 0.9 0:00.45 postmaster
785 root 20 0 42256 748 0 S 0.2 0.0 0:07.58 AliYunDunUpdate
805 root 20 0 1798676 11832 0 S 0.2 0.7 0:02.24 containerd
1027 root 20 0 2281464 29296 0 S 0.2 1.7 0:01.96 dockerd
2056 systemd+ 20 0 67872 2192 0 D 0.2 0.1 0:00.39 postmaster
2243 root 20 0 17204 5068 2592 S 0.2 0.3 0:00.34 sshd
2555 root 20 0 10496 2736 1916 R 0.2 0.2 0:11.41 top
9998 admin 20 0 5057740 313028 4 S 0.2 18.3 0:04.83 ruby
11658 admin 20 0 10944 252 0 D 0.2 0.0 0:00.09 sleep
1 root 20 0 166776 6568 2808 D 0.1 0.4 0:01.42 systemd
22 root 20 0 0 0 0 S 0.1 0.0 0:00.31 ksoftirqd/1
149 root 0 -20 0 0 0 I 0.1 0.0 0:00.17 kworker/0:1H-kblockd
707 systemd+ 20 0 16260 2296 1212 D 0.1 0.1 0:00.16 systemd-network
723 root 20 0 19424 984 0 S 0.1 0.1 0:01.58 assist_daemon
1965 root 20 0 6680 280 0 D 0.1 0.0 0:00.05 cron
1974 www-data 20 0 55912 3996 472 D 0.1 0.2 0:00.98 nginx
2054 systemd+ 20 0 213244 6344 4384 S 0.1 0.4 0:02.02 postmaster
2055 systemd+ 20 0 213780 3208 924 D 0.1 0.2 0:00.12 postmaster
2270 root 20 0 17204 3880 1404 D 0.1 0.2 0:00.67 sshd
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 71456 624 134980 0 0 11302 4 2209 3766 1 1 96 2 0
0 1 0 72756 1452 132412 0 0 15250 12 2418 3969 1 2 94 4 0
0 0 0 67724 1244 137444 0 0 4485 2 2083 3700 1 1 98 1 0
0 0 0 80388 928 124660 0 0 26388 10 2650 4018 1 2 92 4 0
0 0 0 78256 696 126228 0 0 14752 6 2286 3792 1 1 95 3 0
0 0 0 72252 1680 130784 0 0 40334 41 2938 4212 1 2 89 7 0
0 0 0 74812 712 128588 0 0 15904 34 2309 3839 1 1 95 3 0
2 0 0 71120 856 132224 0 0 54282 5 3292 4382 1 3 85 10 0
0 0 0 73668 600 128232 0 0 30135 35 2795 4212 1 2 92 5 0
0 0 0 65160 1524 135636 0 0 30239 6 2842 4247 1 2 90 7 0
0 0 0 74480 1416 126484 0 0 11761 8 2254 3793 1 2 95 2 0
1 0 0 80096 1188 120752 0 0 37110 2 2907 4163 1 4 88 7 0
0 0 0 77880 688 122928 0 0 8439 5 2151 3719 1 1 97 2 0
0 8 0 76744 1256 122536 0 0 110986 14 4410 4860 1 6 34 59 0
0 13 0 71776 244 128496 0 0 126111 21 4386 4699 1 7 0 91 0
1 30 0 71860 356 127916 0 0 125040 21 4634 7331 1 7 0 91 0
3 31 0 77448 204 122688 0 0 125980 10 4167 8370 1 5 0 94 0
3 44 0 68184 168 132192 0 0 150011 0 4296 9015 0 7 0 93 0
1 44 0 74812 216 124700 0 0 204040 0 4949 10108 1 6 0 93 0
6 35 0 66588 244 133160 0 0 131782 2 6238 12786 1 7 0 93 0
1 39 0 68156 556 130996 0 0 144440 11 4608 9622 1 8 0 92 0
0 71 0 72256 212 126520 0 0 169879 12 4780 10242 1 10 0 89 0
0 91 0 66752 112 132476 0 0 542955 18 7422 17564 0 52 0 48 0
6 89 0 70324 172 129516 0 0 404754 21 6033 14379 0 52 0 48 0
3 87 0 60468 156 138060 0 0 499604 1 10640 26065 0 56 0 44 0
5 91 0 63456 152 135588 0 0 725747 11 10827 25806 0 55 0 45 0
4 101 0 69596 168 129132 0 0 558872 8 7755 18745 0 56 0 44 0
6 93 0 66516 156 132772 0 0 394003 3 12549 30622 0 54 0 46 0
4 94 0 62872 152 135976 0 0 656057 0 7790 18800 0 52 0 48 0
2 95 0 57072 156 141552 0 0 347776 0 10390 25943 0 56 0 44 0
4 97 0 66308 164 132964 0 0 641920 0 9963 24307 0 55 0 45 0
13 90 0 75620 152 123836 0 0 658883 0 7870 19260 0 55 0 45 0
2 96 0 66244 152 131496 0 0 764233 0 16078 40498 0 55 0 45 0
1 102 0 60156 224 137440 0 0 542241 0 10243 24560 0 54 0 46 0
13 90 0 62488 164 135548 0 0 671301 0 13771 34230 0 55 0 45 0
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 101 0 61812 100 136048 0 0 548615 0 10328 26305 0 55 0 45 0
2 102 0 61412 92 135928 0 0 1003845 0 17283 42751 0 56 0 44 0
8 98 0 60408 152 136896 0 0 662925 0 11369 29130 0 55 0 45 0
2 104 0 68292 152 129552 0 0 628286 0 13772 34122 0 56 0 44 0
2 99 0 65352 152 132436 0 0 494863 5 8766 21559 0 54 0 46 0
10 94 0 58344 96 138800 0 0 669390 0 9294 22968 0 56 0 44 0
3 95 0 61180 100 135444 0 0 598622 0 13342 32430 0 57 0 43 0
8 96 0 59444 160 137584 0 0 720255 0 10812 25735 0 57 0 43 0
14 89 0 66844 160 130072 0 0 665390 0 17496 43187 0 56 0 44 0
1 98 0 64668 152 132756 0 0 498328 0 7262 18622 0 55 0 45 0
1 98 0 61848 172 135060 0 0 438272 0 7693 19947 0 56 0 44 0
3 102 0 60636 152 136548 0 0 1020531 0 17162 43981 0 55 0 45 0
2 93 0 55096 164 141908 0 0 595678 0 14379 37088 0 55 0 45 0
9 100 0 61704 152 134692 0 0 368380 0 10621 27539 0 55 0 45 0
2 104 0 63784 148 132620 0 0 767905 8 11090 28866 0 56 0 44 0
2 110 0 60124 232 135636 0 0 882479 0 14778 38194 0 55 0 45 0
3 109 0 64632 156 131448 0 0 489138 0 11521 30264 0 56 0 44 0
2 107 0 65852 36 130592 0 0 1214409 0 17572 45932 0 55 0 45 0
2 97 0 60260 96 135668 0 0 559811 0 14592 37198 0 56 0 44 0
1 103 0 56064 104 139668 0 0 514522 0 11059 26834 0 57 0 43 0
7 97 0 62624 160 133492 0 0 646888 4 7819 19552 0 57 0 43 0
8 102 0 65404 152 130172 0 0 526268 0 11623 29396 0 56 0 44 0
I’ll keep the freezing state without rebooting. If you need me to execute some commands on the server to check its status during high loads, feel free to ask. I’ll do my best to maintain my SSH connection and obtain all data without rebooting.
other data from cloud server platform:
يبدو هذا مريباً - قد يكون أو لا يكون السبب. هناك شيء ما (على الأرجح) يقوم بالكثير من عمليات قراءة القرص. يبدو أن AliYunDun هي أداة مزود السحابة. من المحتمل أن يكون AliYunDunMonitor عالقاً في انتظار القرص، ويعمل بأولوية مرتفعة، وقد استهلك الكثير من وقت وحدة المعالجة المركزية.
أرى أن شخصاً ما في مكان ما قد كتب نصاً برمجياً لقتل مثل هذه العمليات. النبرة غاضبة. (لا يمكنني القول ما إذا كان هذا النص البرمجي آمناً، أو فكرة جيدة.)
ولكن من الممكن أيضاً أن تكون إحدى عمليات Discourse هي التي تقوم بكل عمليات قراءة القرص.
ربما جرب
apt-get install iotop
iotop -b -d 15 -P -o
وشاهده حتى يحدث التجمد لديك.
حسنًا، وهذا هو ناتج iotop عند التجميد:
Total DISK READ: 7.92 M/s | Total DISK WRITE: 11.70 K/s
Current DISK READ: 12.14 M/s | Current DISK WRITE: 17.29 K/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
1 be/4 root 6.12 K/s 0.00 B/s ?unavailable? init noibrs
300 be/3 root 0.00 B/s 2.93 K/s ?unavailable? [jbd2/vda3-8]
374 be/3 root 10.64 K/s 0.00 B/s ?unavailable? systemd-journald
709 be/4 systemd- 3.99 K/s 0.00 B/s ?unavailable? systemd-resolved
723 be/4 root 51.07 K/s 0.00 B/s ?unavailable? assist_daemon
725 be/4 root 856.83 K/s 272.40 B/s ?unavailable? aliyun-service
770 be/4 root 63.31 K/s 0.00 B/s ?unavailable? python3 -Es /usr/sbin/tuned -l -P
785 be/4 root 12.77 K/s 0.00 B/s ?unavailable? AliYunDunUpdate
805 be/4 root 389.98 K/s 0.00 B/s ?unavailable? containerd
1008 be/4 root 242.60 K/s 544.80 B/s ?unavailable? argusagent
1027 be/4 root 690.31 K/s 0.00 B/s ?unavailable? dockerd -H fd:// --containerd=/run/containerd/containerd.sock
1320 be/4 root 241.01 K/s 0.00 B/s ?unavailable? containerd-shim-runc-v2 -namespace moby -id 6e9880833995c5e2a295ed6571129387036824d304e09f43d5e1333ebd7fdbd5 -address /run/containerd/containerd.sock
1953 be/4 root 1906.79 B/s 0.00 B/s ?unavailable? runsvdir -P /etc/service
1962 be/4 admin 85.12 K/s 0.00 B/s ?unavailable? bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
1964 be/4 messageb 611.83 K/s 0.00 B/s ?unavailable? redis-server *:6379
1973 be/4 www-data 530.17 K/s 272.40 B/s ?unavailable? nginx: worker process
2054 be/4 systemd- 8.78 K/s 7.45 K/s ?unavailable? postgres: 13/main: walwriter
2056 be/4 systemd- 102.42 K/s 0.00 B/s ?unavailable? postgres: 13/main: stats collector
2081 be/4 admin 817.20 B/s 0.00 B/s ?unavailable? unicorn master -E production -c config/unicorn.conf.rb
2493 ?dif root 132.21 K/s 0.00 B/s ?unavailable? AliYunDun
2504 be/2 root 740.32 K/s 0.00 B/s ?unavailable? AliYunDunMonitor
45686 be/4 root 47.62 K/s 0.00 B/s ?unavailable? sshd: root@pts/0
45816 be/4 root 36.98 K/s 0.00 B/s ?unavailable? top
46146 be/4 root 357.52 K/s 0.00 B/s ?unavailable? python3 /usr/sbin/iotop -b -d 15 -P -o
46160 be/4 root 267.34 K/s 0.00 B/s ?unavailable? sshd: root@pts/2
46232 be/4 root 174.24 K/s 0.00 B/s ?unavailable? vmstat 5
51903 be/4 admin 1569.22 K/s 272.40 B/s ?unavailable? unicorn worker[0] -E production -c config/unicorn.conf.rb
51972 be/4 admin 175.84 K/s 0.00 B/s ?unavailable? unicorn worker[1] -E production -c config/unicorn.conf.rb
60365 be/4 root 272.40 B/s 0.00 B/s ?unavailable? [kworker/u4:0-writeback]
63081 be/4 root 272.40 B/s 0.00 B/s ?unavailable? [kworker/u4:4-events_unbound]
63825 be/4 systemd- 673.02 K/s 0.00 B/s ?unavailable? postgres: 13/main: discourse discourse [local] idle
64191 be/4 root 23.14 K/s 0.00 B/s ?unavailable? -bash
في الواقع، تمكنت من تعطل الموقع عن طريق تحديث الصفحة الرئيسية عدة مرات بسرعة باستخدام مفتاح F5… لذا، أعتقد أنه من المحتمل جدًا أن تكون المشكلة بالفعل في Discourse.
ناتج top الآن:
top - 13:36:47 up 18:03, 4 users, load average: 86.10, 47.87, 19.63
Tasks: 174 total, 4 running, 170 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 21.1 sy, 0.0 ni, 0.0 id, 76.3 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 1668.6 total, 69.6 free, 1413.6 used, 185.4 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 36.9 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
92 root 20 0 0 0 0 S 37.8 0.0 100:17.66 kswapd0
1320 root 20 0 1236124 2320 0 S 4.0 0.1 4:18.47 containerd-shim
1027 root 20 0 2281464 29160 0 S 2.6 1.7 2:25.38 dockerd
805 root 20 0 1798676 11844 0 S 2.5 0.7 2:28.22 containerd
2504 root 10 -10 129972 11660 0 D 2.1 0.7 27:34.39 AliYunDunMonito
90 root 0 -20 0 0 0 R 1.5 0.0 1:58.75 kworker/1:1H-kblockd
2493 root 10 -10 88144 2244 0 D 1.1 0.1 10:49.21 AliYunDun
51989 root 20 0 1318960 8980 0 S 0.8 0.5 0:46.15 snapd
1008 root 20 0 1276372 2584 0 S 0.7 0.2 11:16.56 argusagent
46146 root 20 0 22320 9516 1908 D 0.5 0.6 0:23.57 iotop
46160 root 20 0 17200 4968 2496 D 0.3 0.3 0:03.41 sshd
45686 root 20 0 17200 5188 2716 D 0.3 0.3 0:04.21 sshd
785 root 20 0 42324 876 0 S 0.2 0.1 3:41.24 AliYunDunUpdate
45816 root 20 0 10500 3352 2544 R 0.2 0.2 0:26.01 top
51903 admin 20 0 845708 458296 4 S 0.2 26.8 0:32.36 ruby
53938 admin 25 5 5285240 378040 0 S 0.2 22.1 0:33.50 ruby
723 root 20 0 19424 996 0 S 0.2 0.1 1:57.31 assist_daemon
725 root 20 0 689584 3800 0 S 0.2 0.2 3:06.25 aliyun-service
1964 message+ 20 0 74800 13944 0 D 0.2 0.8 2:51.80 redis-server
1974 www-data 20 0 57696 6136 772 R 0.2 0.4 0:36.37 nginx
1975 www-data 20 0 53508 1520 72 S 0.2 0.1 0:45.76 nginx
2053 systemd+ 20 0 213244 6952 4988 D 0.2 0.4 0:27.47 postmaster
51972 admin 20 0 5139692 329104 4 S 0.2 19.3 0:08.21 ruby
64309 systemd+ 20 0 213244 1956 0 D 0.2 0.1 0:00.15 postmaster
22 root 20 0 0 0 0 S 0.1 0.0 0:09.66 ksoftirqd/1
149 root 0 -20 0 0 0 I 0.1 0.0 0:06.26 kworker/0:1H-kblockd
1973 www-data 20 0 56576 5088 768 D 0.1 0.3 0:35.23 nginx
2052 systemd+ 20 0 213468 34408 32340 D 0.1 2.0 0:30.59 postmaster
2055 systemd+ 20 0 213780 3244 932 D 0.1 0.2 0:29.32 postmaster
2056 systemd+ 20 0 68132 2256 0 D 0.1 0.1 0:15.54 postmaster
2081 admin 20 0 585324 280488 4 S 0.1 16.4 0:57.44 ruby
ناتج vmstat أدناه:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st\n 0 0 0 80348 884 230624 0 0 538 6 1980 3661 1 1 99 0 0\n 0 0 0 78232 2780 226576 0 0 17644 20 2510 4063 3 1 93 2 0\n 3 0 0 93580 176 186012 0 0 34986 19 3329 4751 13 4 78 6 0\n 0 29 0 82988 192 177628 0 0 127805 10 4930 6456 5 7 34 54 0\n 0 30 0 85520 204 175124 0 0 120935 6 3768 6887 1 5 0 94 0\n 3 37 0 89408 232 170836 0 0 122472 35 3876 7157 1 7 0 92 0\n10 80 0 74004 220 186372 0 0 476674 36 4532 10212 0 35 0 64 0\n11 89 0 71564 160 190284 0 0 388222 0 11098 27886 0 53 0 47 0\n 0 100 0 73508 160 188484 0 0 209539 4 4726 11652 0 32 0 68 0\n```
أنا لست خبيرًا في لينكس، ولكن أليس من المفترض أن تكون عملية kswapd0 مسؤولة عن إدارة الذاكرة وتبادل الذاكرة الافتراضية؟ لماذا لديها استخدام عالي لوحدة المعالجة المركزية 'sy' عندما تكون swpd و si و so في vmstat كلها 0؟ أنا في حيرة تامة.من المريب جدًا أن لديك 2 جيجابايت من مساحة المبادلة (swap) ولكن لا يوجد استخدام لمساحة المبادلة ولا نشاط لها. أشك في إعدادات النواة (kernel) لديك. هذه هي إعداداتي - يرجى عرض جميع إعداداتك، يرجى عدم انتقاء بعضها فقط!
head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/block_dump <==
0
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
20
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/drop_caches <==
0
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugepages_treat_as_movable <==
0
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 1
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
1
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
60
==> /proc/sys/vm/user_reserve_kbytes <==
29305
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
تعديل: يرجى أيضًا تشغيل هذه الأوامر ونشر المخرجات
swapon
free
uname -a
df -T
إعجاب واحد (1)
root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/compaction_proactiveness <==
20
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
30
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: cannot open '/proc/sys/vm/drop_caches' for reading: Permission denied
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 0 0
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
0
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/page_lock_unfairness <==
5
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
0
==> /proc/sys/vm/unprivileged_userfaultfd <==
0
==> /proc/sys/vm/user_reserve_kbytes <==
50778
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_boost_factor <==
15000
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
root@iZj6cgi365ov99veqodfgnZ:~# swapon
NAME TYPE SIZE USED PRIO
/swapfile file 2G 0B -2
root@iZj6cgi365ov99veqodfgnZ:~# free
total used free shared buff/cache available
Mem: 1708636 984352 79376 38344 644908 490004
Swap: 2097148 0 2097148
root@iZj6cgi365ov99veqodfgnZ:~# uname -a
Linux iZj6cgi365ov99veqodfgnZ 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
root@iZj6cgi365ov99veqodfgnZ:~# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
tmpfs tmpfs 170864 1164 169700 1% /run
/dev/vda3 ext4 61540412 19791160 39020044 34% /
tmpfs tmpfs 854316 0 854316 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
/dev/vda2 vfat 201615 6186 195429 4% /boot/efi
tmpfs tmpfs 170860 4 170856 1% /run/user/0
overlay overlay 61540412 19791160 39020044 34% /var/lib/docker/overlay2/7754829d0ad68c8acc8b50ed96ae87d8d882a996b87fe0b6821827e527487b62/merged
شكرًا، هذا رائع. بطريقة ما تم ضبط “swappiness” لديك على صفر، وهذا على الأرجح هو سبب معظم مشاكلك.
ولكن هناك ثلاثة إعدادات تستحق الضبط الصحيح: الأول هو “swappiness” والاثنان الآخران مذكوران في تكوين نشر Discourse المتحيز لـ MKJ
/proc/sys/vm/overcommit_memory
/sys/kernel/mm/transparent_hugepage/enabled
/proc/sys/vm/swappiness
يمكنك تعيين هذه الإعدادات مرة واحدة، ولكن يجب عليك أيضًا التأكد من تعيينها عند الإقلاع - انظر منشور MJK، وتحقق من هذه الملفات قبل الكتابة فوقها.
أشك في أن شيئًا ما يحدث عند الإقلاع لتعيين “swappiness” على صفر. ربما يحاول مزود الاستضافة الخاص بك تثبيط التبديل إلى SSD. ولكن يجب أن يكون لديك مساحة تبديل، وإلا يجب عليك الترقية إلى 4 جيجابايت من ذاكرة الوصول العشوائي على الأقل.
ربما جرب
egrep -r swappiness /etc/
لمحاولة العثور على مكان تعيينه.
هناك نصائح في مكان آخر في هذا المنتدى لتعيين “swappiness” على 10 - أفضل تركه على القيمة الافتراضية 60.
إعجاب واحد (1)
عذرًا… لستُ ماهرًا جدًا في لينكس. هل يمكنك أن تعلمني تحديدًا كيفية إعداده؟
لم أقم بتغيير أي إعدادات للنظام يدويًا من قبل. ومع ذلك، أعتقد أن مزود الاستضافة قد يحد من مساحة التبديل لأن هذا الخادم يبدو أنه يعمل على قرص صلب (بالنظر إلى الحد الأقصى لـ IOPS البالغ 2 ألف).
هل يمكن أن يؤدي القيام بهذه الأشياء إلى تعديل دائم للإعدادات التي ذكرتها؟
تشغيل:
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
وتغيير vm.swapiness = 60 في /etc/sysctl.conf
الآن: (لقد قمت بإعادة التشغيل بعد تغيير جميع الإعدادات. الأوامر أدناه تم تشغيلها بعد إعادة التشغيل)
root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/compaction_proactiveness <==
20
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
30
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: cannot open '/proc/sys/vm/drop_caches' for reading: Permission denied
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 0 0
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
1
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/page_lock_unfairness <==
5
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
60
==> /proc/sys/vm/unprivileged_userfaultfd <==
0
==> /proc/sys/vm/user_reserve_kbytes <==
50778
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_boost_factor <==
15000
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
root@iZj6cgi365ov99veqodfgnZ:~# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
يبدو أنه يعمل بشكل جيد! شكراً جزيلاً لكم جميعاً على المساعدة!
إعجابَين (2)
هذا تقدم جيد! أوصي بـ
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.