Установка Discourse становится всё медленнее и медленнее

Моя установка Discourse становится всё медленнее и медленнее в течение последних нескольких недель. В прошлом, когда это случалось, пересборка приложения помогала. Однако сейчас это, похоже, не работает.

Я искал советы на этом форуме и попробовал несколько оптимизаций базы данных (VACUUM FULL VERBOSE, REBUILD INDEX, VACUUM ANALYZE VERBOSE).

Однако ничего из этого не помогает, и при запуске контейнера проходит очень-очень долгое время, прежде чем я смогу подключиться к форуму.

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

Какого размера ваша база данных? Сколько у вас оперативной памяти?

Вывод команды

vmstat 5 5

может быть полезен в данном случае. (Запустите её в момент возникновения проблемы!)

Доступная память: (сверху)

iB Mem :  4041756 всего,   108980 свободно,  3834244 занято,    98532 буфер/кэш
KiB Swap:  1949692 всего,   972196 свободно,   977496 занято.    31140 доступно памяти

Вывод vmstat: (при попытке загрузки, которая выполняется очень-очень медленно)

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 9  2 1011424 108300  15308 122392   37   32   145   101    0    0  2  3 93  1  0
 5  2 1028312 114696   9976 101252 2104 3904  2176  3915  340 1939 41 38  1 19  0
 2  4 1054116 115892  10196 102260 1378 6803  4171  6826  870 1812 23 28  1 48  0
 0  4 1011420 257496  10860 108464 3427 3937  6223  3969  829 2788 15 28  2 55  0
 6  2 1001844 154328  12988 120800 4366  124  7166   161  742 2947 14 26  2 58  0
hubbe@tymin:~$ vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  4 1004748  85768  13948 114648   37   32   145   101    0    0  2  3 93  1  0
 0  6 1033260 108584  10212 101668 1566 6661  4368  6807  497 1990 11 27  0 61  0
12  7 1050808  99524  10708  94852 1932 4551  4854  4625  660 2263 24 32  2 42  0
 5  8 1078776 125060   9136  92948 2079 6963  5541  7030  771 2040 17 32  0 51  0
 4  3 1004784 168216  10164 103420 2631 1457  4970  1467  617 2136 34 38  1 27  0

PS: мой сайт доступен здесь, если это поможет: https://crucible.hubbe.net/

Как это проверить?

Discourse — единственное, что работает на этом сервере? Сколько юникорнов вы настроили в файле app.yml?

Это не единственное, но, безусловно, самое значительное.

Вот топ процессов по использованию памяти:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                       
 1818 hubbe     20   0  910068 159724  10272 S   0.0  4.0   0:31.17 ruby                                                                          
 6141 hubbe     25   5 1195492 140180  10080 S   4.2  3.5  11:31.61 ruby                                                                          
 1845 hubbe     20   0  908732 124036   9388 S   2.8  3.1   0:29.94 ruby                                                                          
 1780 hubbe     20   0  910076  82072   3796 S   0.0  2.0   0:28.40 ruby                                                                          
 1937 systemd+  20   0  360060  25632  21076 S   0.0  0.6   0:00.86 postmaster                                                                    
 2134 systemd+  20   0  356020  23608  19760 S   0.0  0.6   0:00.13 postmaster                                                                    
 1797 systemd+  20   0  355840  22620  19404 S   1.4  0.6   0:00.75 postmaster                                                                    
 2092 systemd+  20   0  356288  21644  17584 S   0.0  0.5   0:00.17 postmaster                                                                    
 2063 systemd+  20   0  355984  18364  16504 S   0.0  0.5   0:00.20 postmaster                                                                    
 1939 systemd+  20   0  355904  15668  15232 S   0.0  0.4   0:00.25 postmaster                                                                    
 2131 systemd+  20   0  353948  14804  13000 S   0.0  0.4   0:00.02 postmaster                                                                    
38770 root      20   0  689760  12940      0 S   0.0  0.3 434:00.34 dockerd                                                                       
43876 root      20   0   16492   9428   1608 S   0.0  0.2   3:34.89 roxen                                                                         
 5728 hubbe     20   0  574796   8136   2064 S   0.0  0.2   0:58.94 ruby                                                                          
37533 root      20   0  593420   5848   1020 S   2.8  0.1 539:40.11 containerd                                                                    
 5689 systemd+  20   0   96432   5832   1672 S   0.0  0.1   3:54.43 redis-server                                                                  
 2196 www-data  20   0  166248   4924   2580 S   0.0  0.1   1:18.03 nginx                                                                         
 2197 www-data  20   0  165972   4484   3168 S   0.0  0.1   1:29.32 nginx                                                                         

Почти всё в этом списке, кроме roxen, связано с Discourse.

UNICORN_WORKERS закомментирован в my.yml

Похоже, что сохранение поста особенно часто приводит к тайм-ауту и ошибке.
Не уверен, является ли это каким-либо указанием на то, что происходит.

Этот вывод vmstat говорит нам о том, что в текущей ситуации оперативной памяти недостаточно.

Возможно, Discourse работает как положено, и всё в порядке, но ваши данные выросли настолько, что 4 ГБ оперативной памяти уже не хватает.

Или же что-то пошло не так, и используется много оперативной памяти, которая не должна использоваться.

Одной из мер оценки размера является создание резервной копии без вложений и проверка её размера.

Возможно, мини-профайлер подскажет, какие действия с базой данных занимают слишком много времени.

Если у вас есть бюджет, чтобы удвоить объём оперативной памяти, сделайте это. (Если вы внимательно увеличите объём оперативной памяти, но оставите хранилище без изменений, при наличии такой возможности у вашего провайдера, то это может быть обратимым и даже временным изменением.)

Вы абсолютно правы.

Если вы не можете позволить себе увеличить объем оперативной памяти, попробуйте временно установить меньшие значения для db_shared_buffers (например, 128 МБ или меньше) и ограничить UNICORN_WORKERS значением 2, так как необходимо как можно скорее прекратить использование подкачки.

62,5 МБ

Дополнительная оперативная память у моего хостинг-провайдера довольно дорогая, поэтому сначала я изучу другие варианты. (К тому же я беспокоюсь, что изменение настроек может нарушить мои льготные тарифы…)

Я изменил db_shared_buffers на 128 МБ и UNICORN_WORKERS на 2.
Достаточно ли остановить и запустить приложение через launcher app stop / start, чтобы эти настройки вступили в силу?

Что такое мини-профайлер и как им пользоваться?

Нажав Alt+P на клавиатуре, вы увидите строку с данными о времени выполнения под баннером форума (у меня справа) после каждого действия на форуме. Если щёлкнуть по этой строке, откроется всплывающее окно со статистикой.

Это примерно столько же, сколько у меня при 1 ГБ оперативной памяти. У меня 2 тысячи тем, 15 тысяч сообщений и более 500 зарегистрированных пользователей.

Какова история вашего Discourse? Я смутно помню, что в прошлом для повышения производительности иногда требовалось создать индекс для какой-либо таблицы.

А как насчёт плагинов? Можно ли запустить действия в безопасном режиме, чтобы проверить, выполняются ли они быстрее?

Также может быть полезно вставить полное дерево процессов:

ps auxf

Я опубликовал своё здесь:
Ищу помощь с установкой Discourse

Есть ли простое место, где можно найти такую статистику?
Большинство статистических данных показывают мне, что произошло за последний день или неделю, но не общие итоги.

Не уверен, что вы имеете в виду под историей. Но я начал его в марте 2021 года.

Первое впечатление такое, что безопасный режим не быстрее. Я поэкспериментирую с ним и мини-профайлером, чтобы проверить, подтвердится ли это впечатление.

Прикреплён вывод команды ps auxf.
auxf.txt (20.1 КБ)

На странице /about есть колонка с данными за всё время.

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

Кажется, я заметил, что ваш сервер настроен на использование гипервизора, тогда как мой — на LXC. Не знаю, важно ли это. (В моей системе отображается процесс /usr/bin/lxcfs, которого нет у вас, а у вас есть процесс hv_vss_daemon, которого нет у меня.)

Также, возможно, вы могли бы предоставить вывод команд df -T и swapon.

1,3 тыс. тем, 24,7 тыс. сообщений, 631 регистрация, 7,1 тыс. лайков

Перезагрузка машин с Linux обычно ничего не даёт, но, полагаю, я могу попробовать.

Я согласен с вашим скептическим отношением к этому! Однако я не предлагаю это всуе — я вполне уверен, что нам встречался случай, когда долго работающая система действительно улучшалась после перезагрузки. (Редактирование: здесь, хотя это был другой случай.)

Вот что сообщил мини-профайлер о сохранении поста:

Это заняло ~30 секунд.