Job-Ausnahme: JavaScript wurde beendet (entweder durch Timeout oder explizit)

Unterstützung Installation
1

Ich habe eine ältere Discourse-Installation (1.9.0.beta5) auf eine frische Droplet auf Digital Ocean mit der allerneuesten Version migriert. Da die alte Version so alt war, war ich nicht sicher, ob alles korrekt übertragen würde, aber es scheint gut zu funktionieren.

Außer dass es alle paar Stunden abstürzt.

Hier ist das Fehlerprotokoll, das ich heute um 00:57 Uhr erhalten habe:

Nachricht

Job-Ausnahme: JavaScript wurde beendet (entweder durch Timeout oder explizit)

Rückverfolgung

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:201:in `eval_unsafe'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:201:in `block (2 levels) in eval'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:307:in `timeout'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:200:in `block in eval'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:198:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_racer-0.2.6/lib/mini_racer.rb:198:in `eval'
/var/www/discourse/lib/es6_module_transpiler/tilt/es6_module_transpiler_template.rb:122:in `block in module_transpile'
/var/www/discourse/lib/es6_module_transpiler/tilt/es6_module_transpiler_template.rb:81:in `block in protect'
/var/www/discourse/lib/es6_module_transpiler/tilt/es6_module_transpiler_template.rb:80:in `synchronize'
/var/www/discourse/lib/es6_module_transpiler/tilt/es6_module_transpiler_template.rb:80:in `protect'
/var/www/discourse/lib/es6_module_transpiler/tilt/es6_module_transpiler_template.rb:115:in `module_transpile'
/var/www/discourse/lib/pretty_text.rb:42:in `apply_es6_file'
/var/www/discourse/lib/pretty_text.rb:61:in `block in ctx_load_manifest'
/var/www/discourse/lib/pretty_text.rb:58:in `each_line'
/var/www/discourse/lib/pretty_text.rb:58:in `ctx_load_manifest' /var/www/discourse/lib/pretty_text.rb:83:in `create_es6_context'
/var/www/discourse/lib/pretty_text.rb:124:in `block in v8'
/var/www/discourse/lib/pretty_text.rb:122:in `synchronize'
/var/www/discourse/lib/pretty_text.rb:122:in `v8'
/var/www/discourse/lib/pretty_text.rb:144:in `block in markdown'
/var/www/discourse/lib/pretty_text.rb:411:in `block in protect'
/var/www/discourse/lib/pretty_text.rb:410:in `synchronize'
/var/www/discourse/lib/pretty_text.rb:410:in `protect'
/var/www/discourse/lib/pretty_text.rb:143:in `markdown'
/var/www/discourse/lib/pretty_text.rb:257:in `cook'
/var/www/discourse/app/models/post_analyzer.rb:33:in `cook'
/var/www/discourse/app/models/post.rb:289:in `cook'
/var/www/discourse/lib/cooked_post_processor.rb:30:in `initialize'
/var/www/discourse/app/jobs/regular/process_post.rb:25:in `new'
/var/www/discourse/app/jobs/regular/process_post.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:192:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:165:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:164:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:137:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:109:in `local'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:136:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:132:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:250:in `stats'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:127:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_logger.rb:8:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:126:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:74:in `global'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:125:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:48:in `with_context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:42:in `with_job_hash_context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:124:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:163:in `process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:83:in `process_one'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:71:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:16:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:25:in `block in safe_thread'

Umgebung

|hostname|dow-18-app|
| --- | --- |
|process_id|8390|
|application_version|800e49f16e43e0783d30971e84a4e4619d448a7c|
|current_db|default|
|current_hostname|forum.driveonwood.com|
|job|Jobs::ProcessPost|
|problem_db|default|
||opts null

post_id 94118
--- ---
bypass_bump true
new_post false
current_site_id default|

Die Seite war heute Morgen nicht erreichbar, als ich sie laden wollte; ich erhielt einen 504-Fehler. Der Server lief noch, und das Protokoll in ./launcher log app zeigte dies wiederholt:

ok: run: redis: (pid 48) 11912s
ok: run: postgres: (pid 47) 11912s
supervisor pid: 26654 unicorn pid: 26658
config/unicorn_launcher: line 71: kill: (26658) - No such process
config/unicorn_launcher: line 15: kill: (26658) - No such process
(26654) exiting

Nach einem Neustart um 9 Uhr lief die Seite einige Stunden lang problemlos, dann stürzte sie erneut um 11:04 Uhr ab. Die Fehlerprotokolle waren an beiden Stellen im Wesentlichen identisch. Ein erneuter Neustart löste das Problem (vorläufig). Ich werde die Seite weiter beobachten und bei Bedarf neu starten, bis ich das Problem gelöst habe.

Die Seite ist hier: http://forum.driveonwood.com

2

Das liegt wahrscheinlich an der Auslastung. Wie sieht es mit der CPU auf Ihrem Server aus? Wie ist der Speicherverbrauch?

3

Die Seite scheint seit diesen beiden Abstürzen stabil zu sein. CPU- und Speicherauslastung sind normal. Ich weiß nicht, wie sie während der Ausfallzeit waren. Vielleicht gab es anfangs aufgrund des Übergangs eine hohe Last.

Ich werde diesen Thread aktualisieren, falls etwas passiert.

4

Gerade abgestürzt. Ich habe den Server erneut neu gestartet, und er nutzt derzeit 70–80 % der CPU. Aus irgendeinem Grund konvertiert er JPG-Dateien, und wir haben eine große Anzahl an Fotos. Ich werde bei Bedarf neu starten; hoffentlich ist dies eine einmalige Aufgabe.

5

Ist heute wieder abgestürzt. Vor dem Neustart habe ich notiert, dass 97 % der CPU von diesem Prozess beansprucht werden:

ruby /var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn -E production -c config/unicorn.conf.rb

Gesamte Speichernutzung:

  3073648 K Gesamtspeicher
  904712 K genutzter Speicher
 1510576 K aktiver Speicher
  376240 K inaktiver Speicher
  815448 K freier Speicher
  306872 K Pufferspeicher
 1046616 K Swap-Cache
       0 K Gesamtswap
       0 K genutzter Swap
       0 K freier Swap

Haben Sie Hinweise dazu, was dieser spezifische Prozess macht?

6

Die Art und Weise, wie Bilder gespeichert werden, hat sich vor einiger Zeit geändert, und sie werden derzeit alle verarbeitet. Es gibt Maßnahmen, die einen Absturz verhindern sollen, aber das reicht für Sie nicht aus. Ich würde empfehlen, Ihr RAM vorübergehend zu erhöhen, bis alle Bilder verarbeitet sind.

Ich glaube, es gibt eine Site-Einstellung, die steuert, wie viele Bilder pro Batch verarbeitet werden, aber ich kann mich im Moment nicht genau daran erinnern, wie sie heißt.

7

Danke. Ich habe so etwas vermutet. Wir haben 15 GB an Bildern.

Ich werde es im Auge behalten und bei Bedarf einfach neu starten.

8

Genauer gesagt wird das Attribut srcset nun auf dem <img>-Tag unterstützt, sodass Retina-Geräte Bilder in höherer Auflösung anzeigen. Dies hat als Nebeneffekt mehr Kopien von Bildern zur Folge, da Sie für dieselbe Bildquelle mehrere Anzeigedichten bereitstellen müssen.

Siehe https://html.com/attributes/img-srcset/