Re: Server che non rilascia la ram
> > Io riporterei il valore di swappiness a quello di default (60 se non > > ricordo male). > > > > Leggi qui https://www.linuxatemyram.com/ > > Ok, ci ripenserò sulla swap: avevo seguito un consiglio legato a mariadb. > In ogni caso il problema esisteva anche prima di portare la swappiness a 0 Se vuoi approfondire oggi ho trovato questo articolo, molto interessante. È in inglese, il contenuto vale bene lo sforzo per tradurla. https://chrisdown.name/2018/01/02/in-defence-of-swap.html Ciao -- Felipe Salvador
[Risolto-male] (was: [Stabile] Problema installazione su HP 255 G6 (Era: Re: Portatile a basso costo per debian))
Ciao a tutti, ho provato in molte combinazioni, stabile, testing, unstable, mettendo i relativi firmware e con le righe di grub radeon.modeset=0 e altro ma non sono mai riuscito a far partire debian sul portatile in questione. Mi sono arreso (quasi) e ho provato manjaro che funziona alla prima. Ora il proprietario è lì che gioca come un forsennato e quindi di modificarla non se ne parla però vorrei continuare a fare qualche prova così da cercare di capire cosa stavo sbagliando o quel che è: dite che si può provare a fare un'installazione su una chiavetta usb? -- Ciao leandro http://6xukrlqedfabdjrb.onion/blog/ Alla bellezza preferisco la verità. E il dubbio è l'unità di misura. signature.asc Description: PGP signature
Re: Server che non rilascia la ram
On Sun, Mar 11, 2018 at 12:41:46PM +, Alessandro Pellizzari wrote: > On 11/03/18 12:10, Michele Orsenigo wrote: > > > I servizi che rallentano, fino a bloccarsi sono fondamentalmente mariadb e > > dovecot. > > Magari l'hai già fatto, ma prova a controllare la configurazione delle > cache di MariaDB. La config suggerita da loro (20% della RAM con MyISAM > e 70% con InnoDB) presuppone 4GB di RAM, ma consigliano di abbassarla su > sistemi con meno RAM. > > Nel tuo caso fai girare anche altra roba sullo stesso computer, quindi > mi terrei ancora più basso, altrimenti rischi di "rubare" cache ad altri > servizi, rendendoli molto lenti. > > Vedi qui: https://mariadb.com/kb/en/library/mariadb-memory-allocation/ > > Bye. Ottimo, attuerei, se non lo hai già fatto, un tuning anche su httpd. Qui[¹] trovi un esempio su una situazione simile alla tua, 1.6Gb di RAM. [¹] https://unix.stackexchange.com/questions/187112/httpd-memory-usage -- Felipe Salvador
Re: Server che non rilascia la ram
On 11/03/18 12:10, Michele Orsenigo wrote: > I servizi che rallentano, fino a bloccarsi sono fondamentalmente mariadb e > dovecot. Magari l'hai già fatto, ma prova a controllare la configurazione delle cache di MariaDB. La config suggerita da loro (20% della RAM con MyISAM e 70% con InnoDB) presuppone 4GB di RAM, ma consigliano di abbassarla su sistemi con meno RAM. Nel tuo caso fai girare anche altra roba sullo stesso computer, quindi mi terrei ancora più basso, altrimenti rischi di "rubare" cache ad altri servizi, rendendoli molto lenti. Vedi qui: https://mariadb.com/kb/en/library/mariadb-memory-allocation/ Bye.
Re: Server che non rilascia la ram
On domenica 11 marzo 2018 12:33:52 CET Felipe Salvador wrote: > On Sun, Mar 11, 2018 at 10:23:27AM +0100, Michele Orsenigo wrote: > > Macchina dopo il riavvio 15gg fa: > > Fri Feb 23 07:10:01 CET 2018 > > > > totalusedfree shared buff/cache > > available > > > > Mem:1527216 182940 1185340 15504 158936 > > 1191596 Swap:975868 0 975868 > > > > Ora: > > totalusedfree shared buff/cache > > available > > > > Mem:1527216 1209240 157888 25068 160088 > > 152632 Swap:975868 0 975868 > > > > Mi aspetto che entro un paio di giorni cominci ad andare sullo swap > > (ho swappiness a 0) e quindi rallentare fino a diventare inutilizzabile, > > come è successo le altre volte > > In questo ultimo (Ora) non mi torna il conteggio free+buff/cache. > La available è inferiore alla somma dei due, oltre ad essere > inferiore alla buff/cache. Eh ... infatti ... > > In generale: > > Tieni presente che viene "swappato" tutto ciò che non è immediatamente > necessario. La swap non è una estensione della RAM, è la > soffitta dove piazzi il cambio stagione. La swap non è un male, è una > risorsa―lo puoi ben capire se al cambio stagione avendo una casa > piccola non hai spazio per mettere via i vestiti. > > Se hai poca RAM a disposizione comincerai a trovare OOM nei log, > a quel punto le applicazioni non avranno più modo di funzionare, avere > una partizione di swap capiente non ti salva da questo scenario. > Io riporterei il valore di swappiness a quello di default (60 se non > ricordo male). > > Leggi qui https://www.linuxatemyram.com/ Ok, ci ripenserò sulla swap: avevo seguito un consiglio legato a mariadb. In ogni caso il problema esisteva anche prima di portare la swappiness a 0 > > Se riscontri rallentamenti, se ne hai già riscontrati, dovresti > cominciare a pensare di aggiungere RAM. Anche qui però bisogna > ragionare. In che contesto riscontri rallentamenti? Cos'è a risultare > rallentato? I servizi forniti da apache e mysql, oppure l'accesso al > sistema e l'esecuzione di programmi (vedi top ecc ecc)? > I servizi che rallentano, fino a bloccarsi sono fondamentalmente mariadb e dovecot. Monitorando l'uso della ram per applicazione non riesco a vedere un aumento significativo nel tempo assegnabile ad un servizio. Se fermo, per esempio, apache (ma ho provato con mariadb) e lo lascio fermo anche per 24 ore, non riscontro alcun miglioramento significativo. Posso certamente aumentare ulteriormente la ram, ma vorrei prima capirne il motivo: possibile che con la vecchia versione e soli 700M di ram non avessi mai riscontrato simili problemi ? Il carico della macchina è perfino diminuito da allora ... Ciao e grazie ancora Michele -- Michele Orsenigo deb...@orsenigo.it
Re: Server che non rilascia la ram
On domenica 11 marzo 2018 11:39:51 CET Davide Prina wrote: . > > Sul server hai installato anche gnome? E' un server "puro": nessun ambiente grafico, non è installato neppure xorg ... Lo controllo esclusivamente con ssh. Quindi ... non so che pesci pigliare ... > > Ciao > Davide Ciao e grazie comunque ! Michele -- Michele Orsenigo deb...@orsenigo.it
Re: Server che non rilascia la ram
On Sun, Mar 11, 2018 at 10:23:27AM +0100, Michele Orsenigo wrote:
> Macchina dopo il riavvio 15gg fa:
> Fri Feb 23 07:10:01 CET 2018
> totalusedfree shared buff/cache
> available
> Mem:1527216 182940 1185340 15504 158936
> 1191596
> Swap:975868 0 975868
>
>
> Ora:
> totalusedfree shared buff/cache
> available
> Mem:1527216 1209240 157888 25068 160088
> 152632
> Swap:975868 0 975868
>
> Mi aspetto che entro un paio di giorni cominci ad andare sullo swap
> (ho swappiness a 0) e quindi rallentare fino a diventare inutilizzabile,
> come è successo le altre volte
In questo ultimo (Ora) non mi torna il conteggio free+buff/cache.
La available è inferiore alla somma dei due, oltre ad essere
inferiore alla buff/cache.
In generale:
Tieni presente che viene "swappato" tutto ciò che non è immediatamente
necessario. La swap non è una estensione della RAM, è la
soffitta dove piazzi il cambio stagione. La swap non è un male, è una
risorsa―lo puoi ben capire se al cambio stagione avendo una casa
piccola non hai spazio per mettere via i vestiti.
Se hai poca RAM a disposizione comincerai a trovare OOM nei log,
a quel punto le applicazioni non avranno più modo di funzionare, avere
una partizione di swap capiente non ti salva da questo scenario.
Io riporterei il valore di swappiness a quello di default (60 se non
ricordo male).
Leggi qui https://www.linuxatemyram.com/
Se riscontri rallentamenti, se ne hai già riscontrati, dovresti
cominciare a pensare di aggiungere RAM. Anche qui però bisogna
ragionare. In che contesto riscontri rallentamenti? Cos'è a risultare
rallentato? I servizi forniti da apache e mysql, oppure l'accesso al
sistema e l'esecuzione di programmi (vedi top ecc ecc)?
> Proverò a vedere se pulendo cache e buffer migliora qualcosa ...
>
> Provo a postare l'output di
> ps aux | awk '{print $2, $4, $11, $5}' | sort -k2r | head -n 30
>
> PID %MEM COMMAND VSZ
> 738 2.0 /usr/sbin/apache2 365488
> 658 16.9 /usr/sbin/mysqld 695116
> 561 0.8 /usr/sbin/opendkim 624528
> 22571 0.8 /usr/sbin/apache2 365788
> 22572 0.8 /usr/sbin/apache2 365788
> 22573 0.8 /usr/sbin/apache2 365788
> 28857 0.8 /usr/sbin/apache2 365788
> 22570 0.8 /usr/sbin/apache2 365572
> 22569 0.7 /usr/sbin/apache2 365540
> 34889 0.4 sshd: 95168
> 31465 0.4 pickup 83228
> 1 0.3 /sbin/init 204592
> 34891 0.3 /lib/systemd/systemd 56424
> 34842 0.3 dovecot/imap-login 21268
> 34872 0.3 dovecot/imap-login 21268
> 34873 0.3 dovecot/imap-login 21268
> 34913 0.3 dovecot/imap-login 21268
> 35967 0.3 dovecot/imap-login 21268
> 34898 0.3 -bash 21016
> 36756 0.2 ps 38304
> 220 0.2 /lib/systemd/systemd-journald 58120
> 34847 0.2 dovecot/imap 24024
> 35970 0.2 dovecot/imap 23764
> 34914 0.2 dovecot/imap 23756
> 34881 0.2 dovecot/imap 23676
> 34882 0.2 dovecot/imap 23668
> 34843 0.2 dovecot/config 20892
> 421 0.1 /usr/sbin/rsyslogd 321816
> 8933 0.1 /usr/sbin/dovecot 18000
>
> Grazie a tutti
>
> --
> Michele Orsenigo
> deb...@orsenigo.it
--
Felipe Salvador
Re: Server che non rilascia la ram
On 11/03/2018 10:23, Michele Orsenigo wrote:
Macchina dopo il riavvio 15gg fa:
Fri Feb 23 07:10:01 CET 2018
totalusedfree shared buff/cache available
Mem:1527216 182940 1185340 15504 158936 1191596
Swap:975868 0 975868
Ora:
totalusedfree shared buff/cache available
Mem:1527216 1209240 157888 25068 160088 152632
Swap:975868 0 975868
Mi aspetto che entro un paio di giorni cominci ad andare sullo swap
(ho swappiness a 0) e quindi rallentare fino a diventare inutilizzabile,
come è successo le altre volte
questa è una cosa che ho visto anch'io sui desktop e che ho segnalato
sia qui in lista che come bug. La segnalazione è stata molto generica e
non è stata considerata, anche perché quando avevo segnalato il problema
la situazione era davvero drammatica, poi con le versioni successive il
problema è diventato più difficile da riprodurre con un uso normale del PC.
Ho cercato di indagare ulteriormente, ma senza molto successo. Ho notato
che facendo determinate cose la situazione precipita e puoi arrivare
all'intervento di Linux che fa kill di X perché non c'è più memoria
disponibile, questo nel giro di poche ore (ad esempio se usi
l'estensione di gnome che ti cambia lo sfondo con un'immagine a caso
prelevata da una directory ogni pochi minuti... almeno era così, perché
quell'estensione poi l'ho disabilitata) o puoi simularlo facendo
avvenire il crash in pochi secondi con un piccolo programma C++ (alloca
la maggior parte di ram e poi chiede all'utente di far partire una
registrazione video del desktop di gnome... però questo potrebbe essere
un altro problema, cioè un bug della registrazione desktop di gnome).
Il problema secondo me è di gnome e in specifico gnome-shell. Ho letto
che hanno fatto recentemente un rifacimento della gestione della memoria
(è da quella versione che ho iniziato a verificare questo problema).
Avevo fatto delle prove su una macchina con installato XFCE e senza
gnome e li non mi sembrava ci fosse questo problema (però questa
macchina ha architettura i386, mentre quelle su cui ho riscontrato il
problema hanno architettura amd64).
Una sensazione mia è che il problema sia la gestione della memoria non
più usata, ho la sensazione che quando un'applicazione non ha più
bisogno di memoria allocata la rilascia, ma in realtà non viene
rilasciata subito, ma resta ancora occupata per un tot di tempo (che può
diventare molto lungo) e questo causa la saturazione di memoria.
Sul server hai installato anche gnome?
Provo ad allegare il sorgente del file C++, se qualcuno vuole testare...
deve avere gnome e non deve avere nessun dato non salvato perché a me
causa l'uccisione di X e quindi di tutti i programmi grafici in
esecuzione. Potrebbe essere che a seconda di quanta RAM si ha a
disposizione occorra cambiare la percentuale di allocazione (ora alloca
i 9/10 di RAM e io ho 4GB). Una volta avviato bisogna far partire la
registrazione del desktop ti gnome come indicato dal messaggio che appare.
Non ho ancora riportato questo programma nel bug report perché nessuno
ha risposto e quindi sembra che nessun altro abbia riscontrato questa
problematica.
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook
#include
#include
#include
#include
#define DEFAULT_MEMORY_TARGET 0
using namespace std;
static unsigned long int
get_memory_target (void)
{
FILE *f;
/* Really simple "get amount of memory on the machine" if it
* doesn't work, you just get the default memory target.
*/
f = fopen("/proc/meminfo", "r");
if (!f)
return DEFAULT_MEMORY_TARGET;
while (!feof(f))
{
char line_buffer[1024];
unsigned long int mem_total;
if (fscanf(f, "MemAvailable: %u", _total) == 1)
{
fclose(f);
return( mem_total * 1024 * 9 / 10);
}
/* Skip to the next line and discard what we read */
if (fgets(line_buffer, sizeof(line_buffer), f) == NULL)
break;
}
fclose(f);
return DEFAULT_MEMORY_TARGET;
}
int main( void )
{
unsigned long int TotMem = 0;
char *Buffer;
TotMem = get_memory_target();
if( TotMem == 0 )
{
cout << "Error reading memory";
return 1;
}
Buffer = new (std::nothrow) char[TotMem];
if( Buffer == NULL )
{
cout << "Error allocation " << TotMem << " memory";
return 1;
}
memset( Buffer, '-', TotMem-1 );
cout << "Nearly all the free RAM has been allocated (" << TotMem << " bytes). Press Ctrl-Alf-Shift-r to see the error and have a X crash... ATTENTION: you will lose all your not saved work!";
cout << "Elsewhere... press Enter key to stop
Re: Ancora su Spectre e Meltdown (variante SgxSpectre)
È stata scoperta una nuova variante denominata SgxSpectre[1] sull'architettura Intel® SGX[2]. Questo dimostra che metodi per aumentare la sicurezza possono essere minati alla fonte (CPU) e quindi essere insicuri. Sembra che le patch rilasciate da Intel siano aggirabili con questo attacco, mentre l'unica mitigazione funzionante sembra che sia la ricompilazione con retpoline... mi sa che fra un po' avremo l'intero sistema compilato con retpoline: prima ti fanno CPU che, mediante metodi predittivi e sfruttamento delle fasi idle delle CPU/CORE aumentano le prestazioni, poi ti fanno software che, per coprire bug di sicurezza hardware, ti rallentano qualsiasi applicativo :-( Ciao Davide [1] https://it.slashdot.org/story/18/03/10/0446211/sgxspectre-attack-can-extract-data-from-intel-sgx-enclaves [2] https://software.intel.com/en-us/sgx
Re: Server che non rilascia la ram
On sabato 10 marzo 2018 16:05:51 CET Felipe Salvador wrote:
> On Sat, Mar 10, 2018 at 02:14:42PM +0100, Michele Orsenigo wrote:
> > Ciao
>
> Ciao
Per prima cosa: grazie Felipe per la risposta
>
> > ho da poco rifatto un server (macchina virtuale a 32 bit con wheezy)
> > utilizzando stretch a 64 bit.
> > Non riesco però a capire perchè l'utilizzo di ram continui ad aumentare
> > nel
> > corso del tempo.
>
> Perché nel corso del tempo Linux la utilizza generosamente per cache e
> buffer e nell'utilizzarla non bada a quella che potrebbe essere la
> percezione dell'utente finale. Ergo, a te pare che sia un ingordo, in
> realtà sta facendo il suo dovere.
>
Macchina dopo il riavvio 15gg fa:
Fri Feb 23 07:10:01 CET 2018
totalusedfree shared buff/cache available
Mem:1527216 182940 1185340 15504 158936 1191596
Swap:975868 0 975868
Ora:
totalusedfree shared buff/cache available
Mem:1527216 1209240 157888 25068 160088 152632
Swap:975868 0 975868
Mi aspetto che entro un paio di giorni cominci ad andare sullo swap
(ho swappiness a 0) e quindi rallentare fino a diventare inutilizzabile,
come è successo le altre volte
> > I processi attivi sono mariadb, apache, postfix, dovecot, opendkim, ntpd e
> > sshd.
> > Ovviamente il maggior consumo è dato da mariadb e da apache, anche se
> > complessivamente è una macchina con un carico irrisorio (per la precedente
> > i 700M che aveva disponibili erano più che sufficienti)
>
> Cosa intendi? 700M di cosa?
700M di ram disponibile, la metà di questa.
>
> > La cosa strana è che anche killando uno ad uno i processi, la memoria non
> > viene rilasciata e l'unico modo per pulirla è riavviare.
>
> Perché continua a tenersi in pancia pagine e pagine di memoria sotto
> forma di cache e buffer. Puoi droppare cache e buffer selettivamente[¹], ma
> finché non riporti qual'è il problema questo rimane una non soluzione a un
> non problema.
Proverò a vedere se pulendo cache e buffer migliora qualcosa ...
Provo a postare l'output di
ps aux | awk '{print $2, $4, $11, $5}' | sort -k2r | head -n 30
PID %MEM COMMAND VSZ
738 2.0 /usr/sbin/apache2 365488
658 16.9 /usr/sbin/mysqld 695116
561 0.8 /usr/sbin/opendkim 624528
22571 0.8 /usr/sbin/apache2 365788
22572 0.8 /usr/sbin/apache2 365788
22573 0.8 /usr/sbin/apache2 365788
28857 0.8 /usr/sbin/apache2 365788
22570 0.8 /usr/sbin/apache2 365572
22569 0.7 /usr/sbin/apache2 365540
34889 0.4 sshd: 95168
31465 0.4 pickup 83228
1 0.3 /sbin/init 204592
34891 0.3 /lib/systemd/systemd 56424
34842 0.3 dovecot/imap-login 21268
34872 0.3 dovecot/imap-login 21268
34873 0.3 dovecot/imap-login 21268
34913 0.3 dovecot/imap-login 21268
35967 0.3 dovecot/imap-login 21268
34898 0.3 -bash 21016
36756 0.2 ps 38304
220 0.2 /lib/systemd/systemd-journald 58120
34847 0.2 dovecot/imap 24024
35970 0.2 dovecot/imap 23764
34914 0.2 dovecot/imap 23756
34881 0.2 dovecot/imap 23676
34882 0.2 dovecot/imap 23668
34843 0.2 dovecot/config 20892
421 0.1 /usr/sbin/rsyslogd 321816
8933 0.1 /usr/sbin/dovecot 18000
Grazie a tutti
--
Michele Orsenigo
deb...@orsenigo.it
