Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?
I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?
The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.
I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.
Существует (или существовало) несколько тем, посвященных настройке. Большинство успешных из них, на мой взгляд (за исключением этой), содержат подробную информацию о доступных ресурсах, параметре db_shared_buffers и других настройках, а также о возникающих проблемах, возможно, с выводами утилит htop или других инструментов. Каков размер вашей базы данных? С какой проблемой вы столкнулись? (Возможно, вам стоит создать новую тему).
Спасибо! Пока проблем нет. Просто заметил высокое потребление памяти, хотя форум не слишком активный. Я просто привык мыслить на опережение и проверять, какие ресурсы используются интенсивнее всего. Это всего лишь VPS с 3 ГБ ОЗУ и 6 ядрами @ 3,5 ГГц. Не медленно, а очень быстро, но видно, что потребление памяти может стать проблемой в будущем, и мне интересно, что можно оптимизировать.
Почитаю ещё немного о приложениях на Ruby on Rails в целом и об оптимизации. Спасибо ещё раз.
В зависимости от того, что именно вы подразумеваете под «потреблением», это может быть нормально. Но при 3 ГБ, вероятно, нет смысла настраивать параметры, так как, если вы запускали ./discourse-setup, его предположения, скорее всего, вполне достаточны.
total used free shared buff/cache available
Mem: 2.9Gi 1.8Gi 167Mi 100Mi 1.0Gi 895Mi
Swap: 1.0Gi 587Mi 436Mi
Доступно примерно 900 МБ. Пока это не проблема. Но проблема привела меня сюда. Хотелось бы узнать, что делать, если/когда доступная память станет проблемой в будущем. Конечно, кроме добавления ещё памяти.
На этом уровне единственное реальное решение — добавить больше оперативной памяти. Если у вас 8 или 16 ГБ, есть несколько вариантов действий. Возможно, стоит увеличить файл подкачки ещё на 1 ГБ, но, скорее всего, проблем не возникнет.
Если вы запускали ./discourse-setup, он создал файл подкачки размером 2 ГБ. При пересборке могут возникнуть проблемы.
Хорошо, мне удалось почти вдвое увеличить доступное использование памяти, изменив значение по умолчанию при установке с: UNICORN_WORKERS: 8
на UNICORN_WORKERS: 4
Затем выполнил: sudo ./launcher rebuild app
Сейчас настраиваю мониторинг PostgreSQL, чтобы понять, что там происходит.
Всегда наступает момент, когда какой-либо ресурс становится узким местом. Но ваш сервер, на мой взгляд, сейчас явно избыточно мощен.
Вы будете использовать больше памяти, когда у вас будет больше процессов Unicorn.
Вам понадобится больше процессов Unicorn, когда на вашем сайте увеличится трафик.
Я вижу, что все процессы Unicorn используют 0,0% ЦП, и, похоже, только worker[0] действительно что-то делает.
Вы уменьшили потребление памяти, запустив меньше процессов Unicorn. Это хорошо, потому что вы, похоже, всё равно их не использовали. Но «доступная память» — на самом деле плохой показатель. Вы оптимизируете не ту переменную.
Неиспользуемая память ничего вам не даёт. Это значит, что вы платите за то, что всё равно не используете. Если у вас постоянно доступно 2 ГБ памяти*, вы можете уменьшить размер сервера и сэкономить деньги.
*) Пересборка Discourse потребует больше памяти, поэтому нужно проверять, сколько памяти доступно во время пересборки. На практике не опускайтесь ниже 2 ГБ общей памяти и/или убедитесь, что у вас достаточно своп-памяти, как уже заметил Pfaffman.
Неверно. «Свободная» память, которая ничего не делает, — это плохо. А «доступная» память — это память, используемая системой, которую можно легко освободить, и это хорошо.
Или официально:
Доступная память: Оценка того, сколько памяти доступно для запуска новых приложений без использования подкачки.
Источник: man free
Как видно на скриншоте ниже, свободная память практически не изменилась. Таким образом, почти вся память системы занята. Однако система теперь будет реже прибегать к подкачке, поскольку имеется больше доступной памяти, которую можно освободить при необходимости.
Полагаю, под «плохо» здесь имеется в виду, что это стоит денег, но ничего не даёт. Это довольно распространённый взгляд, потому что, когда нужны дополнительные ресурсы, всё становится дороже — а оперативная память — дорогая составляющая в этом уравнении.
А если у вас не так много денег, чтобы тратить их впустую, это просто глупо переплачивать (финская поговорка, без обид ).
).