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.

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:

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%':

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):

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

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? :-)