مرحباً، كما ذكرت في المنشورات السابقة، أقوم بتشغيل اختبارات لهجرة Drupal الخاصة بي إلى Discourse ليكون لدي جميع الحلول جاهزة قبل أن أقوم بإيقاف الموقع القديم لترحيل بيانات الإنتاج مع حوالي 2 مليون منشور. ما تعلمته هو أنه على خادم افتراضي خاص سريع جدًا مع 3 أنوية معالج افتراضية، تستغرق عملية الاستيراد وقتًا طويلاً جدًا، حوالي 48 ساعة. وبعد ذلك، قد أحتاج إلى إجراء المزيد من التنظيف باستخدام مهام rake و/أو rails c، وأي شيء يتطلب rake posts:rebake سيستغرق حوالي 20 ساعة أخرى.
أنا لا أفهم تمامًا أساسيات سلسلة أدوات Ruby. ولكن إذا قمت بتوفير المزيد من أنوية المعالج للوظيفة، فهل سيقلل ذلك بشكل كبير من مقدار الوقت الذي تتطلبه أي من هذه العمليات لإكمالها؟ على سبيل المثال، هل يمكن لأمر bundle أو أمر rake تقسيم عمله بين وحدات المعالجة المركزية المتاحة، أم أن الأنوية الإضافية مفيدة بشكل أساسي لتشغيل عمليات متزامنة متعددة عندما يصل العديد من المستخدمين إلى موقع الويب؟
أنا خارج الموضوع، ولكن عندما كنت أعمل على ترحيل منتدى بنفس عدد المشاركات، قمت بتعديل البرنامج النصي للاستيراد لاستيراد 1/100 أو 1/1000 فقط من المواضيع والمشاركات.
إنها طريقة أسرع لمعرفة ما إذا كان الاستيراد الخاص بك موثوقًا به وما إذا كانت هناك حاجة إلى تعديلات أو تصحيح أخطاء.
@Canapin في الواقع، شكرًا جزيلاً لك على ذكر ذلك، أود حقًا أن أعرف كيف فعلت ذلك. كنت أرغب في فعل الشيء نفسه، لكنني تخلصت من الفكرة لأنني افترضت أنني سأواجه عدم اتساق في قاعدة البيانات مع استيراد جزئي. لذلك انتهى بي الأمر بإنشاء منتدى اختبار دروبال هيكلي للاختبار عليه. لكنني أفضل اختبار نسخة من قاعدة بيانات الإنتاج.
أنا قلق بشكل أساسي بشأن هجرة الإنتاج النهائية النهائية؛ سأضطر إلى إيقاف المنتدى القديم عن العمل أو على الأقل جعله للقراءة فقط، ويبدو أن هذا سيستغرق 48 ساعة على الأقل في أفضل الأحوال، إلا إذا كان تخصيص ضعف عدد أنوية وحدة المعالجة المركزية سيقلل الوقت إلى النصف؟
المهام التي تستغرق وقتًا طويلاً للاستعادة هي بالفعل متعددة الخيوط. هناك تحذير واحد وهو أن مضاعفة عدد وحدات المعالجة المركزية لا يعني تقريبًا أبدًا مضاعفة الأداء.
النقطة الأخرى هي أن المهام الخاصة بـ rake posts:rebake والعمل المكثف للمنتدى نفسه لاستعادة المحتوى وتحسينه يمكن أن تحدث أثناء تشغيل المنتدى. مما قد يقلل من الوقت الذي تحتاجه لإيقاف المنتدى مؤقتًا أو جعله للقراءة فقط وتقديم تجربة متدهورة إلى حد ما.
توصيتي ستكون: أولاً، قم بالاختبار. قم بالترحيل، وانظر كم من الوقت يستغرق وكيف يبدو المنتدى بدون كل عمليات إعادة الخبز في مكانها. إذا كان الوقت كافيًا، قم بإنهاء الترحيل حول وقت أقل حركة مرور على منتداك، وبهذه الطريقة تكسب حوالي 4-10 ساعات من الترحيل دون أن يشتكي الكثير من الناس.
للأسف، لم أدون ذلك ونسيت… ولكن إذا كنت تعرف البرمجة، فلا ينبغي أن يكون ذلك صعبًا للغاية.
ربما قمت بتعديل قيم BATCH_SIZE و offset من بين أشياء أخرى لتغيير الحلقة وجعلها تتخطى دفعات من المشاركات أو شيء من هذا القبيل…
لا يمكنني المحاولة مرة أخرى الآن لأنه ليس لدي أي منتدى لاستيراده حاليًا، ولكني سأقوم بعمل برنامج تعليمي سريع في المرة القادمة لأنني أعتقد أنه مفيد للغاية.
أريد ذكر أمرين.\n\n- نعم، وحدات المعالجة المركزية مهمة، لذا احصل على خادم افتراضي خاص أكبر وشغّل مثيلات Sidekiq متعددة لإعادة الخبز ومعالجة الصور، وسيكون الأمر أسرع\n- عندما يكتمل الاستيراد تمامًا، من الجيد دائمًا إجراء نسخة احتياطية/استعادة، مما يمنحك أداءً أفضل لقاعدة البيانات.\n\nهذان معًا: احصل على خادم افتراضي خاص كبير للاستيراد وعندما تنتهي، انقله إلى خادم افتراضي خاص إنتاج أصغر (باستخدام النسخ الاحتياطي والاستعادة).\n\nبشكل عام، لن يتطلب الاستيراد منك إعادة خبز المنشورات بعد ذلك.
شكراً جزيلاً لك يا ريتشارد على الرد. إذن أي من هذه؟
UNICORN_WORKERS
UNICORN_SIDEKIQS
DISCOURSE_SIDEKIQ_WORKERS
مثير للاهتمام، لم أر هذه التوصية من قبل. هل يقلل ذلك من التجزئة أو شيء من هذا القبيل؟
نعم، كنت سأحاول في البداية إصلاح بعض مشاكل [QUOTE] وتحويل Textile → Markdown باستخدام regexp_replace() في وحدة تحكم Postgres ثم إعادة خبز جميع المشاركات، لأن أوامر rake posts:remap كانت بطيئة جدًا. ولكن بعد ذلك اكتشفت أن نكهة التعبير العادي التي تستخدمها Postgres ليست متوافقة مع PCRE، وهناك الكثير من الحالات الشاذة غير المتوقعة للاعتماد عليها. لذلك سأحاول تشغيل المشاركات عبر Pandoc أثناء عملية الاستيراد، مما سيسمح لي بتشغيل الموقع المستورد في حالة قابلة للعرض ثم إصلاح الأشياء الصغيرة مثل الكلمات الرئيسية للرموز التعبيرية باستخدام rake posts:remap.
أعتقد أن سام أو جيف هو من قدم لي هذه النصيحة منذ سنوات عديدة. لم أعد أستطيع العثور عليها. ربما يجب أن نتحقق مما إذا كانت لا تزال فكرة جيدة و/أو تستحق العناء
هل يمكن لأي شخص مشاركة نصائح معي حول أسرع طريقة لإعادة تشغيل برنامج نصي للاستيراد وجعله يعيد استيراد البيانات؟ أحاول تعديل بعض استبدالات النصوص في برنامج الاستيراد، وعندما لا أحصل عليها بشكل صحيح، يتعين علي حذف قاعدة بيانات Discourse وإعادة بنائها باستخدام ./launcher rebuild import، وهو ما يستغرق وقتًا طويلاً. أود إجراء تغييرات في برنامج الاستيراد الخاص بي وجعله يبدأ من جديد (أنا أستخدم قاعدة بيانات نموذجية صغيرة لموقعي الآن، لذا فإن تشغيل المستورد سريع جدًا).
هممم. أنا أختبر استيرادًا آخر لبيانات المنتدى الإنتاجي الخاص بي، هذه المرة على خادم افتراضي خاص قوي جدًا به 8 نوى افتراضية و 16 جيجابايت من ذاكرة الوصول العشوائي. لقد قمت بتعيين: UNICORN_SIDEKIQS=4 DISCOURSE_SIDEKIQ_WORKERS=20 UNICORN_WORKERS=16
مع هذا، لا يبدو أنه يستفيد من جميع النوى أثناء مرحلة import_topics:
على الرغم من أنه من المثير للاهتمام أن الرسم البياني لوحدة المعالجة المركزية كان عند أكثر من 600٪ (لذا تم استخدام ~ 6 من أصل 8 نوى بنسبة 100٪) خلال مرحلة user_import.
لاحظت أيضًا متغير البيئة هذا: RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 هل سيكون هذا صغيرًا جدًا؟
أعتقد أنه خلال حالة إنشاء المستخدم، هناك إجراءات أخرى يتم التعامل معها بشكل غير متزامن بواسطة Sidekiq.
لن يستفيد جزء كبير من الاستيراد من المعالجة المتوازية للأسف، يجب عليك التحسين لسرعة وحدة المعالجة المركزية أحادية النواة بدلاً من ذلك.
نظريًا، يمكنك تشغيل أجزاء مختلفة من استيراد الموضوعات بالتوازي ولكن هذا سيتطلب إعادة هيكلة كبيرة للمستورد والتأكد من معالجة كل شيء بالترتيب. لا يستحق الأمر مهمة لمرة واحدة مع عدد قليل من التكرارات.
لقد اتبعت مزيجًا من هذين الدليلين [1][2] للاستيراد مع الوصول إلى حاوية Docker أخرى تشغل نسخة من قاعدة بيانات المنتدى المصدر في MySQL. لكن خطر ببالي أنه بدلاً من إنشاء حاوية import منفصلة، يمكنني ببساطة استخدام حاوية app واحدة وإضافة mysql-dep.tempate إليها:
هذا يسمح لي بالحصول على نسخة عاملة من Discourse أثناء تشغيل برنامج الاستيراد النصي. هل هناك أي عيب في فتح المنتدى للجمهور بمجرد استيراد جميع المستخدمين والفئات، وإعلام المستخدمين فقط بوجود لافتة تفيد بأنه سيمر بضعة أيام حتى يتم ملؤه بالكامل؟ أفكر في أنه على الأقل يمكنني فتحه بعد استيراد جميع المواضيع والمنشورات ولكن قبل استيراد الرسائل الخاصة، حيث أن الرسائل الخاصة وحدها ستستغرق حوالي 24 ساعة للاستيراد.
