أصبح تثبيت Discourse أبطأ وأبطأ وأبطأ

تثبيت
1

لقد أصبح تثبيت Discourse الخاص بي أبطأ وأبطأ وأبطأ خلال الأسابيع القليلة الماضية. في الماضي، عندما حدث هذا، كان إعادة بناء التطبيق يساعد. ومع ذلك، لا يبدو أنه يساعد الآن.

لقد بحثت عن نصائح في هذا المنتدى، وجربت بعض تحسينات قاعدة البيانات (vacuum full verbose، rebuild index، vacuum analyze verbose)

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

إذا استمر هذا، فسيصبح المنتدى غير قابل للاستخدام تمامًا في النهاية. أي فكرة من أين أبدأ البحث؟

3 إعجابات
2

ما هو حجم قاعدة بياناتك؟ كم لديك من ذاكرة الوصول العشوائي؟

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

قد يكون خرج الأمر التالي مفيدًا هنا:

vmstat 5 5

(قم بتشغيله في وقت حدوث المشكلة!)

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

الذاكرة المتوفرة: (من top)

iB Mem :  4041756 total,   108980 free,  3834244 used,    98532 buff/cache
KiB Swap:  1949692 total,   972196 free,   977496 used.    31140 avail Mem

Vmstat output: (while trying to load things, which is working very very slowly)

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 9  2 1011424 108300  15308 122392   37   32   145   101    0    0  2  3 93  1  0\n 5  2 1028312 114696   9976 101252 2104 3904  2176  3915  340 1939 41 38  1 19  0\n 2  4 1054116 115892  10196 102260 1378 6803  4171  6826  870 1812 23 28  1 48  0\n 0  4 1011420 257496  10860 108464 3427 3937  6223  3969  829 2788 15 28  2 55  0\n 6  2 1001844 154328  12988 120800 4366  124  7166   161  742 2947 14 26  2 58  0\nhubbe@tymin:~$ vmstat 5 5\nprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st\n 1  4 1004748  85768  13948 114648   37   32   145   101    0    0  2  3 93  1  0\n 0  6 1033260 108584  10212 101668 1566 6661  4368  6807  497 1990 11 27  0 61  0\n12  7 1050808  99524  10708  94852 1932 4551  4854  4625  660 2263 24 32  2 42  0\n 5  8 1078776 125060   9136  92948 2079 6963  5541  7030  771 2040 17 32  0 51  0\n 4  3 1004784 168216  10164 103420 2631 1457  4970  1467  617 2136 34 38  1 27  0\n```

ملاحظة: موقعي متاح هنا إذا كان ذلك يساعد: https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
How big is your database?
[/quote]

كيف يمكنني التحقق؟
إعجاب واحد (1)
5

هل Discourse هو الشيء الوحيد على هذا الخادم؟ كم عدد الـ unicorns التي قمت بتعيينها في ملف app.yml؟

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

ليس هذا هو الشيء الوحيد، ولكنه بالتأكيد أكبر شيء.

إليك أهم العمليات حسب استخدام الذاكرة:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                       
 1818 hubbe     20   0  910068 159724  10272 S   0.0  4.0   0:31.17 ruby                                                                          
 6141 hubbe     25   5 1195492 140180  10080 S   4.2  3.5  11:31.61 ruby                                                                          
 1845 hubbe     20   0  908732 124036   9388 S   2.8  3.1   0:29.94 ruby                                                                          
 1780 hubbe     20   0  910076  82072   3796 S   0.0  2.0   0:28.40 ruby                                                                          
 1937 systemd+  20   0  360060  25632  21076 S   0.0  0.6   0:00.86 postmaster                                                                    
 2134 systemd+  20   0  356020  23608  19760 S   0.0  0.6   0:00.13 postmaster                                                                    
 1797 systemd+  20   0  355840  22620  19404 S   1.4  0.6   0:00.75 postmaster                                                                    
 2092 systemd+  20   0  356288  21644  17584 S   0.0  0.5   0:00.17 postmaster                                                                    
 2063 systemd+  20   0  355984  18364  16504 S   0.0  0.5   0:00.20 postmaster                                                                    
 1939 systemd+  20   0  355904  15668  15232 S   0.0  0.4   0:00.25 postmaster                                                                    
 2131 systemd+  20   0  353948  14804  13000 S   0.0  0.4   0:00.02 postmaster                                                                    
38770 root      20   0  689760  12940      0 S   0.0  0.3 434:00.34 dockerd                                                                       
43876 root      20   0   16492   9428   1608 S   0.0  0.2   3:34.89 roxen                                                                         
 5728 hubbe     20   0  574796   8136   2064 S   0.0  0.2   0:58.94 ruby                                                                          
37533 root      20   0  593420   5848   1020 S   2.8  0.1 539:40.11 containerd                                                                    
 5689 systemd+  20   0   96432   5832   1672 S   0.0  0.1   3:54.43 redis-server                                                                  
 2196 www-data  20   0  166248   4924   2580 S   0.0  0.1   1:18.03 nginx                                                                         
 2197 www-data  20   0  165972   4484   3168 S   0.0  0.1   1:29.32 nginx
7

كل شيء تقريبًا في هذه القائمة، باستثناء roxen، يتعلق بالخطاب.

8

تم التعليق على UNICORN_WORKERS في ملف app.yml الخاص بي

9

يبدو أن حفظ منشور عرضة بشكل خاص للانتهاء وفشل المهلة.
لست متأكدًا مما إذا كان هذا أي نوع من الأدلة حول ما يحدث.

10

يشير خرج vmstat هذا إلى أنه - في الوضع الحالي - لا توجد ذاكرة وصول عشوائي (RAM) كافية.

قد يكون Discourse يعمل كما ينبغي، وكل شيء على ما يرام، ولكن بياناتك قد نمت لدرجة أن 4 جيجابايت من ذاكرة الوصول العشوائي لم تعد كافية.

أو قد يكون هناك خطأ ما ويتم استخدام الكثير من ذاكرة الوصول العشوائي التي لا ينبغي استخدامها.

أحد مقاييس الحجم هو أخذ نسخة احتياطية - بدون المرفقات - ومعرفة حجمها.

قد يعطي mini-profiler تلميحًا حول إجراءات قاعدة البيانات التي تستغرق وقتًا طويلاً.

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

5 إعجابات
11

هذا في صلب الموضوع.

إذا لم تتمكن من تحمل تكلفة ذاكرة وصول عشوائي إضافية، يمكنك محاولة تعيين قيم أقل لـ db_shared_buffers (مثل 128 ميجابايت أو أقل) وتحديد UNICORN_WORKERS إلى 2 فقط في الوقت الحالي، حيث تحتاج إلى إيقاف التبديل في أسرع وقت ممكن.

3 إعجابات
12

62.5 ميجابايت

ذاكرة الوصول العشوائي (RAM) الإضافية باهظة الثمن من مزود الاستضافة الخاص بي، لذا سأستكشف خيارات أخرى أولاً. (وأنا قلق من أن تغييرها سيكسر سعري المضمون…)

لقد غيرت db_shared_buffers إلى 128 ميجابايت و UNICORN_WORKERS إلى 2.
هل launcher app stop / start كافٍ لجعل هذه الإعدادات تسري المفعول؟

ما هو المصغر (mini-profiler)، وكيف أستخدمه؟

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

باستخدام Alt+P على لوحة المفاتيح، ستؤدي إجراءات المنتدى اللاحقة إلى عرض سلسلة توقيت أسفل لافتة المنتدى مباشرةً (بالنسبة لي، على اليمين) وإذا نقرت على التوقيت، سترى نافذة منبثقة تحتوي على بعض الإحصائيات.

هذا تقريبًا نفس حجم جهازي، يعمل بذاكرة وصول عشوائي (RAM) بسعة 1 جيجابايت. لدي 2000 موضوع، 15000 مشاركة، وأكثر من 500 تسجيل.

ما هو تاريخ Discourse الخاص بك؟ أتذكر بشكل خافت وقتًا في الماضي كان من المفترض فيه إنشاء فهرس لبعض الجداول لأسباب تتعلق بالأداء.

ماذا عن الإضافات؟ هل يمكنك تشغيل الإجراءات في الوضع الآمن لمعرفة ما إذا كانت تعمل بشكل أسرع؟

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

قد يكون من المفيد أيضًا لصق شجرة العمليات الكاملة الخاصة بك:

ps auxf

لقد نشرت شجرة العمليات الخاصة بي هنا
طلب المساعدة لتثبيت discourse

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

هل هناك مكان سهل للعثور على مثل هذه الإحصائيات؟
معظم الإحصائيات التي أراها تُظهر لي ما حدث في اليوم أو الأسبوع الماضي، ولكن لا توجد إجماليات.

لست متأكدًا مما تقصده بالتاريخ. لكنني بدأته في مارس 2021.

الانطباع الأول هو أن الوضع الآمن ليس أسرع. سألعب به ومع أداة mini-profiler لمعرفة ما إذا كان هذا الانطباع صحيحًا.

مرفق ناتج ps auxf.
auxf.txt (20.1 KB)

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

في صفحة /about، يوجد عمود لجميع الأوقات.

يبدو أن جهازك لم تتم إعادة تشغيله لأكثر من عام - ربما يستحق القيام بذلك، وتحديثه للأمان في نفس الوقت. من الممكن أن يساعد إعادة التشغيل.

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

أعتقد أنني لاحظت أن خادمك مُعد لاستخدام hypervisor بينما خادمي مُعد لاستخدام lxc. لا أعرف ما إذا كان ذلك مهمًا. (يُظهر نظامي عملية /usr/bin/lxcfs والتي لا تظهر في نظامك، ويُظهر نظامك عملية hv_vss_daemon والتي لا تظهر في نظامي.)

أيضًا، ربما يمكنك مشاركة مخرجات df -T و swapon.

18

1.3 ألف موضوع، 24.7 ألف مشاركة، 631 تسجيل، 7.1 ألف إعجاب

إعادة تشغيل أجهزة لينكس لا تساعد عادةً في أي شيء، لكنني أفترض أنه يمكنني المحاولة.

19

أتفق مع موقف متشكك بشأن هذا! لكنني لا أقترح ذلك بلا جدوى - أنا متأكد من أننا رأينا حالة لنظام يعمل لفترة طويلة تحسن مع إعادة التشغيل. (تعديل: هنا، على الرغم من أنها كانت حالة مختلفة.)

20

هذا ما قاله الـ mini-profiler عند حفظ منشور:

استغرق الأمر حوالي 30 ثانية.