# عمليات البناء تستغرق وقتًا طويلاً جدًا

**URL:** https://meta.discourse.org/t/builds-taking-very-long-time/217001
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [3 فبراير 2022، 5:27م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001 "2022-02-03T17:27:27Z")
**Posts on this page:** 8
**Page:** 2

<div class="post-metadata">

### Author: ![Jonathan5](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jonathan5/32/197134_2.png) [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [20 يونيو 2022، 9:55م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/21 "2022-06-20T21:55:25Z")

</div>

تستغرق إعادة البناء الخاصة بي حوالي 10 دقائق أو نحو ذلك. أعتقد أنها كانت أقرب إلى 5 دقائق. لذا لا مشكلة كبيرة. ماذا يعني الخطأ إذن؟ أحصل على شيء مشابه لما في المنشور الأصلي أعلاه:

```plaintext
I, [2022-06-20T21:41:47.107238 #1] INFO -- : cd /var/www/discourse && [! -d 'node_modules'] || su discourse -c 'yarn install --production && yarn cache clean'
warning "eslint-config-discourse > eslint-plugin-lodash@7.1.0" has unmet peer dependency "lodash@>=4".
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".

```

---

<div class="post-metadata">

### Author: ![RBoy](https://avatars.discourse-cdn.com/v4/letter/r/2bfe46/32.png) [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [17 أكتوبر 2023، 11:27ص UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/22 "2023-10-17T11:27:54Z")

</div>

سأضيف المزيد إلى هذا أيضًا، أنا أدير نظامًا خفيفًا (1 جيجابايت من ذاكرة الوصول العشوائي) وموقعًا صغيرًا. يحتوي على عاملين من عمال unicorn، وبين كل منهما كان كل منهما يستهلك 30٪ من الذاكرة، مما كان يسبب الكثير من [تبديل الذاكرة](https://meta.discourse.org/t/limiting-the-number-of-unicorns-memory-usage-and-swapping/274954?u=rboy)، لذلك قررت تقليل العدد من 2 إلى 1 (والذي أعتقد أنه يمكن أن يتعامل مع حوالي 10 اتصالات متزامنة لكل منهما). أحدث هذا فرقًا كبيرًا وجعل تحميل الصفحات شبه فوري وقلل التبديل بمقدار 5-10 أضعاف (اعتمادًا على ما كان يتم تحميله).

العيب الذي أراه الآن هو أنني لم أعد أستطيع استخدام ترقيات المتصفح لتحديث discourse. عندما أحاول التحديث عبر المتصفح، أحصل على:

> ABORTING, you do not have enough unicorn workers running  
> Docker Manager: FAILED TO UPGRADE  
> #\<RuntimeError: Not enough workers\>

لذا، هذا مجرد شيء يجب ملاحظته، ولست متأكدًا مما إذا كان هذا شيئًا يمكن لفريق Discourse اكتشافه/معالجته - إجراء ترقيات المتصفح باستخدام عامل unicorn واحد.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [17 أكتوبر 2023، 2:33م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/23 "2023-10-17T14:33:32Z")

</div>

> [@RBoy](#):
>
> ABORTING, you do not have enough unicorn workers running

يبدو هذا خطأً، خاصة وأن النظام يقلل إلى عامل يونيكورن واحد مؤقتًا بعد ذلك بوقت قصير.

الرقم 2 مبرمج بشكل ثابت، وكذلك الرقم 1 للتخفيض.

> <https://github.com/discourse/docker_manager/blob/main/lib/docker_manager/upgrader.rb#L37C1-L41C1>

تعديل: يبدو أن هذا التغيير أدخل عدم الاتساق

> <https://github.com/discourse/docker_manager/commit/8bfea831c7b423d26d85585f9a3d7301d58e00ae>

أعتقد أن مشاركتك (وهذا الرد) يجب أن تكون في موضوع جديد، في فئة الأخطاء.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [17 أكتوبر 2023، 7:03م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/25 "2023-10-17T19:03:49Z")

</div>

كيف يعمل هذا؟

يونيكورن واحد للتعامل مع عملية الترقية، بينما يقوم الباقي بخدمة المكالمات المستمرة؟

وبالتالي، يلزم وجود عاملين يونيكورن كحد أدنى لإجراء ترقيات عبر الإنترنت…؟

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [18 أكتوبر 2023، 3:56م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/26 "2023-10-18T15:56:11Z")

</div>

> [@RBoy](#):
>
> والتي أعتقد أنها يمكن أن تتعامل مع حوالي 10 اتصالات متزامنة لكل منها

هذا خطأ. يمكن لوحيد قرن واحد التعامل مع طلب واحد فقط في كل مرة، لذلك بينما يمكن استخدامه للمجموعات الصغيرة، فإنه ليس شيئًا نوصي به لمعظم المواقع.

---

<div class="post-metadata">

### Author: ![RBoy](https://avatars.discourse-cdn.com/v4/letter/r/2bfe46/32.png) [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [18 أكتوبر 2023، 5:32م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/27 "2023-10-18T17:32:33Z")

</div>

@Falco لقد نظرت في بيانات المسؤولين الآخرين. فهمي هو أن كل Unicorn يقوم بإنشاء عملية جديدة لكل اتصال وارد. لذا، بينما هو تقنيًا اتصال واحد في كل مرة، يمكن لكل Unicorn التعامل مع مستخدمين متزامنين متعددين.

بناءً على التجربة المشتركة أدناه، يمكن لحوالي 8 Unicorns التعامل مع ما يقرب من 400 مستخدم متزامن.

> [@Optimizing the number of Unicorns and buffer size](https://meta.discourse.org/t/optimizing-the-number-of-unicorns-and-buffer-size/51514/3?u=rboy):
>
> Found the limits of our setup yesterday, with about 400+ concurrent sessions and many of them being logged in, actively polling and chatting. The day before we delivered 138k page views without a hitch. The bottleneck was the number of unicorns (8). We only reached about 35% CPU loads and there were 2GBs of free RAM with these settings. I changed to 10 unicorns, after which we had no more hiccups and served a peak of 440 sessions, and got CPU loads closer to 50%. But then it was getting late a…

بناءً على ذلك، يبدو أن كل Unicorn يمكنه التعامل مع حوالي 50 مستخدمًا متزامنًا. الآن، أعلم أن ذاكرة الوصول العشوائي (RAM) وموارد النظام تحدث فرقًا في عدد العمليات التي يمكن إنشاؤها وما إلى ذلك، ومن هنا جاء افتراضي بأن عامل Unicorn واحد يمكنه التعامل مع 10 مستخدمين متزامنين على نظام بذاكرة وصول عشوائي منخفضة (1 جيجابايت) في الحد الأدنى.

هل افتراضاتي + استنتاجاتي خاطئة تمامًا؟ إذا كان الأمر كذلك، فما هو نطاق المستخدمين المتزامنين الذي يمكن لكل Unicorn التعامل معه اعتمادًا على موارد النظام (بافتراض 1 جيجابايت في الحد الأدنى وأي شيء تشعر أنه مناسب في الحد الأعلى)؟

---

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [18 أكتوبر 2023، 7:19م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/28 "2023-10-18T19:19:54Z")

</div>

هناك فرق بين جلسات المستخدم المتزامنة والاتصالات المتزامنة. الجلسة هي مستخدم متصل بالإنترنت، وكل منهم يقوم بطلب (اتصال) كلما تفاعل.\n\n[quote="RBoy, post:27, topic:217001, username:RBoy"]\nفهمي هو أن كل Unicorn يقوم بعمل نسخة جديدة من العملية لكل اتصال وارد\n[/quote]\nلا يفعل ذلك. يقوم Unicorn بعمل نسخة إلى عدد محدد من عمليات العامل عند بدء التشغيل.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [18 أكتوبر 2023، 7:37م UTC](https://meta.discourse.org/t/builds-taking-very-long-time/217001/29 "2023-10-18T19:37:30Z")

</div>

> [@RGJ](#):
>
> تنقسم Unicorn إلى عدد محدد من عمليات العامل عند بدء التشغيل

وأعتقد أننا رأينا أن كل عملية عامل تدير 10 خيوط.

[Previous page](https://meta.discourse.org/t/builds-taking-very-long-time/217001.md?page=1)
