<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br>Il giorno 4 set 2019, alle ore 10:50, Carlos Catucci <<a href="mailto:carlos.catucci@gmail.com">carlos.catucci@gmail.com</a>> ha scritto:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 4 Sep 2019 at 10:44, Giovanni Vittorio Spina <<a href="mailto:vittorio.spina@gmail.com">vittorio.spina@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ciao a tutti, <br>
Ho un problema importante che non so bene come risolvere.<br>
Faccio applicazioni python per lavoro. Sono grafiche oppure solo testuali che girano su macchine linux di varia natura.<br>
Su tutte sto avendo problemi di ram nel senso che la ram occupata dal processo python aumenta sempre fino ad un kill del sistema operativo per out of memory quando la ram del sistema finisce. <br>
Al momento posso solo risolvere con un wachdog che riavvii l’applicazione quando viene chiusa, ma non mj pare la cosa più elegante.<br>
Uso parecchie librerie di terzi e fatte da me in dieci anni.<br>
Conoscete un modo per debuggare una cosa del genere?<br>
Non so bene dove sbattere la testa.</blockquote></div><div><br></div><div><div style="font-size:small" class="gmail_default">Senza vedere il codice difficile aiutarti. Pero' tieni conto di una cosa, Python ha il meccanismo di Garbage Collecting, per cui al contrario di C non ti devi preoccupare di liberrare la mmoria quando un componente non viene piu usato. Pero' se il tuo codice crea una serie di oggetti (ad esempio) che hanno scope globale, questi non verranno mai distrutti fino che lìapplicazione sta girando. Se continui ad aggiungere prima o poi ovvio che saturi la memoria. <br></div><div style="font-size:small" class="gmail_default">Altro ottimo modo di arrivare questo e' caricare in memoria tabelle di dati senza paginarle, esempio dati di una tabella dDb che contine decine di campi e milioni di record. <br></div><div style="font-size:small" class="gmail_default">Molto probabile pero' che si tratti di bad design delle applicazioni. Se metti su pastebin il codice (sempre che non sia closed) i puo' provare a vedere, in caso contrario dovresti almeno indicare il flusso logico che usi per una applicazione che presenta il problema.</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">Carlos<br></div></div></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>Python mailing list</span><br><span><a href="mailto:Python@lists.python.it">Python@lists.python.it</a></span><br><span><a href="https://lists.python.it/mailman/listinfo/python">https://lists.python.it/mailman/listinfo/python</a></span><br></div></blockquote><br><div>Il fatto è che il codice è piuttosto grande, si parla di centinaia di migliaia di righe fra librerie e altro quindi dare il codice è complicato. Ho notato il problema da quando uso sqlite3 per gestire le variabili di configurazione, potrebbe nascere si lì ma non posso escludere che il problema sia altrove. In generale non ho variabili che incremento di continuo. E ho notato un incremento anche killando il thread di sqlite e cancellando con del(var) sia con che cursor di sqlite.</div><div>Non so bene come analizzare la cosa.</div><div>C’è un modo per vedere lo spazio allocato per variabile in una applicazione, magari anche da dentro al main e avere una lista di quanto crescano le variabili?</div><div>Il problema non si risolve neanche chiamando esplicitamente il collect di gc.</div><div>Vittorio</div></body></html>