Estou executando um pequeno servidor (1G RAM) e também um pequeno site (instalação oficial do Discourse rodando há quase 8 anos). Há mais swapping de disco do que eu gostaria, então comecei a analisar o uso de memória.
Notei que defini o número de unicórnios para apenas 2 há um tempo para limitar o uso de memória (e reduzir o swapping). Executando a versão do Discourse 3.1.0
O que estou perdendo aqui? Por que tenho 20 unicórnios rodando enquanto o app.yml indica 2?
Além disso, existem outras maneiras de reduzir o uso de memória (por exemplo, se eu reduzir o db_shared_buffers para 128MB, haverá algum efeito colateral?) Posso reduzir o uso de memória do sidekiq?
Suspeito que o htop esteja mostrando threads em vez de processos - de qualquer forma, vejo o mesmo no htop que você, mas apenas dois unicorns de acordo com
ps uaxf|egrep unicorn.?worker
Também meu free está como o seu:
# free -h
total used free shared buff/cache available
Mem: 985M 782M 61M 60M 141M 32M
Swap: 2.0G 992M 1.0G
Aliás, ver um pouco de swap em uso não é um problema em si. É o swapping (paginação) real que importaria. Tente vmstat 5 5 e olhe as colunas si e 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
Preferiria não ver nada acima de 1000, mas não estou muito preocupado. Uma segunda execução mostrou um quadro muito mais calmo:
# 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
Editar: a tecla H no htop alternará de threads para processos:
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
Editar: defini db_shared_buffers: \"128MB\" muito cedo e não vi nenhum problema com isso.
Obrigado, muito útil. Qual é a desvantagem de mudar para apenas um worker unicorn? Isso melhoraria o tempo de resposta ou o pioraria (um worker unicorn é limitado a uma conexão de entrada, ou seja, 2 workers tornariam uma única conexão de entrada mais rápida de processar?), assumindo que tenho apenas algumas conexões por minuto?
Quando estou navegando no site, é assim que vmstat 5 5 se parece, alguma sugestão sobre como reduzir o swapping (eu defini a swappiness para 10)?
Certamente parece que seu site seria mais rápido se você tivesse mais RAM. Mas se o tempo de resposta não for um problema, não há problema. Basta olhar para sua equação pessoal de custo/benefício.
Não sei, mas acho que cada unicórnio pode lidar com uma solicitação. Portanto, se você tiver apenas um unicórnio e tráfego suficiente para uma segunda solicitação chegar antes que a primeira seja concluída, essa segunda solicitação terá que esperar. Você pode ver pela minha saída do htop que um unicórnio executou 10 vezes mais tempo de CPU do que o outro. Eu interpretaria isso como meu fórum precisando de apenas um unicórnio 90% do tempo, e os outros 10% do tempo esse segundo unicórnio é útil. Não sinto necessidade de adicionar um terceiro, e pode não ser um grande problema para os membros do meu fórum se eu reduzir para um. Mas não vejo razão para isso: pode usar memória, mas se estiver ocioso, será trocado. Sem grandes problemas: deixe o sistema de memória virtual lidar com isso.
Editar: Eu nunca ajustei o swappiness. Parece estar em 60. Uma troca mais agressiva pode ser útil se liberar mais RAM para buffers de I/O. Não sei.
