ich betreibe eine selbst gehostete Discourse-Installation (2026.5.0-latest). Heute habe ich versucht, YJIT zu aktivieren. Ich habe "templates/enable-ruby-yjit.yml" zu containers/app.yml hinzugefügt und die App neu aufgebaut.
Nach Abschluss des Neubaus geschah etwas Interessantes. Innerhalb des Docker-Containers führte ich env | grep RUBY_YJIT_ENABLE aus und erhielt RUBY_YJIT_ENABLE=1. Bisher alles gut. Als ich dann sudo -u discourse RAILS_ENV=production bundle exec rails runner 'puts "YJIT enabled: #{RubyVM::YJIT.enabled?}"; puts RUBY_DESCRIPTION' ausführte, bekam ich jedoch Folgendes:
YJIT war also nicht aktiviert, obwohl ich die Vorlage enable-ruby-yjit.yml hinzugefügt hatte. Als ich daraufhin sudo -u discourse RAILS_ENV=production bundle exec rails runner 'puts "GlobalSetting.yjit_enabled=#{GlobalSetting.yjit_enabled}"' ausführte, erhielt ich GlobalSetting.yjit_enabled= – einen nil-Wert!
Nach einigem Herumprobieren habe ich YJIT schließlich aktiviert, indem ich Folgendes zu containers/app.yml hinzufügte:
env:
DISCOURSE_YJIT_ENABLED: true
Ich bin mir sicher, dass es irgendwo einen Fehler gibt (GlobalSetting.yjit_enabledsollte niemals nil zurückgeben), aber das Setzen der Umgebungsvariable hat funktioniert. Ich hoffe, jemand, der nach diesem Problem googelt, wird diesen Beitrag finden.
Ist das nicht eine Fehldiagnose? Du prüfst die Umgebungsvariablen eines neu gestarteten Ruby-Prozesses anstelle der des tatsächlich laufenden Webservers.
Wenn du /proc/<pid>/environ des Pitchfork-Mold-Prozesses inspizierst, wirst du die YJIT-Umgebungsvariable dort sehen.
Das Vorhandensein einer Umgebungsvariablen gibt keine Auskunft darüber, ob Ruby aktuell mit aktiviertem YJIT läuft. In diesem speziellen Fall ist die Umgebungsvariable zwar gesetzt, aber etwas anderes überschreibt die Variable, die Rails verwendet, um YJIT beim Start zu aktivieren (oder deaktivieren). Es gibt keine andere Erklärung dafür, warum GlobalSetting.yjit_enabled= selbst bei einer neuen Rails-Instanz nil zurückgibt. Ebenso gibt es keinen Grund, warum YJIT bei einer neuen Rails-Instanz deaktiviert sein sollte.
Nachdem ich die Umgebungsvariable DISCOURSE_YJIT_ENABLED zu meiner containers/app.yml hinzugefügt habe:
sudo -u discourse RAILS_ENV=production bundle exec rails runner 'puts "YJIT enabled: #{RubyVM::YJIT.enabled?}"; puts RUBY_DESCRIPTION' gibt YJIT enabled: true zurück.
Der Speicherverbrauch auf meinem Server steigt endlich leicht an.
Ich sehe eine echte Geschwindigkeitssteigerung auf meinem Forum.
Es sollte einfach sein, meine Ergebnisse nachzuvollziehen. Fügen Sie einfach die Vorlage hinzu und prüfen Sie es.
Das ist falsch. Auf Ruby-Ebene ist die ENV-Variable einer der offiziellen Schalter. Siehe dazu die offizielle Ruby-Dokumentation:
Das ist falsch, denn DISCOURSE_YJIT_ENABLED speist nur GlobalSetting.yjit_enabled → config.yjit in config/application.rb. Rails nutzt dies, um YJIT zu aktivieren, falls es noch nicht aktiviert ist. Es deaktiviert kein bereits aktiviertes YJIT. Wenn also die Umgebungsvariable gesetzt ist, hat DISCOURSE_YJIT_ENABLED keine Wirkung.
Um meinen Punkt weiter zu untermauern, habe ich ein Plugin geschrieben, das angibt, ob YJIT in meinem Web-Prozess aktiviert ist:
Huch! Also meinst du, wir können die Umgebungsvariable zuverlässig nutzen, um zu erkennen, ob YJIT aktiviert ist! Das wusste ich nicht; danke für den Link zur Ruby-Dokumentation.
Ich bin jedoch bei etwas etwas verwirrt. Wie ist es möglich, dass env | grep RUBY_YJIT_ENABLERUBY_YJIT_ENABLE=1 zurückgibt, eine neue Rails-Instanz im selben Container jedoch bei der Abfrage von #{RubyVM::YJIT.enabled?}false ausgibt? Sollte es nicht true ausgeben, da – wie du erwähnt hast – diese Umgebungsvariable auf Ruby-Ebene funktioniert?
Du bist wahrscheinlich sehr beschäftigt, und das ist auch nicht weiter wichtig, also keine Notwendigkeit zu antworten. Ich sollte das auf meinem eigenen Server selbst herausfinden können. Hättest du zufällig dein Plugin? Ich brauche eine Möglichkeit, sicher zu sein, dass mein Discourse-Server auf einem Ruby mit aktiviertem YJIT läuft.
Ich werde deine Antwort als Lösung markieren, sobald ich es nachvollzogen habe.
sudo -u discourse bereinigt die Umgebungsvariablen. Mit der -E-Option wird die normale Umgebung mitübergeben, und in diesem Fall gibt sudo -E -u discourse RAILS_ENV=production bundle exec rails runner 'puts "YJIT aktiviert: #{RubyVM::YJIT.enabled?}"; puts RUBY_DESCRIPTION' Folgendes zurück:
Ich entschuldige mich dafür, dass ich Ihre Zeit verschwendet habe, und habe Ihre Antwort als Lösung markiert. Entschuldigen Sie bitte diese Umstände. Vielen Dank, dass Sie dem nachgegangen sind und sich die Zeit für eine Antwort genommen haben.