أتفق، ما هي قيمة المحتوى الذي لا يقرأه أحد؟ ومن هم الأشخاص الذين سيجلسون فعليًا لقراءة 10,000 منشور من البداية إلى النهاية؟ 
لا بأس أن تكون بعض المواضيع محادثات عابرة تختفي تمامًا مع مرور الوقت، وهو ما كنا نسميه سابقًا “المسار السريع” مقابل “المسار البطيء”.
تحديث صغير:
منذ الاتفاق على إغلاق كل ما هو فوق الحد المحدد (وإعادة ضبط الحدود)، تحسنت الأداء بشكل ملحوظ، بل بشكل كبير. لا تزال تظهر لدينا بعض الرسائل مثل “بسبب الحمل الشديد، يتم عرض هذا مؤقتًا كما يراه المستخدم غير المسجل”، لكن بنسبة أقل بكثير.
ومع ذلك:
مرة أخرى، شكرًا جزيلاً للجميع على المساعدة وتقديم الملاحظات.
سيساعد Postgres 12 حيث يقلل حجم الجداول والفهارس بنسبة 20% في اختبارات @falco.
هل هناك تاريخ مستهدف لذلك حتى الآن؟
بدأت في إجراء اختبارات الأداء اليوم.
يجب أن أتركها تعمل لبعض الوقت هنا على Meta حتى نتمكن من مراقبة أي تدهور في الأداء قبل نشرها في كل مكان.
أعتذر عن إحياء هذا الموضوع مرة أخرى، لكن هذه مشكلة مختلفة عن ترحيل PostgreSQL. (والتي لا أستطيع القيام بها بعد بسبب الحجم).
منذ إعادة البناء الأخيرة، لم يتوقف حجم قاعدة البيانات عن الزيادة:
كانت آخر إعادة بناء في 17 مايو، ومنذ ذلك الحين لم يتوقف حجم قاعدة البيانات عن الزيادة، حيث وصل إلى 57.3 جيجابايت، والجزء الأكبر من الحجم موجود في جدول post_timings.
مشكلتي الرئيسية مع هذا هي أنني أحاول إجراء تحديث PostgreSQL (والذي سيقلل حجم الفهرس بنسبة 20٪ لكنه لن يحل هذه المشكلة على المدى الطويل). ومن التعليقات هنا من الموظفين أن هذا الحجم ليس هو المعتاد، لذا سيستمر في الزيادة ويصبح مكلفًا بشكل كابوسي. كلما مر الوقت، زادت الزيادة وتخلق حلقة تصبح جحيمًا في الصيانة. لذا تظل مشكلتي الرئيسية: هل هناك طريقة للتعامل مع أمر post_timings هذا؟ هل هناك شيء يمكن حذفه؟
هل يمكنني ضغط الجداول أو شيء مشابه؟
شكرًا للجميع على مساعدتهم.
لا مفر من ذلك في الوقت الحالي. إذا كان منتدىكم كبيرًا حقًا، فسيحتوي على جدول توقيتات كبير.
ميتا مثيل قديم جدًا، لكنه متوسط الحجم ويحتوي على جدول post_timings صغير بحجم 4 جيجابايت. من ناحية أخرى، نستضيف مثيلًا عمره أقل من عامين، ومن المفترض أن يتجاوز جدول post_timings فيه الآن 100 جيجابايت.
استضافة المنتديات الكبيرة ستكلفكم أكثر، ولا توجد طرق للتغلب على ذلك اليوم.
ربما تنقلون قاعدة البيانات إلى قطرة مستقلة بسعة 20 دولارًا (قرص 80 جيجابايت) وتضعون الويب على قطرة أخرى بقيمة 10 دولارات؟ 30 دولارًا شهريًا لمجتمع يبدو كبيرًا جدًا تبدو معقولة.
شكرًا جزيلاً لك على مساعدتك، @Falco.
حسنًا، نعم، كما قلت، أسأل فقط لأنه لا يوجد شيء سحري عندما يتعلق الأمر بالفضاء. أنا أبحث في التقسيم، لكن التطبيق سيكون بطيئًا جدًا بسبب الأداء (قصة طويلة، أنا أدون الاختبارات وسأعرضها هنا لاحقًا ليعمل بها الجميع إذا وجدوها مفيدة).
لقد أجريت الاختبار الذي طلبت منك الحديث عنه بشأن استعادة نسخة احتياطية وما إلى ذلك، وأعتقد أن هذا يمكن أن يكون موقفًا جيدًا للاستفادة منه، حيث يمكنني أن أرى على الفور أن استخدام القرص أقل بنسبة 30% (ما زلت أجري بعض الاختبارات للتحقق من عدم وجود أي شيء مفقود)، لكن الآن هناك مشكلة صغيرة مع هذا النهج، لذا وعلى الرغم من أن الفوائد الفورية كبيرة، إلا أن هذا سيولد بعض المشاكل (وذلك أكثر لأنني لا أعرف ما إذا كانت مخزنة مؤقتًا أم لا تعمل على الإطلاق من حيث الصور المخزنة، ونعم، تتضمن النسخة الاحتياطية هذه الصور).
أقوم بتدوين الملاحظات حتى أتمكن من تحديث المنشور الأصلي، وفكرتي هنا هي إضافة سلسلة صغيرة من الملاحظات للأشخاص الذين قد يقلقون بشأن الأداء وكل الأشياء التي قمت بتعديلها حتى الآن.
هل يُعد تطبيق مؤقت “حذف الردود تلقائيًا” حلاً جيدًا من الناحية التقنية؟
في الواقع، هذه فكرة جيدة جدًا وتحل مشكلة سهولة الاستخدام (لأنه، كما قلنا، لن يقرأ أحد 10 آلاف رسالة). لذا فإن السؤال الكبير هو ما إذا كان ذلك سيكون مرهقًا للخادم وقاعدة البيانات.
لست متأكدًا مما إذا كان موضوع ردود يبلغ عددها 9000، منها حوالي 8600 تم حذفها، جيدًا للأداء، لكنني أشك في ذلك. ما رأيك @eviltrout؟
اعتقدت أن المنشورات “المخفية” تُحذف تمامًا من قاعدة البيانات بعد مرور بعض الوقت، لكنني أرى الآن أن هذا على الأرجح ليس صحيحًا.
لذا، من حيث الأداء، لا يمكن لفكرتي حل المشكلة.
هل توجد طريقة لـ “إزالة” هذه البيانات؟
يتم حذف المنشورات المحذوفة بشكل ناعم. ومع ذلك، غالبًا ما يتم فهرستها، لذا قد تلاحظ بعض التحسينات عند حذف مجموعة منها. لا أنصح بذلك على أي حال. إذا كانت هناك أي طريقة لنقل النقاش إلى موضوع جديد بمجرد أن يصبح كبيرًا، فقد يكون ذلك مفيدًا لك.
ماذا تقصد بذلك؟ إن وجود قاعدة البيانات وتطبيق الويب على خوادم منفصلة يجب أن يمنحك أداءً أفضل، لأنه على الرغم من وجود بعض زمن الانتقال بين الخوادم، فإن Unicorn و Postmaster لن يضطرا للتنافس على وحدة المعالجة المركزية والذاكرة العشوائية.
تأكد من أن الخوادم موجودة في نفس منطقة DigitalOcean 
عذراً، أنت محق، فهذا سيحرر كليهما ويحقق أداءً أفضل من تشغيل كل شيء على جهاز واحد (كنت أقارن بالموارد التي أستخدمها على جهاز واحد والتحسينات التي قمت بها حتى الآن).
هذه في الواقع فكرة ممتازة، دعني أحاول حل مشكلة “عدم القدرة على إعادة بناء حاوية البيانات” التي أواجهها، وسيكون ذلك قفزتي التالية في هذه الرحلة.
لقد بحثت بجد في هذا الموضوع، لكنني لم أجد وثائق توضح كيفية القيام بذلك بشكل مثالي. هل يوجد دليل من هذا النوع؟
نحن أيضًا نبدأ في الوصول إلى حدود قدراتنا مع تثبيت VPS القياسي الواحد. ومعضلتنا الفريدة نسبيًا هي محادثات اللعبة التي تحدث خلال مباريات الهوكي وتسبب طفرات حادة في النشاط/الحمولة. خاصة إذا حدث شيء استثنائي في اللعبة.
يبدو أنك ستحتاج إلى شيء قوي بما يكفي لتحمل أوقات الذروة لديك، أو ستحتاج إلى زيادة الأداء خلال هذه الأوقات. ربما تبحث عن خادم افتراضي خاص (VPS) يمكنك الدفع له بالساعة. إحدى الحلول (استكمالًا للنصيحة السابقة) هي نقل حاوية الويب إلى خادم افتراضي خاص فائق القوة تدفع مقابل استخدامه لبضع ساعات فقط عند وجود الألعاب.
يجب عليك:
تشغيل PostgreSQL في مكان آخر (مثل خادم Droplet أو استخدام خدمة مستضافة مثل Worry-Free Managed Database Hosting | DigitalOcean)، ونقل بياناتك هناك.
اتبع إرشادات تشغيل Discourse مع خادم PostgreSQL منفصل
وهذا يمكن تحقيقه أيضًا باستخدام منتجات Discourse المُعبأة في حاويات؟ Web_only و data، أليس كذلك؟
من خلال خبرتي، لا يحل أي نهج حالي هذه المشكلة مباشرةً، ولا يوجد لها حل خطي. في الواقع، فصلها على آلات مختلفة ليس حلاً فوريًا لتلك المشكلة.
نحن أيضًا نواجه انخفاضات حادة ورسائل مثل “الموقع مشغول للغاية، لذا تظهر لك وكأنك غير مسجل” عند حدوث حدث كبير (مثل لعبة، كما ذكر @ljpp)، مما يؤدي إلى إبطاء الموقع بأكمله، وليس فقط الأشخاص داخل ذلك الموضوع.
لذلك، جربت شيئين مختلفين: إعداد منفصل و"آلة كبيرة"، وكلاهما يعاني من هذا النوع من المشكلات. يتم مراقبة مثيلاتي باستخدام Prometheus، وتكون السجلات مرئية على Grafana وما إلى ذلك، لذا لدي تحكم دقيق جدًا في أداء الأجهزة/الحاويات، ويمكنني تأكيد أنه بغض النظر عن ما تفعله، ستحدث المشكلة على أي حال.
إذا وضعت آلة كبيرة خلفها، فقد تؤخر المشكلة قليلاً، لكنك ستواجه الأخطاء وانقطاعات الجلسات، وستكون الآلة شبه خاملة من حيث استخدام القرص أو المعالج أو الذاكرة. وهذا يحدث في كل من “التثبيت الافتراضي” و"تثبيت الحاويتين".
مع آلات مختلفة، تظل المشكلة نفسها، بغض النظر عما إذا كانت الآلات من نفس النوع أو أن إحداهما “مُحسّنة للمعالج” والأخرى “مُحسّنة للقرص” وما إلى ذلك. إلى ذلك، يجب إضافة طبقة إضافية محتملة لفشل الاتصال بين آلتين مختلفتين، مما سيؤدي حتمًا إلى تأخير، على الرغم من أن مقدار هذا التأخير قد يختلف حسب كيفية إعدادك لذلك الاتصال و"مدى بعد" الآلتين عن بعضهما البعض، لكنك ستلاحظ نفس السلوك.
كملاحظة، يحدث هذا النوع من السلوك أيضًا مع أشياء مثل إضافة Babel، لكن يبدو لي أن إضافة Babel يمكنها التعامل مع عدد أكبر بكثير من عمليات الكتابة “المتزامنة”، حتى لو كانت “الرسائل الفورية” في الواقع مواضيع مخفية، لكن الفرق يكمن في كيفية عرضها و"تحديثها"/“جلبها”. هذا الاختلاف في السلوك قادني إلى الاستنتاج بأن هذا شيء يتعلق بتطبيق معين ينشأ من مشكلة من نوع الواجهة الأمامية “تسبب في انهيار” التطبيق (بما أن الواجهة الأمامية ليست مجال تخصصي، على عكس الواجهة الخلفية) والعمليات الجارية عند النشر وبقاء الأشخاص على موضوع ينتظرون “تحديثه ذاتيًا” بعشرات الرسائل في دقيقة واحدة.
إلى ذلك، يجب إضافة العامل البشري: عندما يشعر الناس بأن الموقع “بطيء” أو أن موضوعًا ما “لا يتحدّث بالسرعة التي ينبغي له بها”، سيقومون بالتحديث (F5) بشكل مفرط، مما يضيف حمولة إضافية. لكن حظًا موفقًا في “التثقيف” في هذا الصدد 
