Archives For Tuning Software

Avevamo già parlato di ServiceDesk Plus e tuning qualche tempo fa, quando la piattaforma principale girava su MySQL (se la usavi già da qualche tempo), ormai andato completamente fuori supporto secondo lo sviluppatore del software (è stato richiesto il passaggio a PostgreSQL per continuare a ottenere supporto):

Pulizia e Tuning di ServiceDesk Plus (MySQL)

Cosa cambia dal punto di vista del tuning dell’installazione con PgSQL?

Tuning di ServiceDesk Plus (PostgreSQL)

Nulla a livello di Wrapper Java, almeno rispetto alla precedente volta quando si parlava di modifica per macchine con almeno (o più) di 4 GB di RAM, che è poi lo stesso concetto di base che riguarda l’ulteriore modifica del file di configurazione del Postgres suggerito sempre all’interno della community del prodotto (ServiceDesk, nda).

Ferma il servizio di ServiceDesk prima di continuare ed effettua un backup dei tuoi attuali dati (consigliato uno Snaphost della macchina, se virtuale).

Ti ripropongo ora il passaggio relativo al Wrapper del precedente articolo:

Il file di configurazione del Wrapper Java è quello che trovi in C:\ManageEngine\ServiceDesk\server\default\conf\wrapper.conf, da ritoccare sui due valori suggeriti:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

a (nel caso della mia macchina con più di 4GB di RAM, occhio quindi alla tua):

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

[…]

Ciò che stavolta cambia è il file di configurazione relativo al database. Sto parlando del postgres_ext.conf che dovresti poter trovare già nella cartella ManageEngine\ServiceDesk\pgsql\data. Probabilmente al suo interno potresti già trovare qualche specifica, per esempio:

wal_level = archive
archive_command = 'IF EXIST archive.bat (archive.bat "%p" "%f")'
archive_mode = on

Ciò che tu devi fare, è semplicemente dare un colpo di invio e aggiungerne qualcuna in più, per includere nuovi parametri entro i quali Postgres può continuare a riservare memoria per sé. Sto parlando di questi:

shared_buffers = 512MB
maintenance_work_mem = 100MB
effective_cache_size = 512MB
work_mem = 12MB

che, rispettivamente:

  • shared_buffers: corrisponde generalmente al 25% della memoria di sistema. Su Windows, 512 MB può essere il valore massimo.
  • maintenance_work_mem: corrisponde circa il 5% della memoria di sistema, ma senza superare mai i 512 MB.
  • effective cache size: si aggira approssimativamente sul 50% della memoria fisica disponibile, ho personalmente continuato a indicare 512 MB anche se avrei potuto tenerlo più alto.
  • work_mem: riporta un valore ragionevole che si attesta tipicamente tra i 4 e i 64 MB.

Il riferimento sulla community di ManageEngine, seppur riferito a SupportCenter, è questo: pitstop.manageengine.com/portal/community/topic/supportcenterplus-optimize-postgresql

Puoi riavviare ora il servizio di ServiceDesk per verificare se la modifica alla configurazione appena operata ha portato i benefici sperati (risposta positiva nel mio caso).


Condividi l'articolo con i tuoi contatti:

Stavo facendo regolare manutenzione della macchina di HelpDesk (quella che in ufficio fa girare un’installazione di ServiceDesk Plus, te ne ho già parlato in passato) e mi sono accorto che nel database, la tabella relativa ai log di errore, era cresciuta fino a toccare quota 5,5 GB circa. Dato che con la migrazione a Windows 2012 Server ci siamo portati dietro lo storico di quanto operato fino a quel momento, ho contato nell’errorlog qualcosa come 200.000 eventi e più, circa 6 anni di onorato servizio. Era arrivato il momento di fare un po’ di pulizia.

ServiceDesk: una toolbar personalizzata sempre in vista 1

Per farla breve: utilizzare la GUI in questo caso è impossibile. Gli eventi sono troppi, il software di HelpDesk non è in grado di navigare correttamente tra le tab del log. È quindi consigliato operare direttamente sul database, dopo aver eseguito un backup dello stesso (non si sa mai, fallo senza pensarci due volte e mettiti al sicuro). L’operazione richiederà un rapido fermo dei servizi (immediatamente riavviabili) e non dovrebbe impattare troppo sull’attività dei tecnici e degli utenti, ammesso che il server che ospita l’applicazione abbia sufficiente RAM e CPU a disposizione per tenere a bada i consumi del motore SQL (nel mio caso MySQL) e Java.

Per effettuare una buona pulizia, sono stato anche costretto a un rapido tuning dell’applicativo, andando a modificare alcuni parametri consigliati da Manage Engine. Mettiti “comodo” (si fa per dire) e preparati a fare qualche ritocco sotto al cofano.

Pulizia e Tuning di sistema

Volendo tenere gli ultimi 60 giorni di log e quindi buttare via tutto il resto, sarà necessario dare alla macchina un attimo più di sprint, questo è necessario nel caso in cui quella tabella sia troppo ricca di eventi (puoi vederlo tu stesso con un semplice clic su Community (l’icona del supporto, nelle ultime versioni di ServiceDesk Plus) → System Log Viewer:

Pulizia e Tuning di ServiceDesk Plus

Come detto prima, quel numero “of 2368” superava i 200.000!

Una volta connesso al DB MySQL, l’operazione di pulizia fallirà quasi certamente a causa del buffer InnoDB “troppo stretto“. Puoi controllare tu stesso. Per connetterti al MySQL che sta girando sulla macchina dovrai aprire un prompt dei comandi, quindi andare in C:\ManageEngine\ServiceDesk\mysql\bin, ammesso che tu abbia installato tutto nel disco principale del server (altrimenti sostituisci C:\ con la lettera del drive all’interno del quale si trova ServiceDesk Plus).

Se anche il tuo ServiceDesk Plus utilizza MySQL, continua la lettura delle istruzioni di seguito, in caso contrario dovrai modificare il metodo di collegamento (consulta questa risposta sul forum ufficiale: forums.manageengine.com/topic/how-to-delete-all-log-files#49000007368489):

mysql.exe -u root -P 33366 servicedesk

Una volta connesso, lancia la cancellazione dell’intervallo desiderato (nell’esempio, ho mantenuto 60 giorni di storico, tu puoi ovviamente modificarlo aumentandolo o diminuendolo a piacere), l’istruzione di seguito è valida per MySQL:

delete from errorlog  WHERE DATEDIFF(NOW(),FROM_UNIXTIME(OCCURREDTIME/1000))  >60;

Quasi certamente arriverai a vedere l’errore 1206, causato dall’elevato numero di lock rispetto allo spazio a disposizione in tabella. Per verificare il perché, prova a lanciare uno show global variables like 'innodb_buffer%':

Pulizia e Tuning di ServiceDesk Plus 1

Quel valore (8,388,608 espresso in byte) è basso, è circa l’equivalente di 8MB, non è sufficiente. Per questo motivo sarai costretto a modificare il batch che si occupa di lanciare il motore SQL di ServiceDesk Plus, in base alla RAM a tua disposizione sul server, secondo quanto suggerito nel forum del prodotto: forums.manageengine.com/topic/manage-engine-supportcenter-plus-slowness-and-takes-ages-to-load-the-request-screen. La mia macchina ha più di 4GB di RAM, per questo motivo ho aperto C:\ManageEngine\ServiceDesk\bin\startDB.bat e ho inserito i vari parametri suggeriti:

@start "MySQL" /B "%DB_HOME%\bin\mysqld-nt" --standalone --lower-case-table-names=1 --basedir="%DB_HOME%" --port=%DB_PORT% --datadir="%DB_HOME%\data" --default-character-set=utf8 --set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=2M --sort_buffer_size=4M --myisam_sort_buffer_size=8M --key_buffer_size=64M --innodb_buffer_pool_size=750M --bulk_insert_buffer_size=16M --table_cache=1024M --innodb_flush_log_at_trx_commit=0 --low-priority-updates

Stessa sorte toccata al file di configurazione del Wrapper Java, quello che trovi in C:\ManageEngine\ServiceDesk\server\default\conf\wrapper.conf, modificato alla stessa maniera e ritoccato sui due valori suggeriti, da:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

a (nel caso della mia macchina con più di 4GB di RAM, occhio quindi alla tua):

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

A questo punto potrai fermare e avviare nuovamente il tuo ServiceDesk Plus. Così facendo, collegandoti nuovamente al database, dovresti poter notare che il valore di innodb_buffer_pool_size è aumentato fino a toccare la quota richiesta dalla tua modifica nel file batch (startDB):

Pulizia e Tuning di ServiceDesk Plus 2

Ora potrai finalmente lanciare la pulizia, che non dovrebbe più bloccarsi, e che dovrebbe pulire quanto richiesto entro qualche minuto di lavoro al massimo:

Pulizia e Tuning di ServiceDesk Plus 3

Ora finalmente potrai navigare il System Log da interfaccia grafica di ServiceDesk Plus, avrai reso più rapidi i backup da eseguire quando si lancia un upgrade di prodotto e avrai risparmiato un po’ di spazio su disco, il tutto condito da una maggiore velocità di avvio della piattaforma.

Non male, vero? :-)

Condividi l'articolo con i tuoi contatti:

La risposta per cominciare bene questo post è: SI, è possibile ottimizzare quel tanto che basta il proprio Firefox per permettergli di “non rubare troppa RAM” alla macchina che lo ospita. Ci sono alcuni accorgimenti da non lasciarsi sfuggire che potrebbero nettamente migliorare la vostra esperienza di navigazione, provare per credere.

# la premessa

Software miracolosi che promettono mare & monti non esistono. Codici come Fasterfox o applicativi come Firetune registrano casistiche vittoriose troppe poche volte rispetto a quelle durante la quali combinano “danni” che poi gli utenti lamentano sul forum di Mozilla Italia o su altri specializzati.

Evitate di affidarvi a soluzioni pre-confezionate, peggio ancora se a codice chiuso, non saprete mai cosa andranno a toccare dopo aver selezionato “Migliora le prestazioni!“. Se proprio volete ottimizzare il vostro browser, metteteci mani e testa, magari con qualche suggerimento dato nei paragrafi successivi.

# fa come se fossi a casa tua

Ma non sporcare e non trattare male il panda, nuoce gravemente alla tua ed alla nostra salute quando cercheremo di aiutarti il giorno in cui deciderai di aprire un thread di assistenza nel forum dedicato. Firefox viene rilasciato perfettamente funzionante, provato su più configurazioni e minuziosamente controllato, riga per riga. Il fatto che sul proprio PC non parta correttamente potrebbe voler dire tante cose, ma quasi sicuramente non che l’applicativo in se abbia un bug o sia “nato male“. Cerchiamo di capire quindi come personalizzarlo senza abusare della sua bontà!

# estensioni da tenere al guinzaglio

MozillaZine è un’0ttima risorsa che contiene tanta documentazione riguardante i prodotti Mozilla. Già da tempo è disponibile in KB un elenco che raccoglie tutte le estensioni più “dannose” per il browser, quelle che a causa di uno sviluppo evidentemente non perfetto potrebbero mettere in serie difficoltà il browser:

http://kb.mozillazine.org/Problematic_extensions

In corrispondenza dell’estensione incriminata troverete la soluzione migliore da adottare nel caso in cui non possiate proprio farne a meno. Persino la tanto amata AdBlock Plus potrebbe crearvi rogne … non ci credete?

Can interfere with Flash content, most often on Mac OS.

Certo si fa riferimento a Mac OS in particolare, ma chi vi ha detto che:

Uncheck “Show Tabs on Flash and Java” in Adblock Plus options.

funzioni solo sul sistema di casa Apple? Sarebbe bene anche replicare l’azione su sistemi Windows e Linux, risparmiate quella piccola goccia che sommata a tante altre vi crea la “pozzanghera” ;)

Vi avevo già parlato di “estensioni esose” molto tempo fa, l’elenco era “spuntato fuori” proprio grazie a MozillaZine, io non avevo fatto altro che testare e scrivere in proposito. Inutile dire che il sito aggiorna costantemente quella lista con risoluzioni e alternative, vero?

Segnalo inoltre un bug aperto da diverso tempo ma non ancora risolto. Si tratta di una dispersione di risorse RAM con l’utilizzo della Google Toolbar ufficiale:

https://bugzilla.mozilla.org/show_bug.cgi?id=440090

Strumento utilizzato da tantissimi utenti che ignorano l’esistenza di valide alternative come Googlebar Lite o simili:

extenzilla.org/scheda_estensione.php?id=429

# gli alti consumi dei plugin

I plugin che si aggiungono durante l’utilizzo quotidiano del browser sono diversi, ognuno necessario all’esplorazione del web ma –talvolta– programmato male per browser non “inizialmente previsti“, magari perché si tratta di porting da altre piattaforme, o per stupide distrazioni del dipendente di turno, riportate poi nelle nuove versioni. Ecco perché MozillaZine propone 4 articoli dedicati ai 4 plugin più utilizzati in Firefox (così come in altri browser):

Le spiegazioni sono dettagliate, in inglese (se avete bisogno e non capite troppo bene basta chiedere, ne possiamo parlare sul forum) e provano a mettere “una pezza” laddove esiste la reale perdita di risorse.

# about:consumameno!!

Non è un comando da dare nella solita barra URL, è solo un modo per convincervi che Firefox può effettivamente migliorare e consumare un pò meno “del solito“. Il fenomeno Memory Leak esiste da quando il panda rosso è nato, più o meno. Versione dopo versione, promessa dopo promessa, oggettivamente parlando bisogna ammettere che non è cambiato molto (ciò farà la felicità di qualcuno a caso che continua a gridarlo a gran voce).

Tutto questo anche a causa della nostra quotidiana necessità di funzioni avanzate che non vengono incluse nativamente nel browser. Le estensioni sono la gioia di ogni navigatore, la pena di ciascun utilizzatore di PC con RAM limitata, al 99,9% delle volte corrispondono alla stessa persona.

Prima di cominciare è obbligatorio il solito avviso, meglio prevenire no? :P

ATTENZIONE: Prima di eseguire qualsiasi modifica ai vostri file e/o dispositivi siete pregati di effettuare un backup di questi. Solo così sarete capaci di tornare indietro riparando ad eventuali errori di distrazione. L’articolo e l’autore non possono essere ritenuti responsabili di alcun danno subito dalla vostra strumentazione. Buon lavoro.

Modificando alcuni valori nell’about:config si può cominciare a risparmiare qualcosina. Andiamo nel dettaglio:

Sfatiamo innanzi tutto il mito del “config.trim_on_minimize“, pubblicato su diversi blog e siti web specializzati, in quanto non libera la RAM per volere divino. Spiega MozillaZine:

On Windows operating systems, when a program is minimized and left for a period of time, Windows will swap memory the program is using from RAM onto the hard disk in anticipation that other programs might need RAM []

Ciò vuol dire che non c’è un effettivo risparmio di memoria ma c’è di sicuro un lavoro maggiore dato in pasto alla macchina nel momento in cui si decide di tornare a lavorare su Firefox “svegliandolo” dalla barra di sistema. Al contrario di questa voce, altre 3 risolvono effettivamente degli “abusi di cache” non autorizzati o non voluti dall’utente.

Rispettivamente browser.cache.memory.capacity:

When images are loaded, they can be cached so they don’t need to be decoded or uncompressed to be redisplayed. This preference controls the maximum amount of memory to use for caching decoded images and chrome (application user interface elements).

browser.cache.memory.enable:

When a page is loaded, it can be cached so it doesn’t need to be rerendered to be redisplayed. This preference controls whether to use memory to cache decoded images, chrome (application user interface elements), and secure (https) pages. browser.cache.memory.capacity controls the maximum amount of memory to use.

e browser.sessionhistory.max_total_viewers:

Pages that were recently visited are stored in memory in such a way that they don’t have to be re-parsed (this is different from the memory cache). This improves performance when pressing Back and Forward.

This preference limits the maximum number of pages stored in memory.

alleggerendo quindi la memorizzazione di pagine ed elementi in esse contenuti si potrà certamente risparmiare della memoria RAM solitamente utilizzata da una configurazione di default. Il primo ed il terzo valore corrispondono ad un intero variabile, il secondo è un booleano. Come modificarli? Semplice, basta dare una occhiata alle tabelle di corrispondenza “valore / memoria usata” nelle pagine dello stesso MozillaZine:

kb.mozillazine.org/Browser.cache.memory.capacity#Possible_values_and_their_effects

Valore consigliato? 0, così da tenere spenta la memorizzazione degli elementi (Do not cache decoded images and chrome in memory. ).

kb.mozillazine.org/Browser.sessionhistory.max_total_viewers#Possible_values_and_their_effects

Valore consigliato? Ancora una volta 0, affinché non vengano tenute pagine in memoria (Do not store any pages in memory. ).

Per quello che invece riguarda il valore “browser.cache.memory.enable” basterà portarlo a “false“.

ATTENZIONE: la configurazione appena suggerita può essere davvero vantaggiosa solo ed esclusivamente nel caso in cui si sfrutti una connessione ADSL flat o superiore. Questo perché le pagine vengono costantemente ricaricate e chi possiede un modem 56k, ISDN o una tariffa a “traffico fatto” potrebbe trovarsi in serie difficoltà.

# un riavvio al giorno leva il medico di torno …

In realtà ben più di un riavvio farebbe bene al browser. Certo parla una persona che lo tiene aperto dalla mattina alla sera, fino a quando abbandona l’ufficio sempre dritto senza chiusure (salvo per estensioni nuove installate o aggiornamenti di plugin), ma ciò non fa certo bene al software, soprattutto se parliamo di utenze che tengono aperte decine di schede contemporaneamente.

Ogni tanto si può pensare di uscire da Firefox salvando le attuali schede aperte e facendosele riaprire alla successiva sessione, è una funzione che il browser possiede già da tempo, perché non sfruttarla?

# casistiche di successo

Di casistiche ne ho quante ne volete. Il forum di Mozilla Italia è davvero pieno di thread che riguardano lentezze anomale, crash inaspettati e tanto altro, quasi sempre imputabile ad un utilizzo non troppo corretto della piattaforma. Giusto qualche giorno fa si parlava di lentezza esasperante per poi scoprire che una cronologia non tenuta sotto controllo metteva in difficoltà il software:

forum.mozillaitalia.org/index.php?topic=38245.0

Ricordate: Firefox viene fornito funzionante e testato (come già detto ad inizio post). Il problema è sempre lo stesso più volte citato nelle battute tra informatici, smanettoni o semplici interessati all’argomento: “il reale problema sta sempre tra la sedia e la tastiera“.

Se non dovesse poi bastarvi la documentazione in lingua inglese (e vi assicuro che là fuori ce n’è davvero tantissima), il progetto SUMO (la Knowledge Base di Mozilla Firefox) può vantare una vastità di documenti localizzati in italiano sempre dalla nostra squadra, qui di seguito vi lascio il collegamento diretto ad uno dei tanti, come mi ha fatto giustamente notare Simone nei commenti:

support.mozilla.com/it/kb/Utilizzo+eccessivo+della+memoria

A me non resta che augurarvi buona modifica e buon utilizzo, con la speranza che questo articolo possa aiutarvi a migliorare il vostro rapporto con il browser Mozilla :)

Basato su “Memory Leak” di MozillaZine

Condividi l'articolo con i tuoi contatti: