אופטימיזציה של Discourse Multisite גדול: צווארי בקבוק במסד הנתונים וב-Sidekiq

תמיכה התקנה
,

סיכום מבוסס בינה מלאכותית

In a discussion titled Optimizing a Large Discourse Multisite: Database and Sidekiq Bottlenecks, emonunix seeks advice on tuning a Discourse multisite setup where high background job volume is overwhelming the database, causing Sidekiq queues to back up and slowing site performance. Their current app.yml settings include UNICORN_WORKERS: 4, UNICORN_SIDEKIQS: 4, DISCOURSE_SIDEKIQ_WORKERS: 10, and DISCOURSE_DB_POOL: 8. They specifically ask for best practices on sizing Sidekiq concurrency and whether separating queues (e.g., critical vs. low) would help prevent blocking. itsbhanusharma suggests re-running ./discourse-setup to auto-adjust configs after resource upgrades. pfaffman questions if reducing DISCOURSE_SIDEKIQ_WORKERS might help and notes that Discourse already prioritizes high-priority jobs. Falco asks if upgrading the cloud database instance type has been considered, since the database appears to be the bottleneck. emonunix thanks the contributors for their input. The focus remains on low-risk, configuration-based tuning rather than architectural overhauls.

1

אני מחפש הדרכה מומחים בנוגע לאופטימיזציה של הגדרת ריבוי אתרים של Discourse. יש לי מכונה וירטואלית אחת לרשת ומכונה וירטואלית נפרדת למסד נתונים אצל ספק ענן גדול. בעוד שלשתי המכונות יש מפרטים סבירים, אני מגלה שהמערכת שלי מוצפת מכמות גדולה של משימות ברקע, מה שנראה שמעמיס על מסד הנתונים.

תצורת ה-app.yml הנוכחית שלי היא:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

בהתבסס על התצפיות שלי, צוואר הבקבוק אינו פגיעה במגבלת חיבור קשיחה, אלא דווקא הכמות העצומה של משימות המתחרות על משאבי מסד הנתונים בו-זמנית. התורים ב-Sidekiq מתמלאים ללא הרף, מה שגורם לאתר להרגיש איטי, אפילו עבור משימות ניהוליות בסיסיות.

אני מחפש גישה כללית לכוונון המערכת ליציבות וביצועים. באופן ספציפי, הייתי רוצה להבין את שיטות העבודה המומלצות עבור:

  • מקביליות Sidekiq: כיצד יש לכמת את DISCOURSE_SIDEKIQ_WORKERS בסביבת ריבוי אתרים כדי לטפל בכמות משימות גבוהה מבלי להעמיס על מסד הנתונים?
  • הפרדת תורים: האם מומלץ להפעיל תהליכי Sidekiq נפרדים לטיפול בתורים שונים (למשל, עדיפות critical לעומת low)? זה יבטיח שמשימות כבדות לא יחסמו משימות דחופות יותר.

איני מחפש פתרון הדורש שינוי ארכיטקטוני גדול או מעבר לשרת אינטרנט אחר בשלב זה, מכיוון שאני רוצה לשמור על התהליך פשוט ככל האפשר ובעל סיכון נמוך. אני מקווה לקבל ייעוץ לגבי דרך פעולה בטוחה ויעילה.

תודה!

2

Discourse אמור להיות מסוגל להתאים אותם אוטומטית בהתבסס על משאבי המערכת שלך. שים לב שבטוח להריץ מחדש את סקריפט ./discourse-setup אם הגדלת לאחרונה את משאבי המערכת שלך. הסקריפט יכול להסתגל למשאבים המוגברים ולהתאים את קובץ ה-.yml שלך בהתאם

3

Sounds like you need fewer?

I’m pretty sure that it already knows to prioritize the high priority jobs.

4

@itsbhanusharma @pfaffman תודה על העזרה והתובנות בנושא! אני מעריך את שניכם שהקדשתם מזמנכם לחלוק את המומחיות שלכם.

5

If the database is the bottleneck, have you considered moving to larger instance type for your cloud database?