作业异常:JavaScript 已终止(因超时或显式终止)

我刚刚将一个较旧版本的 Discourse 安装(1.9.0.beta5)迁移到了 Digital Ocean 上一台全新配置的 droplet,系统已更新至最新版本。鉴于旧版本年代久远,我原本不确定所有数据都能正确迁移,但看起来运行正常。

不过,它每隔几小时就会崩溃。

这是今天凌晨 12:57 收到的错误日志:

消息

作业异常:JavaScript 已终止(因超时或显式终止)

回溯

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

环境

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

今天早上我尝试访问网站时,网站无响应,返回了 504 错误。服务器仍在运行,但 ./launcher log app 日志中反复显示以下内容:

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

在上午 9 点重启后,网站正常运行了几个小时后,于上午 11:04 再次崩溃。两处的错误日志基本相同。再次重启暂时解决了问题。我会持续监控,并在需要时重启,直到彻底解决此问题。

网站地址:http://forum.driveonwood.com

这很可能与负载有关,您服务器的 CPU 使用情况如何?内存呢?

自从那两次崩溃后,网站似乎已恢复稳定。CPU 和内存使用率正常。我不清楚停机期间的情况。也许在过渡初期存在一些高负载。

刚崩溃了。我再次重启了服务器,目前 CPU 占用率在 70-80% 之间。不知为何它正在转换 JPG 图片,而我们的照片数量很多。我会按需重启,希望这只是一次性任务。

今天又崩溃了。重启前,我注意到 97% 的 CPU 被这个进程占用:

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

总体内存使用情况:

  3073648 K 总内存
  904712 K 已用内存
 1510576 K 活跃内存
  376240 K 非活跃内存
  815448 K 空闲内存
  306872 K 缓冲内存
 1046616 K 交换缓存
       0 K 总交换空间
       0 K 已用交换空间
       0 K 空闲交换空间

有人知道这个特定进程具体是做什么的吗?

图像的存储方式不久前已更改,目前所有图像都在处理中。虽然有一些机制本应防止崩溃,但对您的情况来说还不够。建议您暂时增加内存,直到所有图像处理完成。

我记得有一个站点设置可以控制每批处理的图像数量,但此刻一时想不起具体是什么。

谢谢。我早就怀疑会有这种情况。我们有 15 GB 的图片。

我会密切关注,并视情况重启。

更具体地说,srcset 属性现在已支持在 <img> 标签上使用,因此视网膜设备可以看到更高分辨率的图像。这意味着作为副作用会产生更多的图片副本,因为您需要用同一张图片服务于多种显示密度。

参见 https://html.com/attributes/img-srcset/