تحديد عدد اليونيكورن، استخدام الذاكرة والتبديل

[RBoy]

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

لاحظت أنني قمت بتعيين عدد الـ unicorns إلى 2 فقط منذ فترة للحد من استخدام الذاكرة (وتقليل التبديل). تشغيل إصدار discourse 3.1.0

ومع ذلك، عندما أقوم بتشغيل htop أرى 20 unicorn قيد التشغيل (10 للعامل 0 و 10 للعامل 1).

ما الذي أفتقده هنا؟ لماذا لدي 20 unicorn قيد التشغيل بينما يذكر app.yml 2؟

هل هناك أي طرق أخرى لتقليل استخدام الذاكرة (على سبيل المثال، إذا قمت بتقليل db_shared_buffers إلى 128 ميجابايت، هل هناك أي آثار جانبية؟) هل يمكنني تقليل استخدام ذاكرة sidekiq؟

هذا هو vmstat 5 5

free -h

[Ed_S]

أشك في أن htop يعرض الخيوط بدلاً من العمليات - على أي حال، أرى نفس الشيء على htop كما ترى، ولكن هناك اثنين فقط من اليونيكورن وفقًا لـ

ps uaxf|egrep unicorn.?worker

أيضًا، قيمة free لدي مثل قيمتك:

# free -h
              total        used        free      shared  buff/cache   available
Mem:           985M        782M         61M         60M        141M         32M
Swap:          2.0G        992M        1.0G

بالمناسبة، رؤية بعض استخدام الـ swap ليست مشكلة بحد ذاتها. إنها عملية الـ swapping (paging) الفعلية التي تهم. جرب vmstat 5 5 وانظر إلى أعمدة si و so.

# vmstat 5 5
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 1041832  63176   5716 127408  367  325   601   393    8   10  2  1 95  2  0
 0  0 1041576  60976   5724 127408  399    0   399    21  212  653  1  1 96  2  0
 0  0 1043544  77036   2296 120688  807  803   807   837  404 1144  1  2 94  3  0
 0  0 1043288  65040   3704 129476  254    0  2292     5  255  780  1  1 96  2  0
 0  0 1048736  81936   2916 119016  762 1499   919  1565  470 1171  3  2 90  5  0

أفضل ألا أرى شيئًا فوق 1000 ولكنني لست قلقًا جدًا. أظهر تشغيل ثانٍ صورة أكثر هدوءًا:

# vmstat 5 5
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 1048452  82712   2532 120848  367  325   601   393    8   10  2  1 95  2  0
 0  0 1047684  74552   2548 124816  285    0  1049    10  230  655  2  1 95  2  0
 0  0 1046660  66556   3692 129008  196    0  1261    16  219  672  1  1 96  2  0
 1  0 1046404  65812   3700 129284   54    0    97    13  137  364  1  0 98  0  0
 0  0 1046148  65280   3700 129288   50    0    50     3  132  344  1  0 98  0  0

تعديل: مفتاح H في htop سيحول من الخيوط إلى العمليات:

  CPU[                                                       0.0%]   Tasks: 66; 1 running
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||824M/985M]   Load average: 0.19 0.12 0.05
  Swp[||||||||||||||||||||||||||||||                  1015M/2.00G]   Uptime: 52 days, 00:50:42

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
13246 1000       20   0  966M  362M  6448 S  0.0 36.8 51:01.52 unicorn worker[0] -E production -c config/unicorn.conf.rb
13237 1000       25   5 1004M  194M  3780 S  0.0 19.8 22:38.19 sidekiq 6.5.9 discourse [0 of 5 busy]
13258 1000       20   0  919M 70176  3632 S  0.0  7.0  5:02.87 unicorn worker[1] -E production -c config/unicorn.conf.rb
12412 systemd-r  20   0  212M 60928 56916 S  0.0  6.0  0:00.23 postgres: 13/main: discourse discourse [local] idle
12818 systemd-r  20   0  212M 39228 34868 S  0.0  3.9  0:00.07 postgres: 13/main: discourse discourse [local] idle
12719 systemd-r  20   0  211M 28400 25336 S  0.0  2.8  0:00.03 postgres: 13/main: discourse discourse [local] idle
13117 1000       20   0  541M 13768  2048 S  0.0  1.4  1:08.11 unicorn master -E production -c config/unicorn.conf.rb

تعديل: لقد قمت بتعيين db_shared_buffers: "128MB" في وقت مبكر جدًا، ولم أواجه أي مشكلة مع ذلك.

[RBoy]

شكرا، مفيد جدا. ما هو العيب في الانتقال إلى عامل unicorn واحد فقط؟ هل سيؤدي ذلك إلى تحسين وقت الاستجابة أم تفاقمه (هل يقتصر عامل unicorn واحد على اتصال وارد واحد، أي هل سيجعل عاملان معالجة اتصال وارد واحد أسرع؟)، بافتراض أن لدي اتصالات قليلة فقط في الدقيقة؟

عندما أتصفح الموقع، هذا ما يبدو عليه vmstat 5 5، أي اقتراحات لتقليل التبديل (لقد قمت بتعيين swappiness على 10)؟

تعديل: هل هناك أي طريقة لتقليل استخدام ذاكرة sidekiq دون التأثير على الأداء؟

[Ed_S]

بالتأكيد يبدو أن موقعك سيكون أسرع إذا كان لديك المزيد من ذاكرة الوصول العشوائي (RAM). ولكن إذا لم يكن وقت الاستجابة مشكلة، فلا توجد مشكلة. فقط انظر إلى معادلة التكلفة/الفائدة الشخصية الخاصة بك.

قد تكون مهتمًا بقراءة تكوين نشر Discourse الرأي لـ MKJ. هناك عدد قليل من التعديلات على نواة النظام التي تعتبر فكرة جيدة. لا أعرف ما إذا كانت ستحدث فرقًا أم لا.

لا أعرف، لكن أعتقد أن كل “يونيكورن” (unicorn) يمكنه التعامل مع طلب واحد. لذلك إذا كان لديك “يونيكورن” واحد فقط، وحركة مرور كافية لطلب ثانٍ قبل اكتمال الطلب الأول، فسيتعين على هذا الطلب الثاني الانتظار. يمكنك أن ترى من مخرجات htop الخاصة بي أن “يونيكورن” واحد قد استهلك وقت معالجة (CPU) أعلى بـ 10 مرات من الآخر. أود أن أفسر ذلك على أن منتدى الخاص بي يحتاج في 90٪ من الوقت إلى “يونيكورن” واحد فقط، وفي 10٪ من الوقت يكون “اليونيكورن” الثاني مفيدًا. لا أشعر بالحاجة إلى إضافة “يونيكورن” ثالث، وقد لا يكون الأمر ذا أهمية كبيرة لأعضاء منتدى الخاص بي إذا انتقلت إلى “يونيكورن” واحد. لكنني لا أرى سببًا لذلك: قد يستهلك الذاكرة، ولكن إذا كان خاملاً فسيتم تبديله (swapped out). لا مشكلة كبيرة: دع نظام الذاكرة الافتراضية يتعامل مع الأمر.

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

[nordize]

إذا قمت بتغيير db_shared_buffers و UNICORN_WORKERS، فهل هناك طريقة لإعادة التشغيل فقط دون إعادة البناء عبر ./launcher rebuild app؟