# Sidekiq lento + Postmaster che utilizza oltre il 95% di CPU (32 core) dopo l'aggiornamento della versione di PostgreSQL
**URL:** https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [27 Maggio 2020, 4:08pm UTC](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983 "2020-05-27T16:08:57Z")
**Posts on this page:** 4
**Page:** 2
### Author:  [@eboehnisch](https://meta.discourse.org/u/eboehnisch)
#### Post date: [28 Maggio 2020, 3:26pm UTC](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983/21 "2020-05-28T15:26:00Z")
Grazie a tutti! Ho corretto la chiave duplicata, eliminato gli indici obsoleti e poi eseguito con successo:
```plaintext
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
```
L’utilizzo della CPU è tornato alla normalità. Fiuu.
Domanda: perché un database non ottimizzato o un indice danneggiato causano un utilizzo della CPU così elevato da parte di `postmaster`? Sono solo curioso.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [29 Maggio 2020, 1:29am UTC](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983/22 "2020-05-29T01:29:36Z")
Penso che l’indice rotto sia un falso allarme; certamente non è ottimale e dovrebbe essere corretto.
Il problema principale è che questo passaggio da 10 a 12 lascia il database con statistiche inadeguate, il che porta a prestazioni scadenti.
Le prestazioni sono scarse perché l’ottimizzatore delle query sceglie piani di esecuzione molto inefficienti, poiché le statistiche che possiede sui dati nelle tabelle sono completamente errate.
Integreremo la ricostituzione delle statistiche tramite vacuum nel nostro processo automatizzato di migrazione.
---
### Author:  [@eboehnisch](https://meta.discourse.org/u/eboehnisch)
#### Post date: [29 Maggio 2020, 1:10pm UTC](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983/23 "2020-05-29T13:10:56Z")
Grazie, @sam, per le spiegazioni. Ha senso. Immagino che sia una buona idea integrare la ricostruzione nel processo di spostamento automatizzato. Ancora grazie per il tuo aiuto!
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [28 Giugno 2020, 1:12pm UTC](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983/24 "2020-06-28T13:12:39Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
[Previous page](https://meta.discourse.org/t/slow-sidekiq-postmaster-using-95-cpu-32-cores-after-postgresql-version-upgrade/152983.md?page=1)