استخدام غير عادي لوحدة المعالجة المركزية

الدعم
7

هذا لا يبدو لي كمشكلة ذاكرة - هناك حوالي 6 غيغابايت فقط مستهلكة بواسطة التطبيقات. هناك الكثير من القراءة تحدث، والتي أخمّن (إلى جانب انشغال sidekiq) ربما يقوم postgres بالكثير من قراءة البيانات القديمة من القرص، ربما لإجراء بعض مهام الإحصائيات. إذا كانت قاعدة البيانات لا تتسع في ذاكرة الوصول العشوائي (RAM)، فمن المحتمل أن تقوم بالكثير من القراءة إذا تم الوصول إلى تلك البيانات الأقدم. هذا ما تبدو عليه الرائحة.

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
admin    2510013 15.8  1.6 7383364 514764 ?      SNl  12:55  56:45 sidekiq 7.3.9 discourse [3 of 5 busy]
systemd+ 2848301 26.9 25.3 8058104 7806820 ?     Rs   17:45  18:18 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2870880  4.3 22.9 8058516 7072000 ?     Ds   18:03   2:09 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2875058 21.0 25.4 8101952 7848140 ?     Rs   18:07   9:46 postgres: 13/main: discourse discourse [local] UPDATE
systemd+ 2924006 30.2 25.3 8112844 7824292 ?     Rs   18:44   2:44 postgres: 13/main: discourse discourse [local] UPDATE
jystemd+ 2929546 12.8 24.9 8049520 7694404 ?     Ss   18:48   0:39 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2931802 17.7 24.5 8045744 7559492 ?     Ss   18:50   0:36 postgres: 13/main: parallel worker for PID 946796
systemd+ 2931803 17.7 24.5 8045744 7557568 ?     Ds   18:50   0:36 postgres: 13/main: parallel worker for PID 946796

أود أن ألقي نظرة على sidekiq أولاً - أراهن أنه مشغول بتشغيل التحديثات. تحقق من عنوان /sidekiq أثناء تسجيل الدخول كمسؤول لترى ما يفعله. من المحتمل أن يعرض لك بعض مهام التحديث طويلة الأمد.

يمكنك أيضًا، على خادم SQL:

SELECT pid, application_name, query
FROM pg_stat_activity
WHERE state IS NOT NULL
  AND state != 'idle';

لمعرفة الاستعلامات التي تعمل وما الذي يستدعيها. سيعطي ذلك تلميحًا حول ما يسبب الحمل.

هل لديك تمكين رؤوس الأداء؟ يمكنك تشغيلها والتقاطها في السجلات لإخبارك بمقدار الوقت الذي يقضيه Discourse في كل جزء.

3 إعجابات