# Problema muito lento no Sidekiq com fila grande devido a enorme quantidade de notificações de usuário não lidas
**URL:** https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716
**Category:** Self-hosting
**Created:** [5 Fevereiro , 2020 12:07 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716 "2020-02-05T12:07:57Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 05:29 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/21 "2020-02-12T05:29:58Z")
Obrigado, @Falco
Estou principalmente perplexo quanto a como o desempenho pode oscilar entre concluir ~11 milhões e ~300 mil jobs em um dia, dentro de ~1 semana, com a mesma configuração. Uma diferença de velocidade de ~35x em termos de jobs por segundo.
Quanto ao uso da CPU, ele voltou a ~15-20%, que é o habitual. Processando jobs na mesma velocidade (lenta).
Apenas para esclarecer/confirmar, eu quis dizer atribuir (não adicionar) alguns sidekiqs exclusivamente para processar a fila de baixa prioridade, já que parecia que as tarefas de baixa prioridade podiam ser processadas a uma taxa muito mais rápida e possivelmente não sofrem os mesmos gargalos. Eu especulava que isso poderia explicar como os jobs por segundo podem variar tão drasticamente (ou seja, tarefas ‘fáceis’ de baixa prioridade presas atrás do backlog da fila padrão).
Para esclarecer: você acha que o desempenho do PostgreSQL está causando a conclusão lenta dos jobs ou apenas o evento de alto uso de CPU que notei ontem (que agora voltou ao normal)?
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [12 Fevereiro , 2020 07:15 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/22 "2020-02-12T07:15:02Z")
Isso tudo é em SSD, certo?
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 07:19 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/23 "2020-02-12T07:19:47Z")
Sim, correto @Stephen - RAID 1 de SSDs NVMe.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 07:31 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/24 "2020-02-12T07:31:52Z")
Atualização: Tentei excluir a fila de baixa prioridade e a fila padrão algumas vezes, sem impacto na velocidade, pois a fila padrão volta a crescer imediatamente. Em seguida, tentei excluir a fila padrão e ativar o modo somente leitura. Isso fez com que o número de tarefas por segundo disparasse dramaticamente, esvaziando a fila de baixa prioridade a uma velocidade cerca de 100 vezes maior.
Edição: Parece que, mesmo com apenas uma fila de baixa prioridade grande, a velocidade de processamento ainda é lenta. Se eu definir o Discourse como somente leitura e depois esvaziar tanto a fila de baixa prioridade quanto a fila padrão, o processamento subsequente de tarefas parece permanecer super rápido, esvaziando as tarefas agendadas e as filas até que eu desative o modo somente leitura. :yuno:
---
### Author:  [@bartv](https://meta.discourse.org/u/bartv)
#### Post date: [12 Fevereiro , 2020 07:43 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/25 "2020-02-12T07:43:20Z")
Meu próximo passo seria descobrir exatamente qual processo está causando o problema, acessando o aplicativo Discourse e executando o htop ou top para verificar os maiores usos de CPU.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12 Fevereiro , 2020 11:15 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/26 "2020-02-12T11:15:29Z")
Parece que o PostgreSQL é o gargalo. Você pode configurar o Prometheus para monitorar seu desempenho e verificar se ele tem acesso suficiente à memória RAM.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 12:06 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/27 "2020-02-12T12:06:16Z")
Obrigado pela sua contribuição, @pfaffman 🙂 Acredito que `db_shared_buffers` e `db_work_mem` no app.yml sejam os únicos controles para o acesso à RAM do PostgreSQL, certo?
Fiz alguns ajustes, tanto para cima quanto para baixo. As configurações atuais no app.yml são:
db\_shared\_buffers: “32768MB”
db\_work\_mem: “128MB”
Com uma memória RAM total do sistema de 128 GB.
Também tentei alterar `max_connections` em `/var/discourse/shared/standalone/postgres_data/postgresql.conf` e depois reconstruir o Discourse. Testei valores acima do padrão (100), de 200 a 500. Atualmente está configurado para 300. Não tenho certeza se modificá-lo ali realmente altera o valor máximo de conexões.
Vejo estas configurações em /var/discourse/templates/postgres.template.yml:
db\_synchronous\_commit: “off”
db\_shared\_buffers: “256MB”
db\_work\_mem: “10MB”
db\_default\_text\_search\_config: “pg\_catalog.english”
db\_name: discourse
db\_user: discourse
db\_wal\_level: minimal
db\_max\_wal\_senders: 0
db\_checkpoint\_segments: 6
db\_logging\_collector: off
db\_log\_min\_duration\_statement: 100
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 12:21 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/28 "2020-02-12T12:21:08Z")
> [@bartv](#):
>
> Descobrindo exatamente qual processo está causando o problema, entrando no aplicativo Discourse e executando
Obrigado @bartv, seguindo sua sugestão, tenho monitorado de dentro do aplicativo Discourse via top. Estou vendo muitos processos postmaster executados pelo usuário postgres — a quantidade de uso de CPU varia. As capturas de tela representam períodos prolongados com estatísticas de uso semelhantes.
Usando ~95% dos 32 núcleos:
Usando ~20%, menor uso de CPU do postmaster.
Usando ~6% de CPU, enquanto o modo somente leitura estava ativo.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12 Fevereiro , 2020 14:12 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/29 "2020-02-12T14:12:59Z")
Qual o tamanho do seu banco de dados? Quantos usuários você tem? Quantas novas postagens por dia?
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [12 Fevereiro , 2020 14:52 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/30 "2020-02-12T14:52:57Z")
A primeira coisa que você deve fazer é executar `VACUUM ANALYZE;` no console do PostgreSQL.
Isso pode demorar um pouco para ser executado; talvez seja interessante parar o Sidekiq temporariamente para reduzir a carga enquanto ele trabalha.
Se isso não ajudar, devemos habilitar o `pg_stat_statements` e, em seguida, verificar quais consultas estão consumindo uma quantidade enorme de CPU.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [12 Fevereiro , 2020 15:04 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/31 "2020-02-12T15:04:19Z")
@pfaffman
- A pasta /var/discourse/shared/standalone/postgres\_data tem 170 GB
- 61,7 mil usuários ativos nos últimos 30 dias (não tenho certeza sobre o total absoluto)
- ~50 mil a 80 mil novas postagens por dia
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12 Fevereiro , 2020 15:28 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/32 "2020-02-12T15:28:52Z")
Oh. Isso não é trivial.
Você deve se informar sobre o ajuste do PostgreSQL. Esse nível de desempenho está um pouco além do auto-hospedagem típica vista aqui.
Eu tentaria reservar cerca de 3/4 da RAM para o PostgreSQL. Com certeza eu separaria em containers de dados e web distintos. Mas você pode precisar de uma configuração mais complexa do PostgreSQL para obter o desempenho necessário.
EDIT: Mas eu não tenho experiência com bancos de dados muito maiores, então veja abaixo! 😉
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [12 Fevereiro , 2020 19:36 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/33 "2020-02-12T19:36:14Z")
Lidamos com bancos de dados muito maiores usando muito menos RAM e com um uso de CPU significativamente menor.
As informações do pg\_stat\_statements provavelmente serão capazes de nos dizer o que está errado.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [16 Fevereiro , 2020 14:51 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/34 "2020-02-16T14:51:59Z")
Muito obrigado pela ajuda, pessoal.
Então, tentei executar `VACUUM ANALYZE;` — infelizmente, não funcionou. Os comandos usados estão abaixo, para referência:
> cd /var/discourse/
> ./launcher enter app
> sudo -u postgres psql
> \c discourse
> VACUUM ANALYZE;
Tentei habilitar o pg\_stat\_statements. Os passos realizados estão abaixo:
Adicionei/modifiquei as linhas abaixo neste arquivo: /var/discourse/shared/standalone/postgres\_data/postgresql.conf
> shared\_preload\_libraries = ‘pg\_stat\_statements’ # (alteração requer reinício)
> pg\_stat\_statements.max = 10000
> pg\_stat\_statements.track = all
> pg\_stat\_statements.track\_utility = on
> pg\_stat\_statements.save = off
Em seguida, recompilei o Discourse e executei:
> ./launcher enter app
> sudo -u postgres psql
> \c discourse
> CREATE EXTENSION pg\_stat\_statements;
Tentei executar consultas, mas recebi o seguinte erro:
> ERROR: pg\_stat\_statements deve ser carregado via shared\_preload\_libraries
Minha suposição é que minhas edições no arquivo postgresql.conf (/var/discourse/shared/standalone/postgres\_data/postgresql.conf) não estão funcionando (recompilei o Discourse após editar). É possível fazer essas edições através do arquivo app.yml? Ou você vê algo que eu tenha feito de errado?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [16 Fevereiro , 2020 16:45 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/35 "2020-02-16T16:45:54Z")
> [@markersocial](#):
>
> (/var/discourse/shared/standalone/postgres\_data/postgresql.conf) não estão funcionando (reconstruí o Discourse após editar).
Reconstruir o Discourse apagará essas alterações. Reiniciar o container provavelmente resolverá o problema. (algo como `sv restart postgres` dentro do container também pode funcionar).
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [17 Fevereiro , 2020 06:47 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/36 "2020-02-17T06:47:31Z")
> [@pfaffman](#):
>
> sv restart postgres
Obrigado, tentei reiniciar o container:
> ./launcher stop app
> ./launcher start app
Ainda recebo o mesmo erro ao tentar consultar:
> ERRO: pg\_stat\_statements deve ser carregado via shared\_preload\_libraries
As alterações que fiz anteriormente ainda persistem no arquivo aqui, mesmo após uma reconstrução:
> /var/discourse/shared/standalone/postgres\_data/postgresql.conf
Suspeito que este não seja o local onde devo fazer essas edições 🧐
Talvez seja porque estou usando apenas app.yml (e mail-receiver.yml) na pasta de containers e não implementei o uso de data.yml.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [17 Fevereiro , 2020 12:38 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/37 "2020-02-17T12:38:12Z")
> [@markersocial](#):
>
> Estou suspeitando que este arquivo não é o local onde deveria fazer essas edições
Sem olhar de fato, é provável que seja /etc/postgres dentro do container. Você também pode precisar instalar a biblioteca que ele está exigindo.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [19 Fevereiro , 2020 09:52 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/38 "2020-02-19T09:52:27Z")
Obrigado, isso ajudou muito, no início. 🤸♂️. O problema parecia resolvido e a fila de jobs estava rodando muito rápido apenas aumentando as conexões máximas no postgresql.conf. Infelizmente, desacelerou novamente após cerca de um dia.
Abaixo estão os passos, caso sejam úteis para outras pessoas que queiram aumentar o max\_connections do PostgreSQL.
> docker ps
Obtenha o ID do contêiner, por exemplo, aaabbbccc123, e substitua nos comandos abaixo:
Copie o arquivo postgresql.conf de dentro do contêiner Docker para o sistema de arquivos local:
> docker cp aaabbbccc123:/etc/postgresql/10/main/postgresql.conf /srv
Edite a configuração:
> nano /srv/postgresql.conf
Copie-o de volta para o contêiner Docker:
> docker cp /srv/postgresql.conf aaabbbccc123:/etc/postgresql/10/main/postgresql.conf
> cd /var/discourse
> ./launcher stop app
> ./launcher start app
Exclua o arquivo residual (opcional):
> rm /srv/postgresql.conf
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [19 Fevereiro , 2020 10:12 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/39 "2020-02-19T10:12:17Z")
@supermathie Acredito que tenha ativado o pg\_stat\_statements com sucesso 😀
Tentei usar esta consulta:
> SELECT
> (total\_time / 1000 / 60) as total,
> (total\_time/calls) as avg,
> query
> FROM pg\_stat\_statements
> ORDER BY 1 DESC
> LIMIT 100;
Baseado neste guia: [The most useful Postgres extension: pg\_stat\_statements - Citus Data](https://www.citusdata.com/blog/2019/02/08/the-most-useful-postgres-extension-pg-stat-statements/)
No entanto, não consigo interpretar o resultado, acho que cometi algum erro.
total | avg | query
1671.1110420745 | 374.736186677194 | SELECT COUNT(\*) FROM ( +
| | SELECT $1 FROM +
| | notifications n +
| | LEFT JOIN topics t ON t.id = n.topic\_id +
| | WHERE t.deleted\_at IS NULL AND +
| | n.notification\_type \<\> $2 AND +
,| | n.user\_id = $3 AND +
| | n.id \> $4 AND
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [19 Fevereiro , 2020 13:39 UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/40 "2020-02-19T13:39:19Z")
Agora que você sabe o que deseja fazer, pode aplicar essas alterações usando um bloco `replace` no seu app.yml.
Além disso, você pode simplesmente executar `./launcher enter app` e editar os arquivos diretamente. Observe, no entanto, que ao reconstruir, essas alterações não estarão presentes no novo contêiner.
[Previous page](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716.md?page=1)
[Next page](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716.md?page=3)