После обнаружения выпуска версии 3.3.0-beta1 я сразу же обновил свой экземпляр Discourse через веб-интерфейс.
Однако в процессе обновления логи веб-интерфейса зависли более чем на пятнадцать минут без дальнейшего вывода (кажется, последним выводом была серия растущих многоточий? Возможно, я немного не уверен). Примерно через два часа я проверил статус сервера на платформе облачных услуг и предположил, что он завис, поэтому выполнил мягкую перезагрузку через эту платформу.
После перезагрузки я немедленно создал резервную копию Discourse через командную строку, загрузил её вместе с файлом app.yml на локальный компьютер, а затем полностью переустановил Discourse (разумеется, последнюю версию). После этого я загрузил резервную копию и запустил процесс восстановления через командную строку.
Восстановление прошло успешно, но теперь мой экземпляр Discourse столкнулся с серьёзными проблемами производительности. Раньше использование процессора в обычном режиме не превышало 10%, а теперь даже в часы низкой нагрузки оно подскакивает до 30%, а чтение с диска также значительно возросло. Хуже того, иногда сервер неожиданно падает: чтение с диска достигает около 1900 операций в секунду (это предел моего облачного сервера), а процессор более 40% времени находится в состоянии ожидания. Веб-страницы не загружаются, выдавая тайм-ауты соединения. В данный момент я запускаю vmstat и top, но, к сожалению, не сохранил их вывод. Помню, что обмен с подкачкой (swap IO) был почти нулевым, что указывает на чистое чтение с диска. Количество заблокированных потоков превышало 100.
Я подозреваю, что это неудачное обновление могло повредить что-то, возможно, данные внутри резервной копии, а не саму программу. Есть ли способ — э-э, не уверен — очистить кэш или выполнить подобные операции? Или, может быть… запустить обновление снова? (В конце концов, обновления Discourse происходят довольно часто, и обновить можно практически в любое время.)
В качестве временного решения я установил программный сторожевой таймер для автоматической перезагрузки при высокой нагрузке. Однако это не долгосрочное решение, и я не нашёл здесь подобных проблем; очевидно, дело не в самом программном обеспечении Discourse. Я хочу понять, как это исправить.
Если вам нужно, чтобы я выполнил какие-либо команды на сервере для проверки его состояния во время высокой нагрузки, пожалуйста, дайте знать. Я сделаю всё возможное, чтобы поддерживать соединение SSH и получить эти данные без перезагрузки.
