Sebbene in generale le cose siano andate bene, ho riscontrato problemi successivi con i processi Postgres che impazzivano utilizzando il 100% di un core. Tuttavia, numeri variabili di processi. Ho provato alcune cose, da una ricostruzione a riavvii. Attualmente sto provando un rake db:validate_indexes che è già in esecuzione da alcune ore senza alcun feedback. Non sono sicuro se l’avessi già fatto prima e se dovrebbe avvenire più rapidamente.
L’utilizzo del forum funziona bene fondamentalmente, ma è decisamente rallentato. Alcuni processi più lunghi, come il caricamento dei profili utente di utenti più attivi, richiedono notevolmente più tempo del solito.
Sono abbastanza sicuro che ci siano alcuni problemi con il database, ma ho difficoltà a capire quali.
Devo dire che il nostro database è piuttosto grande: siamo a circa 150 GB dopo il ripristino e dopo la creazione degli indici. Dal monitoraggio del processo di ripristino non ho visto errori e la creazione degli indici è andata bene ai miei occhi.
Qualche idea su come affrontare questo problema? Al momento ci sono 3 processi postgres; erano 6 prima di un riavvio che ho effettuato qualche ora fa; ho anche visto tutti i 16 core utilizzati dopo il ripristino.
MODIFICA: Ho appena notato in questo momento che 3 processi sidekiq sono occupati con “indicizzazione delle categorie per la ricerca”. Potrebbe essere tutto solo la ricostruzione dell’indice di ricerca? Se è così, si può risolvere in altro modo? Quando faremo il ripristino del sistema live, questo sarà un grosso problema se degrada le prestazioni in questo modo per più ore o addirittura giorni.
Al momento è in esecuzione solo un task sidekiq con “Jobs::BackfillBadge”, ma ci sono ancora 7 processi postgres che sembrano bloccare il 100% della CPU costantemente. Sono davvero curioso di sapere cosa sta succedendo lì.
Non sono sicuro se stia facendo qualcosa, ma è lì da più di 30 minuti.
Ho messo il forum in sola lettura e riavviato la VM per terminare i 7 processi Postgres che erano “bloccati” lì prima. Subito dopo il riavvio, 2 di questi processi postgres sono tornati e non sono cambiati. Al momento non c’è nulla in esecuzione in sidekiq.
Non vuoi davvero eseguire un VACUUM completo. Tutto ciò di cui hai bisogno per recuperare le prestazioni è un VACUUM VERBOSE ANALYZE. Non puoi eseguire un FULL in un sito in esecuzione.
Aha! Consigli sensati da un esperto! Quindi forse avevo ragione sul fatto che 8 GB/25% non sono sufficienti, e anche se 16 GB sono più del 40%, potrebbe comunque essere un buon suggerimento perché…
Ragazzi. come detto questo è un server di test - non c’è traffico su di esso. Questo server non è assolutamente abbastanza buono per l’uso in produzione, ma non è questo il problema qui. La domanda è perché vediamo processi postgres bloccati in quel modo (con il 100% di utilizzo della CPU) e che rallentano drasticamente le cose. Stvamo eseguendo il testserver con una capacità inferiore anche fino a pochi giorni fa - è stato aumentato solo a causa della mancanza di spazio su disco per un ripristino.
La macchina di produzione è in esecuzione con 128 GB di RAM con le stesse impostazioni di Shared buffer senza alcun problema - quindi non penso che ci sia un problema generale con queste impostazioni e la dimensione dei buffer condivisi - specialmente non una macchina di test privata senza traffico.
Ma comunque - rifarò il ripristino e vedrò se qualcosa potrebbe essere andato storto dato che apparentemente non c’è una buona spiegazione per il comportamento.
Postgres