يا روبرت،
لقد انتقلنا إلى خادم افتراضي خاص جديد بـ 4 أنوية (Ryzen 9 5950x)،
لا يزال استخدام وحدة المعالجة المركزية يقارب 100٪. أنا حقًا لا أعرف ما الخطأ.
ظننت أنك ستنتقل إلى خادم Scaleway ذي 8 نوى؟
ما هي النطاق الترددي المزعوم لهذا الخادم؟ أتساءل عما إذا كان النطاق الترددي المنخفض يمكن أن يسبب بطء الاتصالات/الانقطاعات لتصبح عنق الزجاجة؟
تمتلك Scaleway خوادم افتراضية خاصة بنطاقات ترددية تبلغ مئات الميجابت في الثانية، وليس 30.
يبدو 30 منخفضًا للغاية بالنسبة لي.
هذه هي المواصفات.
4096 ميجابايت DDR3 ECC RAM
4 نواة معالج افتراضية (3.4+ جيجاهرتز E3-1231 v3/1241 v3/1240 v5)
200 جيجابايت Raid 10 HDD تخزين
5 تيرابايت نطاق ترددي @ 1 جيجابت/ثانية (السرعة محدودة إلى 5 ميجابت/ثانية بعد استهلاك الحصة المخصصة)
1 IPv4، /64 IPv6
20 جيجابت/ثانية حماية TCP DDoS، ترقية متاحة إلى 200 جيجابت/ثانية
سياتل، واشنطن، الولايات المتحدة الأمريكية
لوحة تحكم Virtualizor
غير مُدار
بسبب فارق التوقيت، اخترنا أخيرًا مزود خدمة السحابة هذا. لقد قاموا بتحسين الشبكة للزوار من بلدنا.
بالمناسبة، ناتج htop هو
استخدام وحدة المعالجة المركزية بنسبة 100٪ غير طبيعي.
كل شيء على ما يرام باستثناء الحمل واستخدام وحدة المعالجة المركزية.
هل هناك أي شيء غريب في سجلات الوصول؟
يبدو الآن أن الأمور تهدأ.
نعتقد أن الاستعادة من نسخة احتياطية تسبب زيادة في استخدام وحدة المعالجة المركزية.
على أي حال، شكراً جزيلاً لك يا روبرت!
إعجابَين (2)
نعم، هذا سيحل المشكلة!
هممم، يجب أن تستهدف أقراص SSD
إعجابَين (2)
اكتشاف رائع يا بنيامين!
تمتلك Scaleway وغيرها أقراص NVMe SSD. أفضل بكثير!
قد يكون المعالج ينتظر القرص.
إعجاب واحد (1)
عذرًا، لقد قمت للتو بلصق مواصفات خاطئة.
المواصفات هي
4096 ميجابايت DDR4 ECC RAM
4 نواة معالج افتراضية (3.4 جيجاهرتز AMD Ryzen 5950X)
100 جيجابايت تخزين NVMe SSD بنظام RAID
5 تيرابايت نطاق ترددي @ 10 جيجابت/ثانية (السرعة محدودة إلى 5 ميجابت/ثانية بعد استهلاك الحصة المخصصة)
1 IPv4، /64 IPv6
حماية DDoS عبر TCP بسرعة 20 جيجابت/ثانية، ترقية متاحة بسرعة 200 جيجابت/ثانية
سياتل، واشنطن، الولايات المتحدة الأمريكية
لوحة تحكم Virtualizor
غير مُدار
إنها NVMe. 
3 إعجابات
أعتقد أنه من الممكن أن تكون الإضافات التي قمنا بتثبيتها قد زادت من الحمل.
لقد أحدثت الإضافة تغييرًا في نموذج المستخدم بحيث عندما ننتقل إلى مسار الاكتشاف، نقوم دائمًا بحساب نقاط نموذج المستخدم في نموذج الموضوع عدة مرات.
add_to_class(:user, :total_earned_points) do
self.user_points.sum(:reward_points)
end
add_to_class(:user, :available_points) do
self.total_earned_points - self.user_rewards.sum(:points)
end
add_to_class(:user, :rewards) do
DiscourseRewards::Reward.where(created_by_id: self.id)
end
add_to_serializer(:basic_user, :total_earned_points) do
user&.total_earned_points
end
add_to_serializer(:basic_user, :available_points) do
user&.available_points
end
add_to_serializer(:current_user, :total_earned_points) do
scope.user.total_earned_points
end
add_to_serializer(:current_user, :available_points) do
scope.user.available_points
end
add_to_serializer(:current_user, :user_rewards) do
scope.user.user_rewards
end
add_to_serializer(:current_user, :rewards) do
scope.user.rewards
end
ظننت أنك قلت أنك قمت بإزالة جميع الإضافات وأنها كانت تتصرف بنفس الطريقة؟
هل لهذا فهرس؟
كم عدد الصفوف في جدول user_rewards؟ من المثير للاهتمام أنه لا يميز حسب المستخدم… (لكنني أفترض أنه يجب أن يكون بطريقة ما تحت هذا المستوى).
أخشى أن هذا لا يقوم بتعيين فهرس.
النموذج موضح أدناه.
module DiscourseRewards
class Reward < ActiveRecord::Base
self.table_name = 'discourse_rewards_rewards'
has_many :user_rewards
belongs_to :created_by, class_name: 'User'
default_scope { where(deleted_at: nil) }
end
end
module DiscourseRewards
class UserPoint < ActiveRecord::Base
self.table_name = 'discourse_rewards_user_points'
belongs_to :user
belongs_to :user_badge
belongs_to :user_points_category
def self.user_total_points(user)
UserPoint.where(user_id: user.id).sum(:reward_points)
end
end
end
module DiscourseRewards
class UserReward < ActiveRecord::Base
self.table_name = 'discourse_rewards_user_rewards'
belongs_to :user
belongs_to :reward
enum status: [:applied, :granted]
end
end
لقد قمت بتعطيل جميع الإضافات في الوضع الآمن. ومع ذلك، كما تعلم، لم يتغير قاعدة البيانات. 
شيء لأخذه مع المؤلف أظن.
يبدو أنه قد لا يكون قابلاً للتوسع لعدد المستخدمين الكبير الخاص بك؟
قد تحتاج إلى إعادة البناء بدون الإضافة. سيكون ذلك مقارنة جيدة وربما يؤكد ما إذا كانت المشكلات ناتجة عن الإضافة أم لا.
لن يكون لوجود الجداول أي أهمية إذا لم يتم تشغيل الاستعلامات.
إعجابَين (2)
discourse_rewards_user_points | 233525 | 27 ميجابايت | 5152 كيلوبايت | 32 ميجابايت
discourse_rewards_user_rewards | 61 | 16 كيلوبايت | 16 كيلوبايت | 32 كيلوبايت
discourse_rewards_user_points_categories | 9 | 16 كيلوبايت | 16 كيلوبايت | 32 كيلوبايت
discourse_rewards_rewards | 4 | 16 كيلوبايت | 16 كيلوبايت | 32 كيلوبايت
جدول discourse_rewards_user_points ضخم.
إعجاب واحد (1)
قم بإزالته بالكامل (من البناء، لا حاجة لتدمير الجداول)، وانظر ماذا يحدث.
إعجابَين (2)
شكراً لك، سأجرب ذلك الآن.
إعجاب واحد (1)
أوه روبرت، لقد قمت بإعادة البناء بدون المكون الإضافي، وتم تقليل وقت الاستجابة لصفحات مسار الاكتشاف إلى أقل من 200 مللي ثانية من 2-3 ثوانٍ قبل ذلك.
إعجاب واحد (1)
حسنًا، ها هو. سأناقش التحسين مع المؤلف، أو إذا كانت لديك المهارات، فهل تقدم طلب سحب؟
إعجاب واحد (1)
أنا أسأل صديقنا الملم بقواعد البيانات للمساعدة.
لكنه يعمل على جافا. أعتقد أن الأمر سيستغرق بعض الوقت.
إعجاب واحد (1)