Saturazione dell'HD dovuta alla creazione intempestiva di file postgresql

[Sophie]

Buongiorno,
Innanzitutto, i miei migliori auguri per il nuovo anno.

Da lunedì, dopo 15 giorni di ferie, il nostro server Wapt si è bloccato, saturando il disco rigido con i file PostgreSQL in /var/lib/postgresql/9.6/main/base/16385/
con file che raggiungono una dimensione di 1048576 Kb fino a saturare l'HD.

Di seguito la configurazione del nostro server virtuale:

• Versione Wapt 1.7.4.6165

• Sistema operativo Debian 4.9

• 4 GB di RAM

• Disco rigido da 40 GB

Abbiamo circa 1800 macchine nel nostro inventario.

All'avvio della console viene visualizzato il seguente messaggio di errore:
Impossibile ottenere l'elenco degli host: Errore sul server:
OperationalError('impossibile connettersi al server: Nessun file o directory di questo tipo\n\tls il server è in esecuzione localmente e accetta \n\tconnessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432."?\n',)

Di seguito il risultato di stato del servizio waptserver
waptserver.service - Script di avvio del server WAPT
Caricato: caricato (/usr/lib/systemd/system/waptserver.service; abilitato; preimpostazione del fornitore: abilitato)
Attivo: attivo (in esecuzione) da mar 2020-01-07 12:17:02 CET; 8 ore fa
PID principale: 664 (python)
Attività: 1 (limite: 4915)
CGroup: /system.slice/waptserver.service
└─664 /opt/wapt/bin/python /opt/wapt/waptserver/server.py

07 gen 20:40:36 srv-wapt15 python[664]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
07 gen 20:40:36 srv-wapt15 python[664]: OperationalError: impossibile connettersi al server: nessun file o directory di questo tipo
07 gen 20:40:36 srv-wapt15 python[664]: Il server è in esecuzione localmente e accetta
07 gen 20:40:36 srv-wapt15 python[664]: connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
07 gen 20:40:36 srv-wapt15 python[664]: , istanza: 07 gen
20:40:36 srv-wapt15 python[664]: 2020-01-07 20:40:36,449 CRITICO Errore pong SocketIO per uuid 4C4C4544-004B-3710-8059-B1C04F4D3632 e sid b270e
07 gen 20:40:36 srv-wapt15 python[664]: File "/opt/wapt/waptserver/server_socketio.py", riga 278, in on_wapt_pong
07 gen 20:40:36 srv-wapt15 python[664]: con wapt_db.atomic() come trans:
07 gen 20:40:36 srv-wapt15 python[664]: File "/opt/wapt/lib/python2.7/site-packages/peewee.py", riga 3533, in __enter__
07 gen 20:40:36 srv-wapt15 python[664]: return self._helper.__enter__()

Ripristinare questa VM a uno stato precedente non risolve il problema: dopo alcuni minuti il ​​fenomeno si ripresenta.

Avete qualche idea, per favore?
Grazie per il tuo feedback

[dcardon]

Ciao Sophie,

Innanzitutto, i miei migliori auguri per il nuovo anno.

Da lunedì, dopo 15 giorni di ferie, il nostro server Wapt si è bloccato, saturando il disco rigido con i file PostgreSQL in /var/lib/postgresql/9.6/main/base/16385/
con file che raggiungono una dimensione di 1048576 Kb fino a saturare l'HD.

Di seguito la configurazione del nostro server virtuale:

• Versione Wapt 1.7.4.6165

• Sistema operativo Debian 4.9

• 4 GB di RAM

• Disco rigido da 40 GB

Abbiamo circa 1800 macchine nel nostro inventario.

All'avvio della console viene visualizzato il seguente messaggio di errore:
Impossibile ottenere l'elenco degli host: Errore sul server:
OperationalError('impossibile connettersi al server: Nessun file o directory di questo tipo\n\tls il server è in esecuzione localmente e accetta \n\tconnessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432."?\n',)

Sembra che la dimensione degli inventari JSON (query WMI locali + dmidecode sulle macchine locali) sia aumentata significativamente e il database PostgreSQL non gestisce i VACUUM con sufficiente rapidità. Nei log vengono visualizzati messaggi come quelli riportati di seguito?

Codice: Seleziona tutto

ERROR: canceling autovacuum task CONTEXT: automatic vacuum of table "segmentation.pg_toast.pg_toast_237738400" LOG: checkpoints are occurring too frequently (8 seconds apart) HINT: Consider increasing the configuration parameter "max_wal_size

È possibile liberare un po' di spazio sulla macchina per consentire a PostgreSQL di riavviarsi (ma inizialmente non al servizio WAPT) e quindi eseguire un VACUUM FULL sul database Wapt per verificare che liberi spazio.

Codice: Seleziona tutto

df -h 
systemctl stop waptserver
rm quelques_fichiers_inutiles_pour_recupere_un_peu_despace
systemctl restart postgresql
sudo -u postgres psql wapt -c "VACUUM FULL"
df -h

Questo non risolve il problema, ma almeno conferma che è effettivamente quello il problema. Abbiamo un cliente con un problema simile e stiamo attualmente eseguendo il debug con lui. Probabilmente c'è un recente aggiornamento di Windows che ha modificato qualcosa nelle richieste WMI.

Sinceramente,

Denis

[dcardon]

Ciao di nuovo,

solo per tua informazione, per caso disponi di un pacchetto di audit che attiva regolarmente WAPT.register()?

Cordiali saluti,

Denis

[stephaneB]

Ciao,
grazie per la risposta (sono un collega di Sophie che ha avviato questa discussione).

Abbiamo effettivamente dei log di pgsql di questo tipo:
"I checkpoint si verificano troppo frequentemente
(ogni 25 secondi)
... Valuta la possibilità di aumentare il parametro 'max_wal_size'".

La funzione vacuum ha recuperato lo spazio e riavviato i servizi.

Sarebbe una buona idea pianificare un'attività cron di pgsql vacuum nel frattempo?

Per quanto riguarda un possibile pacchetto contenente una funzione wapt.register(), non credo, ma ci darò un'occhiata.

[dcardon]

Ciao StephaneB,

Ciao,
grazie per la risposta (sono un collega di Sophie che ha avviato questa discussione).

Abbiamo effettivamente dei log di pgsql come questo:
"I checkpoint si verificano troppo frequentemente
(ogni 25 secondi)
... Valuta la possibilità di aumentare il parametro 'max_wal_size'."

La funzione vacuum ci ha permesso di recuperare lo spazio e riavviare i servizi.

Sarebbe una buona idea pianificare un'attività cron di pgsql vacuum nel frattempo?

Per quanto riguarda un possibile pacchetto contenente una funzione wapt.register(), non credo, ma ci darò un'occhiata.

Il problema simile che abbiamo identificato è correlato a un numero eccessivo di aggiornamenti completi dell'inventario (circa 100-150 al secondo). Il database non ha abbastanza tempo per ripulire i suoi file principali (AUTOVACUUM) e l'unico modo per recuperare spazio è eseguire un FULL VACUUM, che blocca la tabella (e quindi blocca altre connessioni per darle il tempo di ripulire). Normalmente, il blocco esclusivo non dovrebbe durare più di pochi secondi, ma durante questo periodo non è possibile effettuare alcuna scrittura sulla tabella.

Mentre si aspetta di scoprire cosa sta generando inventari pieni non necessari, è possibile impostare un cron job con VACUUM FULL.

Sinceramente,

Denis

Nota: per essere più precisi, il problema VACUUM non si verifica per la tabella Hosts stessa, ma per la tabella TOAST corrispondente che memorizza i blob bjson e TEXT.

[dcardon]

Ok, nell'altro caso, il numero eccessivo di aggiornamenti dell'inventario è dovuto a un pacchetto con un file di controllo che ha un valore errato per il parametro `forced_install_on`. Hai utilizzato questo parametro nel tuo file di controllo?

[Sophie]

Ok, nell'altro caso, l'eccessivo numero di aggiornamenti dell'inventario è dovuto a un pacchetto con un file di controllo che ha un valore errato per il parametro forced_install_on. Hai usato questo parametro nel tuo file di controllo?

Buongiorno,
No, non utilizziamo mai questo parametro perché non sappiamo ancora esattamente a cosa serva.

[stephaneB]

Ciao, a quanto pare nessuno ha ancora utilizzato il parametro "forced_install_on" nei nostri file di controllo dei pacchetti. Con circa 200 pacchetti, controllarli uno per uno sarebbe un lavoro estenuante... Esiste un modo, una query, che ci permetta di trovarlo rapidamente? (Una ricerca con grep nella directory dei pacchetti non ha avuto alcun effetto, come previsto...).
Ho modificato i pacchetti più recenti (nell'ultimo mese) e non ho trovato alcun valore per questo parametro. (Alcuni pacchetti non lo menzionano; nella maggior parte dei casi, è indicato come privo di valore).

[dcardon]

Ciao stephaneB,

il problema non deriva necessariamente dal parametro in questione. Semplicemente, per qualche motivo, il motore di calcolo delle dipendenze locale non funziona correttamente e riavvia un inventario per verificare i parametri di filtro dei pacchetti. Il ciclo di `update-status` genera quindi il problema che stai riscontrando.

Dovresti individuare le macchine che causano il problema (cerca le macchine la cui data di "ultima connessione" è sempre negli ultimi minuti), quindi riavviare il servizio localmente in modalità debug, oppure, in alternativa, rimuovere tutti i pacchetti dalla macchina in questione e aggiungerli di nuovo uno alla volta per trovare quello che causa il problema. Una volta trovato il pacchetto, puoi pubblicare il file di controllo in questa discussione per capire qual è il problema.

Cordiali saluti,

Denis

[vcardon]

Salve, sembra che nessuno abbia ancora utilizzato il parametro "forced_install_on" nei nostri file di controllo dei pacchetti. Con circa 200 pacchetti, controllarli uno per uno sarà un lavoro noioso... Esiste un modo, una query, che ci permetta di trovarlo rapidamente? (Un grep nella directory del pacchetto non ha alcun effetto, come previsto...).
Ho modificato i pacchetti più recenti modificati nell'ultimo mese e non ho trovato un valore per questo parametro. (Alcuni pacchetti non lo menzionano e nella maggior parte è indicato come privo di valore).

Ciao stephaneB,

Possiamo offrirti un supporto telefonico più interattivo con un contratto di supporto. È molto conveniente e sembra che tu possa beneficiare dell'offerta MESR Software Grouping e della promozione valida fino alla fine del 2020. Contattaci tramite il nostro sito web https://www.tranquil.it/gerer-parc-info ... ri-supporto se questa opzione ti interessa.

Sinceramente.

Vincenzo