Exception de tâche : JavaScript a été arrêté (soit par dépassement de délai soit explicitement)

Soutien Installation
1

Je viens de migrer une ancienne installation Discourse (1.9.0.beta5) vers un nouveau droplet chez Digital Ocean avec les dernières versions de tout. Étant donné son ancienneté, je ne savais pas si tout serait correctement transféré, mais il semble que cela fonctionne bien.

Sauf qu’il plante toutes les quelques heures.

Voici le journal d’erreur que j’ai obtenu à 00h57 ce matin :

Message

Exception de tâche : JavaScript a été terminé (soit par dépassement de délai, soit explicitement)

Backtrace

/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'

Env

|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|

Le site était non réactif lorsque j’ai essayé de le charger ce matin ; j’ai obtenu une erreur 504. Le serveur était toujours en cours d’exécution, et le journal dans ./launcher log app affichait ceci de manière répétée :

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

Après un redémarrage à 9h, le site a fonctionné correctement pendant quelques heures, puis il a à nouveau planté à 11h04. Les journaux d’erreur sont substantiellement identiques dans les deux cas. Un nouveau redémarrage a résolu le problème (pour l’instant). Je vais surveiller la situation et redémarrer au besoin jusqu’à ce que je résolve ce problème.

Le site est ici : http://forum.driveonwood.com

2

Cela est probablement lié à la charge. Comment se présente le CPU sur votre serveur ? Et la mémoire ?

3

Le site semble stable depuis ces deux plantages. L’utilisation du CPU et de la mémoire est normale. Je ne sais pas comment elle était pendant l’indisponibilité. Peut-être y avait-il une charge importante au début en raison de la transition.

Je mettrai à jour ce fil si quelque chose se produit.

4

Juste planté. J’ai redémarré le serveur à nouveau, et il utilise actuellement 70-80 % du CPU. Il convertit des fichiers JPG pour une raison inconnue, et nous avons beaucoup de photos. Je redémarrerai si nécessaire, j’espère que c’est une tâche ponctuelle.

5

Planté à nouveau aujourd’hui. Avant de redémarrer, j’ai noté que 97 % du processeur était utilisé par ce processus :

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

Utilisation globale de la mémoire :

  3073648 K mémoire totale
  904712 K mémoire utilisée
 1510576 K mémoire active
  376240 K mémoire inactive
  815448 K mémoire libre
  306872 K mémoire tampon
 1046616 K cache swap
       0 K swap totale
       0 K swap utilisée
       0 K swap libre

Avez-vous des informations sur ce que fait précisément ce processus ?

6

La façon dont les images sont stockées a changé il y a quelque temps et elles sont toutes en cours de traitement. Il existe des mécanismes censés empêcher les plantages, mais ils ne suffisent pas dans votre cas. Je vous recommande d’augmenter votre RAM pendant un certain temps, jusqu’à ce que tout soit terminé.

Je pense qu’il existe un paramètre du site qui contrôle le nombre d’images traitées par lot, mais je ne me souviens plus exactement de son nom à l’instant.

7

Merci. Je soupçonnais quelque chose comme ça. Nous avons 15 Go d’images.

Je vais surveiller cela et redémarrer simplement si nécessaire.

8

Plus précisément, l’attribut srcset est désormais pris en charge sur la balise <img>, ce qui permet aux appareils rétina d’afficher des images en plus haute résolution. Cela entraîne, comme effet secondaire, la création de plusieurs copies des images, car vous devez servir plusieurs densités d’affichage pour une même image.

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