Ограничение количества единорогов, использования памяти и подкачки

Поддержка Самостоятельное хостинг
1

Я запускаю небольшой сервер (1 ГБ ОЗУ) и небольшой сайт (официальная установка Discourse работает уже почти 8 лет). Обмен страницами на диск происходит чаще, чем мне хотелось бы, поэтому я начал изучать использование памяти.

Я заметил, что некоторое время назад установил количество процессов Unicorn только на 2, чтобы ограничить использование памяти (и уменьшить обмен страницами). Я использую версию Discourse 3.1.0.

image
image897×401 12.4 KB

Однако при запуске htop я вижу 20 запущенных процессов Unicorn (10 для worker 0 и 10 для worker 1).

image
image1236×671 70.2 KB

Что я упускаю? Почему у меня запущено 20 процессов Unicorn, хотя в app.yml указано 2?

Также есть ли другие способы уменьшить использование памяти (например, если я уменьшу db_shared_buffers до 128 МБ, будут ли какие-либо побочные эффекты)? Могу ли я уменьшить использование памяти Sidekiq?

Это вывод команды vmstat 5 5
image

Вывод команды free -h
image

2

Я подозреваю, что htop показывает потоки, а не процессы. В любом случае, в htop я вижу то же самое, что и вы, но согласно команде

ps uaxf|egrep unicorn.?worker

у меня всего два юникорна.

Также у меня free показывает то же, что и у вас:

# free -h
              total        used        free      shared  buff/cache   available
Mem:           985M        782M         61M         60M        141M         32M
Swap:          2.0G        992M        1.0G

Кстати, само по себе использование части swap-памяти не является проблемой. Важно именно активное свопирование (страничная подкачка). Попробуйте выполнить vmstat 5 5 и посмотрите на столбцы si и so.

# 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
 0  0 1041832  63176   5716 127408  367  325   601   393    8   10  2  1 95  2  0
 0  0 1041576  60976   5724 127408  399    0   399    21  212  653  1  1 96  2  0
 0  0 1043544  77036   2296 120688  807  803   807   837  404 1144  1  2 94  3  0
 0  0 1043288  65040   3704 129476  254    0  2292     5  255  780  1  1 96  2  0
 0  0 1048736  81936   2916 119016  762 1499   919  1565  470 1171  3  2 90  5  0

Я бы предпочел не видеть значений выше 1000, но я не слишком беспокоюсь. Второй запуск показал гораздо более спокойную картину:

# 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
 0  0 1048452  82712   2532 120848  367  325   601   393    8   10  2  1 95  2  0
 0  0 1047684  74552   2548 124816  285    0  1049    10  230  655  2  1 95  2  0
 0  0 1046660  66556   3692 129008  196    0  1261    16  219  672  1  1 96  2  0
 1  0 1046404  65812   3700 129284   54    0    97    13  137  364  1  0 98  0  0
 0  0 1046148  65280   3700 129288   50    0    50     3  132  344  1  0 98  0  0

Редактирование: в htop клавиша H переключает отображение с потоков на процессы:

  CPU[                                                       0.0%]   Tasks: 66; 1 running
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||824M/985M]   Load average: 0.19 0.12 0.05 
  Swp[||||||||||||||||||||||||||||||                  1015M/2.00G]   Uptime: 52 days, 00:50:42

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
13246 1000       20   0  966M  362M  6448 S  0.0 36.8 51:01.52 unicorn worker[0] -E production -c config/unicorn.conf.rb
13237 1000       25   5 1004M  194M  3780 S  0.0 19.8 22:38.19 sidekiq 6.5.9 discourse [0 of 5 busy]
13258 1000       20   0  919M 70176  3632 S  0.0  7.0  5:02.87 unicorn worker[1] -E production -c config/unicorn.conf.rb
12412 systemd-r  20   0  212M 60928 56916 S  0.0  6.0  0:00.23 postgres: 13/main: discourse discourse [local] idle
12818 systemd-r  20   0  212M 39228 34868 S  0.0  3.9  0:00.07 postgres: 13/main: discourse discourse [local] idle
12719 systemd-r  20   0  211M 28400 25336 S  0.0  2.8  0:00.03 postgres: 13/main: discourse discourse [local] idle
13117 1000       20   0  541M 13768  2048 S  0.0  1.4  1:08.11 unicorn master -E production -c config/unicorn.conf.rb

Редактирование: я установил db_shared_buffers: "128MB" очень рано и не сталкивался с какими-либо проблемами из-за этого.

3

Спасибо, очень полезно. Какой недостаток у перехода на одного воркера Unicorn? Улучшит ли это время отклика или ухудшит (ограничен ли один воркер Unicorn одним входящим соединением, то есть ускорят ли 2 воркера обработку одного входящего соединения?), учитывая, что у меня всего несколько соединений в минуту?

Когда я просматриваю веб-сайт, vmstat 5 5 выглядит так. Есть ли какие-либо предложения по уменьшению свопинга (я установил swappiness в 10)?

image
image824×136 6.21 KB

РЕДАКТИРОВАНИЕ: Есть ли способ уменьшить использование памяти Sidekiq без ущерба для производительности?

4

Действительно, ваш сайт мог бы работать быстрее, если бы у вас было больше оперативной памяти. Но если время отклика не является проблемой, то и проблем нет. Просто оцените соотношение ваших личных затрат и выгод.

Вам может быть интересно прочитать Мнение MKJ о конфигурации развёртывания Discourse. Там описаны несколько системных настроек ядра, которые могут быть полезны. Не знаю, повлияют ли они на производительность.

Не уверен, но, кажется, каждый процесс unicorn может обрабатывать один запрос. Значит, если у вас всего один unicorn и достаточно трафика, чтобы второй запрос поступил до завершения первого, этот второй запрос придётся ждать. Судя по выводу htop, один unicorn потратил в 10 раз больше процессорного времени, чем другой. Это, на мой взгляд, означает, что мой форум на 90% времени нуждается только в одном unicorn, а второй полезен лишь 10% времени. Я не чувствую необходимости добавлять третий процесс, и для участников моего форума переход к одному процессу, возможно, не стал бы большой проблемой. Но я не вижу причин для этого: процесс может занимать память, но если он бездействует, он будет выгружен в swap. Это не проблема: пусть система виртуальной памяти сама этим занимается.

Редактирование: Я никогда не настраивал параметр swappiness. По-видимому, он установлен на 60. Более агрессивное использование swap может быть полезным, если это освободит больше памяти для буферов ввода-вывода. Не знаю.

5

Если я изменю db_shared_buffers и UNICORN_WORKERS, можно ли просто перезапустить, не выполняя пересборку через ./launcher rebuild app?