Высокое использование памяти без трафика?

Поддержка
1

Итак, я тестирую Discourse как возможную платформу для нашего существующего форума и пытаюсь разобраться с требованиями к ресурсам.

В данный момент я запускаю Droplet с Discourse на узле DigitalOcean с 4 виртуальными ядрами процессора и 8 ГБ оперативной памяти.

При импортированном сайте vBulletin, который работает здесь без трафика и активности, система изначально использует около 75% из этих 8 ГБ оперативной памяти, а за несколько дней потребление возрастает до 100%, после чего сервер перестает отвечать.

Это меня сбивает с толку, поскольку минимальные требования, кажется, значительно ниже.

(Я пересоздавал контейнер, проверял и очищал задачи Sidekiq, но использование памяти по-прежнему высокое.)

Есть ли у кого-нибудь советы, или мне стоит рассматривать конфигурацию с огромным объемом оперативной памяти только для того, чтобы форум оставался доступным?

2

Сколько постов было импортировано?

Система может повторно обрабатывать посты и изменять размер изображений, что может потребовать значительных ресурсов, даже если у вас нет пользователей. Вы можете проверить /sidekiq, чтобы увидеть, есть ли в очереди или выполняются ли какие-либо задания. Также htop может дать вам представление о том, что выполняется.

3

Около 240 000 сообщений.

Импорт был примерно 5 недель назад. С тех пор приложение пересобиралось 5 раз, так как это, похоже, решает проблему с памятью, когда контейнер достигает 100% использования памяти и перестает отвечать.

Все задачи в Sidekiq были очищены, как упоминалось, но использование памяти всё ещё составляет 75%.

График использования памяти с момента пересборки сервера вчера:

ОЗУ: 8 ГБ

image
image998×311 15.7 KB

ЦП

image
image1002×315 45.1 KB

Трафик

image
image997×312 23.5 KB

Sidekiq

image
image1230×607 77.8 KB

4

На мой взгляд, это похоже на медленную утечку памяти, которая приведёт к её исчерпанию через несколько дней… (что, кстати, уже наблюдалось до сих пор.

5

После импорта для оптимизации производительности базы данных всегда рекомендуется создать резервную копию и восстановить её в том же экземпляре.

График памяти включает кэш или исключает его? (т. е. как выглядит вывод команды free -m?)

Есть ли плагины?

6

image
image756×111 15.8 KB

## Плагины размещаются здесь
## подробности см. по адресу https://meta.discourse.org/t/19157
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-data-explorer.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-cakeday.git
          - git clone https://github.com/discourse/discourse-spoiler-alert.git
          - git clone https://github.com/discourse/discourse-user-card-badges.git
          - git clone https://github.com/discourse/discourse-adplugin.git
7

Отличная идея. Определённо попробую.

8

Из-за этого сайт перестал отвечать… (Сделана резервная копия, восстановлена из резервной копии, затем выполнена перезагрузка)

image
image1015×379 130 KB

Использование оперативной памяти выросло с 6 ГБ до 7 ГБ, и сайт не отвечает.

9

Redis использует почти 5 ГБ, поэтому для Discourse остаётся очень мало места, особенно учитывая, сколько процессов unicorn вы запускаете.

Если очередь Sidekiq чистая, попробуйте очистить Redis, так как после импорта в нём может накопиться слишком много мусора:

./launcher enter app
redis-cli flushall
10

Понял, попробую команду redis.

Проблема с воркерами unicorn была тем, что я проверил довольно рано. Я изменил использование оперативной памяти для db_shared_buffers, а также установил количество воркеров unicorn на 3.

Однако настройка воркеров unicorn, похоже, мало влияет или вообще не влияет на количество фактически запущенных воркеров.

Из моего файла app.yml

  ## Сколько одновременных веб-запросов поддерживается? Зависит от объема памяти и количества ядер процессора.
  ## Будет установлено автоматически загрузочным скриптом на основе обнаруженных процессоров, или вы можете переопределить
  UNICORN_WORKERS: 3
11

Эта команда flushall творила чудеса — объём использования снизился до 2 ГБ. Посмотрим, сохранится ли такой результат.

Тревожным моментом было то, что данные продолжали расти. Надеюсь, теперь приложение сможет лучше управлять собой самостоятельно.

В любом случае… значит, импорт хранит данные в Redis постоянно? Это кажется странным, но я не знаю, как работает Redis.

Огромное спасибо за помощь!

image
image1023×319 11.4 KB