{"id":82,"date":"2012-12-18T15:01:59","date_gmt":"2012-12-18T14:01:59","guid":{"rendered":"http:\/\/eppesuigoccas.homedns.org\/wordpress\/?p=82"},"modified":"2014-07-02T10:23:41","modified_gmt":"2014-07-02T09:23:41","slug":"la-dimensione-delle-directory","status":"publish","type":"post","link":"https:\/\/blog.sguazz.it\/index.php\/archives\/82","title":{"rendered":"La dimensione delle directory"},"content":{"rendered":"<p>Ieri sono intervenuto su un server che aveva un <em>load average<\/em> parecchio alto e passava il 90% del tempo in modalit\u00e0 kernel. Usando il comando <code>top<\/code> ho visto che i processi in cima alla classifica erano dei server oracle ed exim. I processi oracle possono stare l\u00ec per parecchio tempo perch\u00e9 vi possono essere delle query particolarmente impegnative, ma il comando exim mi ha un po&#8217; insospettito.<\/p>\n<p>Ho quindi verificato che un certo job veniva lanciato dal cron ogni minuto e inviava un email con degli errori di sintassi. Exim avrebbe dovuto occuparsi della consegna dell&#8217;email, ma a causa di un errore nella configurazione del DNS, non vi riusciva e si riproponeva di riprovare pi\u00f9 tardi, lasciando quindi quell&#8217;email in coda.<\/p>\n<p>Tutti i messaggi della coda di Exim stanno nella directory <code>\/var\/spool\/exim\/input<\/code>. In questa directory c&#8217;erano circa 177000 file. I file di per s\u00e8 sono tanti, ma rimangono gestibili. Visto che tutti quanti erano eguali e riportavano gli stessi errori, ho pensato di rimuoverli con piccolo ciclo shell che richiamasse il comando <code>exim -Mrm NOMEFILE<\/code>. Dopo circa mezz&#8217;ora erano stati cancellati solo 6000 file e il <em>load average<\/em> era raddoppiato. Allora ho fatto il tutto in maniera forse poco ortodossa, cancellando con il comando <code>rm<\/code> tutto il contenuto della directory.<\/p>\n<p>Il <em>load average<\/em> \u00e8 sceso, ma i nuovi messaggi generati dal cron (per il job in questione e per altri job) facevano comunque s\u00ec che il processo exim restasse in cima alla classifica. E soprattutto, la maggior parte del tempo CPU era sempre passata in modalit\u00e0 kernel anzich\u00e9 utente.<\/p>\n<p>Ho allora verificato quanto fosse grande la directory \/var\/spool\/exim\/input:<\/p>\n<p><code># ls -ld \/var\/spool\/exim\/input<br \/>\ndrwxr-x--- 2 Debian-exim Debian-exim 4643078144 dic 12 17:39 \/var\/spool\/exim\/input<\/code><\/p>\n<p>che fa circa 4Gb per la sola directory. Ho quindi \u00abclonato\u00bb la directory e tutto si \u00e8 magicamente sistemato:<\/p>\n<p><code># mkdir \/var\/spool\/exim\/input2<br \/>\n# chown --reference \/var\/spool\/exim\/input{,2}<br \/>\n# chmod --reference \/var\/spool\/exim\/input{,2}<br \/>\n# mv \/var\/spool\/exim\/input{,.bak} &amp;&amp; mv \/var\/spool\/exim\/input{2,}<br \/>\n# invoke-rc.d exim restart<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ieri sono intervenuto su un server che aveva un load average parecchio alto e passava il 90% del tempo in modalit\u00e0 kernel. Usando il comando top ho visto che i processi in cima alla classifica erano dei server oracle ed exim. I processi oracle possono stare l\u00ec per parecchio tempo perch\u00e9 vi possono essere delle [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,3],"tags":[],"class_list":["post-82","post","type-post","status-publish","format-standard","hentry","category-sysadmin","category-computer"],"_links":{"self":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/82","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/comments?post=82"}],"version-history":[{"count":5,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/82\/revisions"}],"predecessor-version":[{"id":101,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/82\/revisions\/101"}],"wp:attachment":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/media?parent=82"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/categories?post=82"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/tags?post=82"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}