Risorse VPS fuori controllo #16

New Issue

giuliof · 2022-04-27T20:31:44Z

giuliof commented

2022-04-27 20:31:44 +00:00

Si segnalano criticità sul VPS:

Occupazione del disco che cresce in maniera incontrollata e ritorna in condizioni normali con un riavvio;
Occupazione di ram eccessiva;

Soluzioni da sperimentare:

rotate dei log relativi ai container (al più, silenziamento completo dei log su file e, se si può fare, mantenimento solo dei log temporanei in journalctl)
Limitazione risorse per ciascun container

Si segnalano criticità sul VPS: - Occupazione del disco che cresce in maniera incontrollata e ritorna in condizioni normali con un riavvio; - Occupazione di ram eccessiva; Soluzioni da sperimentare: - [ ] rotate dei log relativi ai container (al più, silenziamento completo dei log su file e, se si può fare, mantenimento solo dei log temporanei in journalctl) - [ ] Limitazione risorse per ciascun container

giuliof added the

bug

label 2022-04-27 20:31:44 +00:00

lan-quil commented

2022-10-24 20:51:09 +00:00

Occupazione del disco che cresce in maniera incontrollata e ritorna in condizioni normali con un riavvio

Potrebbe essere colpa dell'esaurimento degli inode? Da verificare nel momento in cui si presenta il problema con un df -hi

(Related: #4 )

> Occupazione del disco che cresce in maniera incontrollata e ritorna in condizioni normali con un riavvio Potrebbe essere colpa dell'esaurimento degli inode? Da verificare nel momento in cui si presenta il problema con un `df -hi` (Related: https://git.golem.linux.it/golem/morgan/issues/4 )

giuliof commented

2022-10-24 21:15:43 +00:00

Ho provato al volo, per l'appunto in questo momento il disco è in condizioni semi-critiche con un'occupazione dell'86% quando, a cose normali, dovrebbe sotto il 50%.

Comunque, questo è il responso del comando sopra citato:

root@atena ~ # df -hi
Filesystem     Inodes IUsed IFree IUse% Mounted on
udev             480K   281  480K    1% /dev
tmpfs            482K   636  482K    1% /run
/dev/sda1        5.0M  468K  4.6M   10% /
tmpfs            482K     1  482K    1% /dev/shm
tmpfs            482K     3  482K    1% /run/lock
tmpfs            482K    17  482K    1% /sys/fs/cgroup
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/b543845c94a06f5e53207ecef91a05bf7a49ea6a5327f5fbc6e308b4b1378058/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/a9fd38be0ea490007e510988ad0c0762500b02cae309dc27a3617fb5bae66855/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/3187826f7dfc1ec2a255839fbcdb647d125f6c4b6fc4e8234855ac247a454810/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/d27cd2f03fc814de9e07ba53403655325851c7ccb23ea5a65ed6286ce1257407/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/0887cace8e848b191facb4995df57128380e279c67e5e4cfbb3a8205ccb711b1/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/c4cf2db3884d525d3864d025ea1dc82adff2b02d755d216c6747ab14fbe67a41/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/b59ce50ef4e6ae0edd6eaca2caa94e7c45822cc301dbc2bb035121a718f8a3ac/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/afd7ef8d30e5d6bf5fd73b5257fc05e4714a081739e41802279698f3f8203a5f/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/50b7954daa290697d6e7e48bc07072a8aeaa51bf31a1f24d9337765acf0afff8/merged
overlay          5.0M  468K  4.6M   10% /var/lib/docker/overlay2/3a30326fe57e284a5384b6e68352129ba4a4a647ad424244e72960c007cac688/merged
tmpfs            482K    11  482K    1% /run/user/0

Gli inode sembrerebbero essere sotto controllo.
Magari domani sera approfittiamo della condizione "sfavorevole" del disco per collegarci al server e dare un occhio insieme.

Ho provato al volo, per l'appunto in questo momento il disco è in condizioni semi-critiche con un'occupazione dell'86% quando, a cose normali, dovrebbe sotto il 50%. Comunque, questo è il responso del comando sopra citato: ```bash root@atena ~ # df -hi Filesystem Inodes IUsed IFree IUse% Mounted on udev 480K 281 480K 1% /dev tmpfs 482K 636 482K 1% /run /dev/sda1 5.0M 468K 4.6M 10% / tmpfs 482K 1 482K 1% /dev/shm tmpfs 482K 3 482K 1% /run/lock tmpfs 482K 17 482K 1% /sys/fs/cgroup overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/b543845c94a06f5e53207ecef91a05bf7a49ea6a5327f5fbc6e308b4b1378058/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/a9fd38be0ea490007e510988ad0c0762500b02cae309dc27a3617fb5bae66855/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/3187826f7dfc1ec2a255839fbcdb647d125f6c4b6fc4e8234855ac247a454810/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/d27cd2f03fc814de9e07ba53403655325851c7ccb23ea5a65ed6286ce1257407/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/0887cace8e848b191facb4995df57128380e279c67e5e4cfbb3a8205ccb711b1/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/c4cf2db3884d525d3864d025ea1dc82adff2b02d755d216c6747ab14fbe67a41/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/b59ce50ef4e6ae0edd6eaca2caa94e7c45822cc301dbc2bb035121a718f8a3ac/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/afd7ef8d30e5d6bf5fd73b5257fc05e4714a081739e41802279698f3f8203a5f/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/50b7954daa290697d6e7e48bc07072a8aeaa51bf31a1f24d9337765acf0afff8/merged overlay 5.0M 468K 4.6M 10% /var/lib/docker/overlay2/3a30326fe57e284a5384b6e68352129ba4a4a647ad424244e72960c007cac688/merged tmpfs 482K 11 482K 1% /run/user/0 ``` Gli inode sembrerebbero essere sotto controllo. Magari domani sera approfittiamo della condizione "sfavorevole" del disco per collegarci al server e dare un occhio insieme.

lan-quil commented

2022-10-25 19:35:35 +00:00

Gli inode sembrerebbero essere sotto controllo.

Sembrerebbe di sì...

Se non lo conoscete un altro strumento rapido per il monitoraggio è netdata (in debian è ad un apt install netdata di distanza), dà molte statistiche senza bisogno di alcuna configurazione.
Non è però consigliato usarlo in modo continuativo, è abbastanza pesante sulle risorse e a volte ha creato esso stesso problemi.
Ma è un buon modo per avere una rapida panoramica alla bisogna.

> Gli inode sembrerebbero essere sotto controllo. Sembrerebbe di sì... Se non lo conoscete un altro strumento rapido per il monitoraggio è [netdata](https://www.netdata.cloud/) (in debian è ad un `apt install netdata` di distanza), dà molte statistiche senza bisogno di alcuna configurazione. Non è però consigliato usarlo in modo continuativo, è abbastanza pesante sulle risorse e a volte ha creato esso stesso problemi. Ma è un buon modo per avere una rapida panoramica alla bisogna.

giuliof commented

2023-05-22 19:08:41 +00:00

Il problema sembrerebbe essere risolto grazie a @gbiotti, che con un ps si è accorto di uno script con un po' troppe istanze in esecuzione. @giomba ha provveduto ad aggiornare lo script e da quel momento il disco è rimasto stabile (~ 41%-42% di spazio occupato). Teniamo il VPS sott'occhio senza riavviarlo ogni lunedì, se nel giro di un mese non succedono altri scherzi chiuderei questa issue.

(Related: #4 )

In ogni caso, diverso tempo fa era stato installato uptime-kuma come prova sul server in officina (chi è in vpn ed ha le credenziali può accedere da http://cassone.golem.linux.it:7030), ed ha permesso di trovare un problema collaterale. Ogni tanto veniva segnalato il down del VPS, tentando di connettersi il sistema era molto lento e la RAM pressocé satura. Nel giro di qualche minuto tornava stabile, non appena il kernel si decideva a sacrificare qualche processo per farsi posto (quasi sempre il database di gitea).

Ora, magari questa era una delle manifestazioni dovute allo script scovato, però è anche vero che non navighiamo nella RAM. Per dire, allo stato attuale, con un uptime di poco più di un giorno, lo stato di occupazione della ram è il seguente:

root@atena ~ # free -m
              total        used        free      shared  buff/cache   available
Mem:           3853        1813         194         150        1845        1632
Swap:          1023          38         985

Un mese e mezzo fa, prima che venisse scovato e patchato lo script, mi sono permesso di aggiungere uno swapfile di 1GB, che ha messo fine a quei brevi down segnalati da uptime-kuma. Insieme al disco teniamo d'occhio anche i down di kuma e la RAM e speriamo che non escano fuori altri scherzi.

Il problema sembrerebbe essere risolto grazie a @gbiotti, che con un `ps` si è accorto di uno script con un po' troppe istanze in esecuzione. @giomba ha provveduto ad aggiornare lo script e da quel momento il disco è rimasto stabile (~ 41%-42% di spazio occupato). Teniamo il VPS sott'occhio senza riavviarlo ogni lunedì, se nel giro di un mese non succedono altri scherzi chiuderei questa issue. > (Related: https://git.golem.linux.it/golem/morgan/issues/4 ) In ogni caso, diverso tempo fa era stato installato uptime-kuma come prova sul server in officina (chi è in vpn ed ha le credenziali può accedere da http://cassone.golem.linux.it:7030), ed ha permesso di trovare un problema collaterale. Ogni tanto veniva segnalato il down del VPS, tentando di connettersi il sistema era molto lento e la RAM pressocé satura. Nel giro di qualche minuto tornava stabile, non appena il kernel si decideva a sacrificare qualche processo per farsi posto (quasi sempre il database di gitea). Ora, magari questa era una delle manifestazioni dovute allo script scovato, però è anche vero che non navighiamo nella RAM. Per dire, allo stato attuale, con un uptime di poco più di un giorno, lo stato di occupazione della ram è il seguente: ``` root@atena ~ # free -m total used free shared buff/cache available Mem: 3853 1813 194 150 1845 1632 Swap: 1023 38 985 ``` Un mese e mezzo fa, prima che venisse scovato e patchato lo script, mi sono permesso di aggiungere uno swapfile di 1GB, che ha messo fine a quei brevi down segnalati da uptime-kuma. Insieme al disco teniamo d'occhio anche i down di kuma e la RAM e speriamo che non escano fuori altri scherzi.

giuliof referenced this issue

2023-06-05 18:40:50 +00:00

Background jobs per nextcloud #21

Sign in to join this conversation.