Привет!
У меня работает Discourse в Docker, и он почему-то никогда не использует swap, когда оперативной памяти не хватает. Из-за этого приложение падает или выдает ошибку fatal error: out of memory allocating heap arena map, если я пытаюсь пересобрать образ. Без перезагрузки каждые несколько часов всё не работает.
Подскажите, пожалуйста, как это исправить?
Спасибо,
Кьян
Предполагая, что вы используете Linux, что показывает команда free -h? (Желательно сразу после перезагрузки, а также незадолго до возникновения ошибки.)
возможно, swappiness установлен в 0?
cat /proc/sys/vm/swappiness
Привет!
Раньше было 40, теперь я установил на 60.
Система всегда кэширует большие объемы оперативной памяти, и подкачка никогда не используется, даже при высокой загрузке RAM.
Я думаю, что на две части вывода стоит обратить особое внимание: это 5,5 ГБ доступной памяти и 0 Б использованного свопа. Или, возможно, 9 ГБ свободного свопа. Сумма 5,5 ГБ + 9 ГБ показывает, какой запас у вас есть. Объем памяти, используемый для буферов и кэша, динамичен и никогда не должен приводить к нехватке ресурсов.
Учитывая время до сбоя всего в несколько часов, я бы запустил vmstat 5 и сохранил вывод так, чтобы можно было увидеть последние моменты перед падением. Раньше я использовал cron-задачу для запуска vmstat 5 5 с записью в лог-файл каждые 10 минут.
Возможно, из-за некорректно работающего ПО все доступные ресурсы будут исчерпаны очень быстро. В таком случае может быть очень полезен лог команды ps uax, записываемый каждые несколько минут, чтобы получить несколько снимков состояния в критические моменты.
Также возможно, что в игру вступают какие-то другие ограничения. Предположительно, это чистая установка на чистую ОС, без запущенных дополнительных служб и без специальной конфигурации?
Привет!
Как мне настроить запись вывода команды vmstat 5 в лог каждые 10 минут? И как сделать так, чтобы ps uax записывал данные в лог каждые несколько минут?
Да, это чистая установка Ubuntu Server 18.04. Установлены только Apache, Docker и подобное.
Я только что вспомнил, что у меня установлен Varnish Cache, что объясняет использование RAM для кэширования. Но я не понимаю, почему Discourse не использует подкачку (swap). Несколько дней назад я установил лимит подкачки для него с помощью команды Docker, но это не помогло.
Вот однострочная команда, которая проста и эффективна (хотя cron — более правильный подход):
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
Она будет работать бесконечно: чтобы остановить, выполните touch /tmp/stop.
Лог появится в /var/log/monitor.log — используйте tail -99, чтобы увидеть последние записи, или less, чтобы пролистать его. Вам нужно будет найти в логе те участки, где проявляется проблема.
Кажется, вы задаёте себе не тот вопрос. За виртуальную память, включая использование буферов и swap, отвечает ядро Linux. Если free показывает, что swap настроен, это нормально, и вам не нужно ничего делать.
Ваш настоящий вопрос должен звучать так: почему Discourse работает плохо, почему его приходится перезапускать и почему я вижу fatal error?
Настоятельно рекомендую переименовать эту тему в:
«Почему возникает ошибка
Хм, что именно вы сделали? Что показывает команда
docker stats --no-stream --no-trunc
в столбцах MEM USAGE / LIMIT и MEM %?
(В моём случае LIMIT немного меньше объёма физической памяти машины. Возможно, это означает, что процессы внутри контейнера вряд ли вызовут подкачку, и вы можете столкнуться с ошибкой выделения памяти даже при практически неиспользуемой подкачке.)
Привет!
Похоже, Discourse упал, так как при переходе на домен я получаю ошибку Nginx 502 Bad Gateway. Однако контейнер Docker всё ещё запущен.
Да, кроме редких случаев.
Я пересобрал его, так как это часто на какое-то время исправляет ошибку 502 Bad Gateway.
Также я перезагружаю сервер, чтобы проверить, исправит ли это ошибку. Часто это помогает, но скорее всего нет, и пересборка на какое-то время решает проблему.
Скоро я также получу этот лог ошибок.
При запуске /var/log/monitor.log с помощью tail -99 я получаю: -bash: /var/log/monitor.log: Отказано в доступе
(Судя по вашему скриншоту, контейнер с именем “app” имеет лимит памяти 7,8 ГБ и использует всего 3%, так что всё в порядке. Редакция: но может показаться подозрительным, что он использует 100% процессора.)
Нам просто нужно посмотреть конец этого файла журнала, поэтому
tail -199 /var/log/monitor.log
может дать нам то, что нужно. Но, возможно, нам потребуется просмотреть больше данных: может быть, вы сможете заархивировать файл журнала и прикрепить его или поделиться им другим способом. Каков размер файла журнала?
ls -l /var/log/monitor.log
Я думаю, что 100% — это 1 ядро. Потому что система работает нормально.
log.txt|вложение (25,0 КБ)
199 строк лога.
monitor.txt (39.3 КБ)
Вот полный лог 
Спасибо. Всё выглядит нормально, но это лишь один снимок. Ожидается, что каждые 10 минут к логу будет добавляться новый раздел. Подождите, пока не обнаружите проблему в вашем Discourse, а затем поделитесь последними несколькими разделами.
Должен сказать, я не понимаю, что происходит.
Я заметил, что ваши три юникорна потребляют много процессорного времени, и не знаю, почему это должно быть так.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \_ unicorn worker[2] -E production -c config/unicorn.conf.rb
Вы можете запустить top и нажать shift+m, чтобы отсортировать процессы по использованию оперативной памяти и увидеть, что потребляет больше всего памяти. Можете ли вы опубликовать результат здесь?
