يبدو أن حجم القطرة قوي بما يكفي لهذا النوع من الاستيراد، لذا لا أتوقع أن يكون UNICORN_WORKERS هو المحدد الرئيسي هنا.
بعض الملاحظات:
- إيقاف يونيكورن قد يكون مقبولًا لحاوية مخصصة للاستيراد فقط أو للتجربة، لكنه على الأرجح لن يسرّع عملية الاستيراد نفسها بشكل كبير.
- تعطيل المرفقات والصور الشخصية يجب أن يزيل أحد أبطأ الأجزاء، لذا إذا كنت لا تزال تحصل على حوالي 440 منشورًا في الدقيقة فقط، فقد يكون الاختناق في إدخال/إخراج قاعدة البيانات، أو جانب استعلام phpBB MySQL في المصدر، أو انتظار Redis/PostgreSQL.
- يستحق سطر السجل المراقبة الدقيقة:
Exception while creating post 304683. Skipping.
رغم أن الاستيراد يستمر، فهذا يعني أن هذا المنشور على الأقل تم تخطيه. إذا تكرر هذا الأمر، فقد يكون الترحيل النهائي ناقصًا لبعض المنشورات.
يبدو أن جزء Redis يمثل مهلة عميل Redis لمدة ثانية واحدة أثناء قفل المutex الموزع في Discourse بينما يقوم PostCreator بإنشاء منشور. أنصحك بالتحقق مما إذا كان Redis مثقلًا بالفعل، أو ما إذا كانت المهلة قصيرة جدًا خلال استيراد طويل.
من الخطوات التالية المفيدة:
free -h
df -h
iostat -xz 1
vmstat 1
redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 20
أيضًا، هل قاعدة بيانات phpBB MySQL محلية على نفس القطرة، أم يتم قراءتها عبر الشبكة؟ نظرًا لأن تتبع المكدس يتجاوز mysql2، فإن قاعدة بيانات المصدر البطيئة أو القرص البطيء يمكن أن تبقي استخدام المعالج منخفضًا بينما ينتظر المستورد.
بالنسبة للمعدل الحالي، من 333919 / 2167314 بحوالي 441 عنصرًا في الدقيقة، لا يزال لديك حوالي 69 ساعة متبقية، لذا قد ينتهي الأمر، لكنني سأكون قلقًا بشكل أساسي من أن استثناءات مهلة Redis هذه قد تتسبب في تخطي بعض المنشورات.
لن أنصح بأ رفع UNICORN_WORKERS. في حالة تشغيل الاستيراد فقط، فإن يونيكورن غير ذي صلة إلى حد كبير. الأهم هو أن الاستيراد يستمر لكنه يتخطى المنشورات، وهذا هو الجانب الذي أود تسليط الضوء عليه.