تم الترقية إلى الإصدار 3.3.0.beta3-dev بالأمس وتم تثبيت إضافة الذكاء الاصطناعي أيضًا. الإضافة ممكّنة حاليًا للموظفين فقط (5 أشخاص)
لكن الموقع بأكمله بطيء للغاية، وأواجه أخطاء تحميل شديدة. لا يبدو أنني أستطيع تحديد مصدر المشكلة، فالحمل على خادمي يبدو طبيعيًا.
هل هناك مكان أو أماكن يمكنني الذهاب إليها لمعرفة سبب المشكلة؟
بالنظر إلى خادمي، يبدو أن عمليات يونيكورن مشغولة للغاية
هل هذا هو السبب؟ هل أحتاج إلى المزيد من وحدة المعالجة المركزية؟ أم مجرد المزيد من اليونيكورن؟
هل مضى وقت طويل منذ آخر ترقية لك؟ ربما يقوم بإجراء نوع من معالجة الصور أو إعادة الخبز.
يمكنك إلقاء نظرة على /sidekiq لمعرفة ما يفعله.
تمت إعادة تشغيل كل شيء وعاد كل شيء إلى طبيعته ولكننا الآن نواجه حملاً زائداً للغاية مرة أخرى. لا يمكنني تحديد مصدر المشكلة، هل هناك أي أدوات يمكن أن تساعد داخل ديسكورس؟
إذًا، العاملون الثلاثة في يونيكورن
مشغولون… لكننا لا نحصل على حركة مرور أعلى من المعتاد على ما يبدو، إنها تقريبًا نفس ما كانت عليه. التغيير الوحيد كان الترقية إلى 3.3.0 وإضافة إضافة الذكاء الاصطناعي ولكنها متاحة فقط للموظفين.
بدأت المشاكل بالأمس 6/3
لدينا عدد قليل من الزواحف الإضافية على ما يبدو.
هذه مجرد زواحف على مدى شهر، ولكن مرة أخرى لا يبدو أنها أعلى بكثير. الموقع غير قابل للاستخدام تقريبًا.
أي مساعدة ستكون موضع تقدير!
هذا مجرد تخمين، ولكن الشيء الوحيد الذي يلفت انتباهي في سجلات Sidekiq هو أن المهمة المعروضة هي NotifyMailingListSubscribers. يمكن لهذه المهمة أن تنشئ الكثير من الطلبات.\n\nأيضًا، هل ترى أي أخطاء في صفحة المسؤول / السجلات / سجلات الأخطاء لديك؟
لقد أضفت حظرًا لـ Facebook crawler لأن هذا الرجل كان يذهب إلى المدينة
ومع ذلك، لاحظت أن إضافة بطء / زواحف لا تقوم بتحديث ملف robots.txt الخاص بي
لكن ملف robots.txt لا يعرض الإدخالات البطيئة، فقط الإدخالات المحظورة.
الكثير من هذه
أرى 3 أخطاء ولكنها لا تبدو ذات صلة… (على الرغم من صعوبة تحديد ذلك)
Job exception: PG::DatetimeFieldOverflow: ERROR: timestamp out of range: \"271768-09-23 06:24:11.793040 BC\"
LINE 1: ...sers\".\"moderator\" = FALSE AND (users.created_at < '271768-09...
^
ActionDispatch::RemoteIp::IpSpoofAttackError (IP spoofing attack?! HTTP_CLIENT_IP=\"10.10.121.119\" HTTP_X_FORWARDED_FOR=\"14.140.10.244, 14.140.10.244\")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'
وخطأ آخر في الوظيفة حول SMTP
يقوم Discourse بتحديد معدل الاستخدام الخاص به، ولا يعتمد على robots.txt
شكرا مايكل،
هل لديك أي أفكار أخرى حول ما يمكن أن يكون؟ هل سيساعد تدوير المزيد من اليونيكورن؟
هل يتم ذلك من ملف app.yml؟
نعم، ربما سيساعد ذلك.
env:
UNICORN_WORKERS: 8
في ملف app.yml سيؤدي ذلك.
أوصي بسحب أرقام الأداء باستخدام إضافة Prometheus إذا قمت بإعدادها، أو يمكنك استخدام ترويسات الأداء.
سيساعد تحليل سجلات الويب الخاصة بك كثيرًا في تحديد سبب انشغال خادمك؛ يبدو أن الزواحف مكان جيد للبدء.
تمت الترقية بنجاح إلى خادم DO جديد، مضاعفة ذاكرة الوصول العشوائي والمعالج. تمت إضافة 8 وحيدات (مقابل 3) وتم إجراء إعادة فهرسة لقاعدة البيانات وتنظيف، وأعتقد أننا عدنا للعمل!
شكراً للمساعدة
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.