Ошибка задания: JavaScript был остановлен (по таймауту или явно)

Я только что перенёс старую установку Discourse (версия 1.9.0.beta5) на новый дроплет в Digital Ocean с самым свежим ПО. Учитывая возраст старой версии, я не был уверен, что всё перенесётся корректно, но вроде всё работает нормально.

За исключением того, что сервер падает каждые несколько часов.

Вот лог ошибки, полученный сегодня в 00: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:00 сайт работал нормально несколько часов, но затем снова упал в 11:04. Ошибки в логах в обоих случаях практически идентичны. Повторная перезагрузка решила проблему (пока что). Буду следить за ситуацией и перезагружать сервер по мере необходимости, пока не найду решение.

Сайт находится здесь: http://forum.driveonwood.com

Скорее всего, это связано с нагрузкой. Как обстоят дела с загрузкой процессора на вашем сервере? А с памятью?

Сайт, похоже, стабилен после двух сбоев. Загрузка процессора и использование памяти в норме. Не знаю, какие показатели были во время простоя. Возможно, изначально была высокая нагрузка из-за перехода.

Я обновлю эту тему, если что-то произойдёт.

Только что произошел сбой. Я перезагрузил сервер, и сейчас он использует 70–80% процессора. По какой-то причине он конвертирует файлы JPG, а у нас много фотографий. Буду перезагружать по мере необходимости, надеюсь, это разовая задача.

Снова упал сегодня. Перед перезагрузкой я заметил, что 97% процессора уходит на этот процесс:

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 ГБ изображений.

Я буду следить за этим и перезагружать систему по мере необходимости.

Более конкретно, теперь атрибут srcset поддерживается в теге <img>, поэтому устройства с Retina-дисплеями получают изображения в более высоком разрешении. Это означает, что как побочный эффект создаётся больше копий изображений, так как нужно обслуживать одно и то же изображение для нескольких плотностей дисплея.

См. https://html.com/attributes/img-srcset/