أدى ذلك إلى شكوكي بأن السبب هو طلبات الزوار الآليين (Crawlers) الساعة 9:40 صباحًا. لكنني لا أعرف ما إذا كان هناك طريقة للتحقق من ذلك. راجعت قائمة الزوار الآليين وعدد الطلبات، ومعظمها يأتي من Google وBing، لذا من المؤكد أننا لن نحجبهم.
هذا قادني إلى الأسئلة التالية:
هل يوجد سجل يمكنني من خلاله معرفة من يقوم بالوصول إلى الموقع في لحظة معينة؟
هل هناك طريقة لجعل الزوار الآليين توزيع طلباتهم بشكل متباعد نظرًا لأنهم “زوار آليون جيدين”؟
هل زيادة موارد وحدة المعالجة المركزية/الذاكرة في الخادم ستساعد في حل المشكلة؟ أنا متشكك قليلاً في ذلك نظرًا لأن استخدام وحدة المعالجة المركزية والذاكرة لم يرتفع. هل متوسط استهلاك الذاكرة بنسبة 80% مرتفع جدًا؟
نحن نستخدم 2 من أنوية المعالجة الافتراضية (vCPUs) و2 جيجابايت من الذاكرة. قمنا بضبط المثيل على 4 عمال (workers) لـ Unicorn، وهو ما يبدو متوافقًا مع كمية الذاكرة المتاحة لدينا.
نعم، تحقق من /var/discourse/shared/standalone/log/var-log/nginx/access.log.
نعم، إعداد الموقع “إبطاء وكلاء مستخدمين لمحركات البحث”.
يبدو أن ما حدث كان انتظار إدخال/إخراج (I/O wait) خلال ذروة الساعة 9:40. قد يساعد زيادة الذاكرة العشوائية (RAM) حيث يمكن الاحتفاظ بمزيد من البيانات في ذاكرة التخزين المؤقت، لكنني لا أعرف ما إذا كانت هذه الذروة كانت للقراءة أو الكتابة، حيث قمت بقص مفتاح الرسم البياني .
على أي حال، إذا كنت تستطيع تحمل التكلفة، فإن زيادة حجم القطرة (droplet) إلى الحجم التالي المتاح سيساعد دائمًا.
شكرًا لك. لقد تفحصت سجل الأخطاء في الساعة 9:40 صباحًا، ويبدو أن الطلبات قادمة من إجراءات المستخدمين (متصفحات المستخدمين) وليس من برامج الزحف.
كانت الذروة الخضراء للقراءة.
نعم، بما أن الأمر لا يبدو وكأنه ناتج عن برامج الزحف، فأعتقد أنني سأجري تجربة مع حجم القطرة التالي ويزيد ذاكرة الوصول العشوائي من 2 جيجابايت إلى 4 جيجابايت لأرى ما إذا كان ذلك سيساعد.
من المفاجئ قليلًا بالنسبة لي أن يكون نشاط المستخدمين هو السبب، لأنني كنت دائمًا أعتقد أن لدينا عددًا أقل من المشاركين النشطين في العامين الماضيين مقارنة بما قبل ذلك. لكن عندما نظرت إلى تحليلات Google، نلاحظ زيادة مستمرة في المستخدمين - ربما حتى لو انخفض عدد المشاركين، فإن عدد المتفرجين (lurkers) قد زاد…
.
