Builds dauern sehr lange

Installation
21

Meine Neuerstellungen dauern etwa 10 Minuten. Ich glaube, sie waren früher eher 5 Minuten. Also keine große Sache. Was bedeutet die Fehlermeldung aber? Ich bekomme etwas Ähnliches wie das im ursprünglichen Beitrag oben:

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".
22

Ich werde dem noch mehr hinzufügen. Ich betreibe ein schlankes System (1 GB RAM) und eine kleine Website. Sie hat 2 Unicorn-Worker, und jeder von ihnen verbrauchte 30 % des Speichers, was zu viel Speicher-Thrashing verursachte. Daher beschloss ich, die Anzahl von 2 auf 1 zu reduzieren (von denen ich glaube, dass sie jeweils etwa 10 gleichzeitige Verbindungen verarbeiten können). Dies machte einen RIESIGEN Unterschied, die Seitenaufrufe waren fast augenblicklich und der Swap-Speicher wurde um das 5-10-fache reduziert (abhängig davon, was geladen wurde).

Der Nachteil, den ich jetzt sehe, ist, dass ich keine Browser-Upgrades mehr verwenden kann, um Discourse zu aktualisieren. Wenn ich versuche, über einen Browser zu aktualisieren, erhalte ich:

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

Also nur etwas, das man beachten sollte. Ich bin mir nicht sicher, ob das etwas ist, das das Discourse-Team herausfinden/beheben kann – Browser-Upgrades mit einem einzigen Unicorn-Worker durchzuführen.

2 „Gefällt mir“
23

Das scheint ein Fehler zu sein, zumal das System kurz darauf vorübergehend auf einen einzigen Unicorn reduziert wird.

Die Zahl 2 ist fest einprogrammiert, ebenso wie die Zahl 1 für die Reduzierung.

Bearbeitung: Es sieht so aus, als hätte diese Änderung die Inkonsistenz eingeführt

Ich denke, Ihr Beitrag (und diese Antwort) sollten in einem neuen Thread in der Kategorie Bugs erstellt werden.

4 „Gefällt mir“
25

Wie funktioniert das?

Ein Unicorn zur Handhabung des Upgrade-Prozesses, während die übrigen die laufenden Anrufe bedienen?

Und somit sind mindestens 2 Unicorn Workers für Online-Upgrades erforderlich …?

26

Das ist falsch. Ein einzelnes Unicorn kann nur eine Anfrage gleichzeitig bearbeiten, daher ist es zwar für kleine Gruppen nutzbar, aber wir würden es für die meisten Websites nicht empfehlen.

1 „Gefällt mir“
27

@Falco Ich habe mir die Daten anderer Administratoren angesehen. Soweit ich weiß, erstellt jeder Unicorn für jede eingehende Verbindung einen neuen Prozess. Während es sich also technisch gesehen um eine Verbindung nach der anderen handelt, kann jeder Unicorn mehrere gleichzeitige Benutzer verarbeiten.

Basierend auf den unten geteilten Erfahrungen können etwa 8 Unicorns ungefähr 400 gleichzeitige Benutzer verarbeiten.

Basierend darauf scheint es, dass jeder Unicorn etwa 50 gleichzeitige Benutzer verarbeiten kann. Ich weiß, dass RAM und Systemressourcen einen Unterschied bei der Anzahl der möglichen Forks usw. machen, daher meine Annahme, dass 1 Unicorn-Worker auf einem System mit wenig RAM (1 GB) am unteren Ende 10 gleichzeitige Benutzer verarbeiten kann.

Liege ich mit meinen Annahmen + Schlussfolgerungen völlig daneben? Wenn ja, in welchem Bereich könnten gleichzeitige Benutzer liegen, die jeder Unicorn je nach Systemressourcen verarbeiten kann (angenommen 1 GB am unteren Ende und alles, was Sie für angemessen halten, am oberen Ende)?

1 „Gefällt mir“
28

Es gibt einen Unterschied zwischen gleichzeitigen Benutzersitzungen und gleichzeitigen Verbindungen. Eine Sitzung ist ein Online-Benutzer, und jeder von ihnen stellt eine Anfrage (Verbindung), wann immer er interagiert.

Das tut er nicht. Unicorn spaltet sich beim Start in eine bestimmte Anzahl von Worker-Prozessen auf.

1 „Gefällt mir“
29

Und, ich glaube, wir haben gesehen, dass jeder Worker-Prozess 10 Threads ausführt.