I, [2024-04-17T09:57:04.110084 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake assets:precompile:build'
97:M 17 Apr 2024 10:01:01.012 * 100 изменений за 300 секунд. Сохранение...
97:M 17 Apr 2024 10:01:01.012 * Фоновое сохранение запущено процессом с PID 3733
3733:C 17 Apr 2024 10:01:01.026 * База данных сохранена на диск
3733:C 17 Apr 2024 10:01:01.027 * Fork CoW для RDB: текущее значение 1 МБ, пиковое 1 МБ, среднее 0 МБ
97:M 17 Apr 2024 10:01:01.112 * Фоновое сохранение завершено успешно
97:M 17 Apr 2024 10:56:01.848 * Буфер репликации освобождён после 3600 секунд без подключённых реплик.
На сервере 64 ГБ оперативной памяти, поэтому я не думаю, что проблема в нехватке памяти, хотя в контейнере я указал db_shared_buffers: "4096MB", как рекомендовано в инструкциях по настройке.
Есть какие-то идеи, что происходит? Как провести диагностику? Как исправить?
Спасибо, Джей. Я ждал два часа и сделал это (это архивный форум, поэтому простои меня не сильно беспокоили).
Единственное, что я сделал иначе, — добавил - git clone https://github.com/discourse/discourse-calendar, но заметил, что в конце нет .git. Не знаю, имело ли это какое-то значение.
С тех пор, как возникла эта проблема, у нас начались трудности с сервером. Когда это произошло впервые, мы заметили, что другие Ruby-сайты на сервере стали недоступны. Это случалось дважды с интервалом в несколько дней, и перезагрузка решала проблему (эти сайты используют аутентификацию через Discourse). Только что это произошло снова, но на этот раз два форума Discourse также возвращали ошибку 504 Gateway Time-out.
Я заметил, что у других пользователей возникала похожая проблема с зависанием процесса rebuild, и хочу узнать, не изменилось ли что-то в Discourse недавно, что могло бы быть связано с этим? Изменяет ли Discourse что-либо за пределами контейнеров, например системный Ruby? Это очень странно
Вчера было выпущено исправление, позволяющее серверам с малым объемом ОЗУ перестраивать мир гораздо быстрее и странным образом, но, возможно, оно не сработает, так как проверка рассчитана на 2 ГБ, а ваша проблема, скорее всего, в том, что у вас больше 2 ГБ, но вся память занята другими процессами на сервере.
Мне кажется, вам просто нужно больше оперативной памяти.
У сервера 64 ГБ оперативной памяти, Джей, и каждый экземпляр DC настроен с параметром db_shared_buffers: "4096MB".
Кроме того, эти дополнительные проблемы возникли не во время восстановления, а, похоже, являются остаточным явлением той самой первоначальной проблемы.
Я выполню очистку Docker (./launcher cleanup), чтобы посмотреть, поможет ли это, но если у вас или у кого-либо ещё появятся другие идеи, буду очень признателен.
Редактирование: только что заметил что-то странное после выполнения команды docker container ls -a, создам новую тему об этом.
