استخدام الذاكرة يتزايد تدريجيًا بعد إعادة التشغيل

تثبيت
1

لست متأكدًا متى بدأ الأمر، ولكن في مرحلة ما خلال الأسابيع القليلة الماضية، يُفترض أنه بعد تحديث Discourse، بدأ الموقع يشعر بالبطء قليلاً. نحن نعمل على الإصدار 3.4.0.beta2-dev.

لاحظت أن مثيل الخادم كان لديه ذاكرة حرة قليلة جدًا، لذلك قمت بإعادة تشغيله. بعد بدء تشغيل Discourse، كان استخدام الذاكرة جيدًا في البداية (حوالي 1.2 جيجابايت)، ولكنه بدأ في الزيادة، ويبدو أنه سيصل قريبًا إلى نقطة يصبح فيها بطيئًا مرة أخرى.

الموقع ليس مزدحمًا بشكل خاص (20 إلى 30 زائرًا يوميًا)، وكان يعمل بشكل جيد لسنوات عديدة، حتى وقت قريب.

يحتوي مثيل الخادم على 2 جيجابايت من الذاكرة، والتي يجب أن تكون كافية وفقًا للمتطلبات التي رأيتها (1 جيجابايت كحد أدنى؛ 2 جيجابايت موصى بها).

يبدو الأمر أشبه بتسرب في الذاكرة بالنسبة لي. بالطبع، إذا كان هناك تسرب، فقد لا يكون Discourse، بل Docker أو شيء آخر. يتم استخدام المثيل لـ Discourse فقط.

أي أفكار؟ هل هناك طريقة للتحقق من أنه تسرب، وتحديد العملية المتسربة؟

2

مفهوم الذاكرة الحرة زلق للغاية - العلامة المؤكدة الوحيدة لقلة الذاكرة هي نشاط الترحيل.

free
أو
free -h
سيعطيك لقطة

vmstat 5 5
مفيد جدًا لمعرفة كيفية سير الأمور، بما في ذلك نشاط الترحيل.

إعجابَين (2)
3 
              total        used        free
Mem:          1.9Gi       1.5Gi        73Mi
Swap:         2.0Gi        54Mi       1.9Gi

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  55524 111624  20080 385060    1    3    68    52  965  349  4  2 93  1  0
 0  0  55524 114884  20088 385152    0    0    13     8 1047  352  2  1 96  0  0
 0  0  55524 112428  20088 385160    0    0     0     3  831  319  3  1 95  0  0
 0  0  55524 111616  20096 385164    0    0     0    51  688  278  2  0 97  0  0
 0  0  55524 109884  20104 385168    0    0     0     8 1117  281  2  1 96  0  1

هل يبدو أي مما سبق مشكلة؟ أحصل على أرقام استخدام الذاكرة من HTOP، والتي تبدو متوافقة مع FREE.

شاغلي الرئيسي هو الطريقة التي يستمر بها استخدام الذاكرة في النمو. أتوقع أن يصل إلى نقطة معينة ثم يحوم حولها، صعودًا وهبوطًا مع استخدام الموقع. الاتجاه التصاعدي الثابت مقلق.

4

بالتأكيد، هذا يبدو جيدًا في الوقت الحالي - لا يوجد نشاط في si و so، وهو الترحيل، وأيضًا حركة مرور قرص قليلة جدًا، وهي bi و bo.

ما يفعله لينكس هو استخدام الذاكرة المجانية للتخزين المؤقت للقرص، لذلك ليس من السيئ رؤية الذاكرة المجانية تنخفض. يعرض خرج free ذاكرة الوصول العشوائي المتاحة، وتقول الصفحة الدليلية:

available
تقدير لمقدار الذاكرة المتاحة لبدء تطبيقات جديدة، دون التبديل.

في حالة vmstat، تكون أعمدة buff و cache هي الذاكرة المستخدمة للتخزين المؤقت للقرص وقد تنمو لتحسين أداء الإدخال/الإخراج، ولكنها تتقلص عندما يكون هناك ضغط على الذاكرة. لذلك، لكل من free و vmstat، فإن مقدار “free” هو مقياس متشائم.

إعجاب واحد (1)
5

حسنًا، شكرًا لك. ربما لم تكن البطء متعلقة بما بدا أنه وضع ذاكرة منخفض. سأستمر في مراقبة هذا.

إعجاب واحد (1)
6

لا يزال من الممكن أن يزداد شيء ما تدريجيًا.

هذه إحدى تكتيكاتي لمعرفة ما يحدث:

# ps aux|sort -n +5|tail
systemd+    1659  0.0  1.3 904384 54588 ?        S    16:44   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
root         830  0.0  1.6 2253324 65208 ?       Ssl  16:44   0:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
systemd+    1682  0.0  1.9 904516 78092 ?        Ss   16:44   0:01 postgres: 13/main: checkpointer 
systemd+    18757  0.1  2.1 912368 85644 ?        Ss   18:06   0:00 postgres: 13/main: discourse discourse [local] idle
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]

(أو ps auxc)

إعجابَين (2)
7

إذا كان من السهل مراقبة نشاط وحدة المعالجة المركزية (CPU) و (القرص) I/O، فإنني أوصي بمراقبة هذه الأنشطة بدلاً من استخدام الذاكرة. خاصة I/O. إذا كانت وحدة المعالجة المركزية منخفضة و I/O مرتفعًا، وكان المنتدى بطيئًا، فقد يشير ذلك إلى نقص مؤثر في ذاكرة الوصول العشوائي (RAM).

8

هناك عدد قليل من الأسباب، بخلاف وجود خطأ، لجعل الموقع بطيئًا: أحدها هو الزيادة التدريجية في عدد المستخدمين، ونشاط المستخدمين، وحجم قاعدة البيانات؛ والآخر هو أن Discourse يزداد حجمًا مع تطوره، ويضيف ميزات، ويحدث مكونات البرامج.

ولكن من الجدير مراقبة الاستجابة، وما إذا كانت الآلة الحالية بالحجم المناسب.

(على سبيل المثال، لاحظت أن أرخص آلة لدى Hetzner تحتوي الآن على 4 جيجابايت من ذاكرة الوصول العشوائي، بنفس السعر الذي كانت عليه الآلة الأرخص غير المتوفرة الآن والتي تحتوي على 2 جيجابايت من ذاكرة الوصول العشوائي. لا يزال أحد مواقعي يعمل على الحجم الأقدم بسعة 2 جيجابايت.)

للتسجيل، نظرًا لأنني كنت أتابع استخدام موقعي الرئيسي، فقد تم نقله مؤخرًا والخادم جديد وتمت إعادة تشغيله حديثًا، سأدرج بعض النتائج. إنها كمية كبيرة من البيانات - لا تتردد في عدم دراستها!

الحالة الحالية للآلة هي

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360

لاحظت أنه عند تسجيل الدخول، تعلن الآلة
Memory usage: 45%
وهو ما يعكس بشكل وثيق عمود “used” (المستخدم)، وليس عمود “free” (المتاح).

لقد كنت آخذ قراءات دورية من الأوامر التالية

   date
   uptime
   free
   ps aux|sort -n +5|tail
   vmstat 5 5

وما رأيته هو أن الذاكرة “المتاحة” تم استبدالها بذاكرة “buffer” (مخزن مؤقت) و “cache” (ذاكرة تخزين مؤقت)، دون زيادة بصمة ذاكرة الوصول العشوائي للعمليات (RSS). أعتقد أن هذا يوضح لماذا ليس من الجيد تتبع الذاكرة “المتاحة”، حتى لو جعل بعض مزودي الاستضافة هذا الأمر سهلاً. أعتقد أيضًا أنه يوضح، في هذه الحالة، عدم وجود تسرب في الذاكرة.

بعد فترة وجيزة من إعادة التشغيل، أرى هذا:

# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1560508      996400      179712     1348436     1974692
Swap:        4194288           0     4194288

وبعد فترة وجيزة

# ps aux|sort -n +5|tail
...
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0      0 866112 314288 1083816    0    0    32    28  484  621  4  1 95  0  0

ترى أن sidekiq (435 ميجابايت) والـ unicorns (330-350 لكل منها) هي أكبر العمليات.

بمرور الوقت، تنخفض الذاكرة المتاحة ثم استخدام ذاكرة sidekiq (RSS)، ويفترض أن ذلك بسبب تبديلها إلى القرص، دون تأثير غير مرغوب فيه - الآلة لا تظهر أي نشاط تبديل إلى القرص. لصالح زيادة مساحة المخزن المؤقت والذاكرة المؤقتة، أعتقد.

# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0      0 679764 326988 1190840    0    0     0    11  285  396  1  1 98  0  0

بعد حوالي 14 ساعة:

# uptime
 10:12:06 up 17:27,  1 user,  load average: 0.04, 0.02, 0.00
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.6 5647908 377424 ?      Sl   Sep05  12:42 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.8 11.3 6431988 444184 ?      SNl  Sep05  18:51 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0   2048 199972 342480 1576156    0    0     0    17  361  511  2  2 96  0  0

لاحقًا…

# uptime
 19:52:00 up 1 day,  3:07,  1 user,  load average: 0.02, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.8 5654308 382944 ?      Sl   Sep05  20:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.5 11.1 6431668 436340 ?      SNl  Sep05  25:04 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0   2304 103356 301632 1690136    0    0     0    10  360  511  1  1 98  0  0

لاحقًا…

# uptime
 12:13:09 up 1 day, 19:28,  2 users,  load average: 0.05, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.1 5654820 358612 ?      Sl   Sep05  31:47 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.3 10.0 6431668 393584 ?      SNl  Sep05  35:08 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 284416 281596  77904 1908528    0    0     0    38  315  450  1  1 98  0  0

لاحقًا

# uptime
 13:26:42 up 2 days, 20:42,  1 user,  load average: 0.20, 0.06, 0.02
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789072 365720 ?      Sl   Sep05  51:54 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.2 10.0 6433332 393472 ?      SNl  Sep05  50:44 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 242944  82016  95188 2082180    0    0     0   131  332  488  1  1 98  0  0

لاحقًا

# uptime
 09:21:33 up 3 days, 16:36,  1 user,  load average: 0.13, 0.10, 0.03
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1618936      323032      476664     1963376     1619208
Swap:        4194288      250112     3944176
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789200 363572 ?      Sl   Sep05  67:02 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.1  9.6 6433652 377472 ?      SNl  Sep05  63:14 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 250112 321888  56052 1906672    0    0     2    13  293  420  1  0 99  0  0

لاحقًا

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360
# ps aux|sort -n +5|tail
...
1000        1971  1.1  9.5 6434676 371648 ?      SNl  Sep05  80:49 sidekiq 6.5.12 discourse [0 of 5 busy]
1000        2006  1.2  9.5 5658468 373404 ?      Sl   Sep05  88:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 1  0 252928 101040  86736 2082372    0    0     0    10  333  482  1  0 99  0  0
9

شكراً لمشاركة ملاحظاتك. أرى نفس الشيء تقريباً، باستثناء أننا نستخدم نسخة بحجم 2 جيجابايت، لذا هناك مساحة أقل. شكراً أيضاً على الإشارة إلى أن بعض مقاييس الذاكرة “المتاحة” و"المستخدمة" ليست مفيدة بالضرورة.

عندما قمت بإعادة تشغيل النسخة آخر مرة قبل بضعة أيام، كان استخدام الذاكرة الأولي 1.23 جيجابايت. منذ ذلك الحين، ارتفع تدريجياً، وهو الآن عند 1.8 جيجابايت. الموقع لا يزال سريع الاستجابة بشكل معقول، في الوقت الحالي.

الموقع لا يضم الكثير من المستخدمين في الواقع، ولم يكن هناك أي زيادة حديثة في تسجيلات المستخدمين أو نشاطهم. في الشهر الماضي، كان هناك حوالي 20 موضوعاً جديداً، وحوالي 100 مشاركة، وحوالي 4 مستخدمين نشطين يومياً.

سأستمر في مراقبة الأمور، وسأنشر هنا إذا وصلت ذاكرة النسخة إلى الحد الأقصى مرة أخرى، أو أصبح الموقع بطيئاً مرة أخرى، أو كليهما.

إعجاب واحد (1)
10

أصبحت ترقية Discourse مهمة شاقة بسبب مشاكل الذاكرة، لذا قمنا أخيرًا بترقية الجهاز الافتراضي من 2 جيجابايت إلى 4 جيجابايت. ومنذ ذلك الحين، استقر استخدام الذاكرة.

إعجابَين (2)