6 suggerimenti utili per la corretta configurazione di MailStore Server
MailStore Server è un applicativo estremamente versatile, in grado di lavorare praticamente con tutte le piattaforme di posta elettronica presenti sul mercato e in grado anche di soddisfare le richieste degli utenti più esigenti.
Tuttavia, se il server di posta da cui si archiviano le email è di grandi dimensioni, è possibile che i limiti dell’HW su cui è stato installato MailStore, o una limitata larghezza di banda disponibile verso il server di posta, possano creare dei problemi al suo normale funzionamento.
L’ ottimizzazione di MailStore non è difficile e consiste principalmente nello scegliere la frequenza più idonea con cui sono archiviate le nuove email ricevute.
Generalmente, quando si configura MailStore per la prima volta, si ha la tendenza ad optare per l’approccio “controlla con la maggiore frequenza possibile se sono arrivati nuovi messaggi non ancora archiviati”. Questa scelta, però, vedremo che rischia di sovraccaricare inutilmente le risorse messe a disposizione del sistema su cui è installato.
Di seguito, cercheremo di elencare dei suggerimenti semplici per ottimizzazione il funzionamento di MailStore in base alle risorse del sistema che lo ospita.
1) Controllare il carico sul server con il monitor Luke
Il modo più immediato per capire cosa sta succedendo in MailStore è vedere quanto spesso i “task” sono in esecuzione, quanto tempo impiegano per essere completati e se sono eseguiti contemporaneamente. Per questo, durante la fase di configurazione, è fondamentale monitorare con attenzione elenco dei “task” seguente.
Un altro strumento per controllare il carico del sistema è il Task Manager di Windows, con cui è possibile esaminare sia la memoria occupata che l’utilizzo della CPU del processo MailStoreServer.exe / MailStoreServer_x64.exe.
NOTA: Sui server in cui si stanno eseguendo più archiviazioni in parallelo (“Thread” di seguito), l’aumento incontrollato dell’occupazione della memoria è un vero e proprio campanello di allarme che avvisa della necessità di ridurre il numero di “thread” di archiviazione simultanei in esecuzione.
In generale la gestione della CPU da parte di MailStore può essere vista nel seguente modo.
Ogni archiviazione di una casella di posta mantiene occupato un core della CPU.
In Windows, grazie al multitasking, un singolo core della CPU può gestire più di un task alla volta. Ciò consente a più “thread” di condividere una stessa CPU che quindi elaborerà alternativamente un pezzo di un “thread”, poi quello di un altro e così via.
Alla luce di ciò, si consiglia di non superare un numero di “thread” in esecuzione doppio rispetto ai core disponibili nella CPU, che significa che ogni 2 “thread” di archiviazione ci debba essere minimo 1 core della CPU.
Pertanto, è molto importante pianificare e programmare accuratamente i vari profili per essere sicuri che non ci siano contemporaneamente in esecuzione troppi “thread”.
Se supponiamo di avere 100 profili in esecuzione contemporaneamente in un determinato istante della giornata, per ottenere buone prestazioni idealmente occorrerebbero 100 core della CPU o, come detto sopra, almeno 50. E’ evidente, che in una situazione simile, solo una buona pianificazione possa evitare di dover fornire una quantità così enorme di risorse all’applicativo.
2) Evitare di lanciare la modalità “automatica” un numero elevato di profili differenti
La modalità di archiviazione automatica è stata introdotta nella versione 9, in pratica MailStore, dopo l’esecuzione di ogni “task” fa una pausa di 5 minuti (intervallo che eventualmente è possibile modificare) per poi rieseguirlo nuovamente.
Se l’esecuzione di un “task” richiede solo pochi secondi, ripetere questa attività ogni 5 minuti non comporta rischi di sovraccarico.
Se, invece, il processo di sincronizzazione delle caselle postali viene eseguito per un numero elevato di utenti, per il suo completamente potrebbe essere necessario un tempo molto più lungo, ad esempio 15 minuti, rimanendo poi inattivo per soli 5 minuti prima di ricominciare. Quindi, in questo caso, la percentuale di utilizzo delle risorse del server aumenterà al 75% sovraccaricandolo pesantemente.
Per risolvere il problema si potrebbe aumentare il periodo di attesa tra l’esecuzione di un “task” e la successiva, ma in casi come questo è sicuramente meglio cambiare completamente strategia di archiviazione utilizzando ad esempio “task” pianificati come descriveremo di seguito.
Modalità automatica e avvio del servizio.
Ultima avvertenza sui “task” automatici: essi iniziano tutti con il servizio MailStore, quindi, se si riavvia il server, o si riavvia il servizio, sul server saranno lanciati contemperamene tutti i task posti in modalità automatica, sulla rete sarà richiesto il massimo traffico necessario all’esecuzione dei “task” e il server sarà oberato dalle richieste di esecuzione di tutti i task. Uno scenario di questo tipo è sicuramente da evitare nel caso di installazioni con numero molto elevato di caselle di posta da archiviare.
Poiché il tempo necessario per terminare un “task” non può essere previsto con esattezza a priori, quando si avviano molti profili tutti insieme (ad esempio all’avvio del servizio MailStore Server), questi termineranno in momenti differenti e, una volta trascorso il periodo di pausa, saranno eseguiti nuovamente. Siccome non si ha alcun controllo sulla successione dell’esecuzione dei “task”, può succedere che in determinati istanti siano eseguiti contemporaneamente tutti i task e di aver bisogno quindi per la loro esecuzione di un numero di “core” della CPU pari al 50% del numero di profili di archiviazione impostati.
Per questo motivo, ogni volta che si devono archiviare più caselle postali da un singolo server di posta elettronica in cui è possibile utilizzare un unico account di servizio per il recupero di tutte le email, il produttore raccomanda di preferire il metodo di archiviazione chiamato “journaling”.
Il metodo di archiviazione “journaling” è sicuramente utilizzabile con Microsoft Exchange e 365, Google GSuite, IceWarp, Kerio Connect, server Linux, come Dovecot e con molti altri server di posta elettronica.
In un profilo di “journaling” multimailbox l’archiviazione sarà eseguita come “batch” e il numero di utenti / caselle di posta sono già definiti. Tale profilo potrà essere impostato esplicitamente per essere eseguito con un numero massimo di “thread” per volta.
3) Utilizzo di un “task” programmato
La pianificazione programmata dei “task” in MailStore viene spesso trascurata perché normalmente non archivia con la stessa elevata frequenza della modalità automatica. Se però un “task” automatico richiede più di 15 minuti per concludersi, è una alternativa che va assolutamente presa in considerazione.
In definitiva, la pianificazione programmata obbliga alla determinazione di quanto tempo ci vorrà affinché una nuova email sia presente nell’archivio. Quindi, se si riesce ad accettare il fatto che un nuovo messaggio sarà ricercabile nell’archivio solo dopo ad esempio 30 minuti (o un’ora) anziché in un tempo minore, al server sarà risparmiato molto lavoro.
Usando i “task” pianificati, si sceglie semplicemente l’intervallo di esecuzione o un determinato orario ogni tot minuti, giorni, settimane, mesi.
NOTA: qualunque “task” si configuri, consigliamo di dargli sempre un nome da cui sia facile dedurre se si tratta di un “task” automatico, manuale o programmato.
4) Determinazione del corretto numero di “thread”
In base all’esperienza maturata in questi anni, quando si riscontra un rallentamento del server su cui è installato MailStore, di solito ciò è dovuto al numero troppo elevato di thread di archiviazione in esecuzione.
Ciò è particolarmente importante se si utilizza un “task” per l’archiviazione di caselle postali multiple (“journaling”), con cui è possibile archiviare simultaneamente al più caselle postali del server. L’impostazione predefinita per questo tipo di “task” è di 5 “thread”, ma se si dispone di più “task” che si collegano a più caselle postali è possibile avere rapidamente molti task sovrapposti che impegneranno ancora più “thread”.
Ogni “thread” richiede della memoria per la sua esecuzione, quindi, se Mailstore Server sta impegnando una grande quantità di memoria, è molto probabile ci siano in esecuzione contemporanea molti “thread”.
Da test eseguiti, non è stata riscontrata molta differenza nella velocità di archiviazione complessiva quando si riducono i “thread”, quindi un altro suggerimento è ridurre i “task” a uno o due “thread” al massimo.
Spesso un “task” che archivia solo una casella di posta alla volta si comporta meglio e di conseguenza si generano meno “timeout” di disconnessione.
5) Archiviazione differenziata per le cartelle preferite
Un altro modo per ottimizzare ulteriormente i “task” di archiviazione di MailStore consiste nel focalizzarsi nell’archiviazione di specifiche cartelle presenti all’interno della casella di posta dell’utente.
Per esempio, nel caso si abbia un “task” che sincronizzi l’intera struttura delle cartelle di un utente ogni 15 minuti e contemporaneamente elimini tutti i messaggi di posta elettronica più vecchi di 1 anno, MailStore controllerà ogni cartella alla ricerca di eventuali modifiche e se rileva una modifica, dovrà eseguire lo scaricamento del contenuto della cartella.
Siccome MailStore, se rileva una modifica in una cartella, esegue lo scaricamento del suo contenuto, è possibile ottimizzarlo ulteriormente limitando il “task” di archiviazione ad “elevata frequenza” a sole specifiche cartelle che contengano i messaggi di maggior interesse come potrebbero essere “Posta in arrivo” e “Posta inviata”.
6) Separare il lavoro di “rimozione” dell’email già archiviate dal serve
E’ meglio evitare che MailStore esegua la stessa attività ripetutamente quando non strettamente necessario.
Consigliamo, ad esempio, di separare la sincronizzazione dei contenuti delle caselle di posta dalla procedura di eliminazione delle vecchie email già archiviate del server di posta, creando un “task” separato di rimozione che sia eseguito ogni giorno ma per una sola volta e nel momento ritenuto più opportuno.
Per spiegarci meglio facciamo di seguito un semplice esempio.
Supponiamo di voler impostare delle regole di cancellazione differenziate: da alcune caselle di posta andranno eliminati i messaggi più vecchi di 3 mesi e su altre andranno eliminate quelle più vecchie di un anno.
Invece di eseguire archiviazione e cancellazione in un unico task, in questo caso sarà meglio eseguire queste operazioni separatamente e in momenti diversi.
Per prima cosa andrà creato il profilo per l’archiviazione di tutte le caselle postali. Questo profilo potrebbe essere posto in esecuzione in “modalità automatica” per archiviare i nuovi messaggi di posta in tempi molto brevi.
Successivamente imposteremo un profilo che gestisca solo la rimozione delle email più vecchie di un anno dalle caselle postali.
Dal momento che il primo profilo garantisce già di avere tutte le nuove email archiviate, questo secondo profilo di cancellazione potrà essere eseguito una volta al giorno e nell’orario più favorevole (per esempio di notte).
Il profilo successivo che creeremo gestirà invece la cancellazione di alcune caselle postali dopo 3 mesi. Anche questo secondo profilo di rimozione potrà essere eseguito una volta al giorno e nell’orario più favorevole ma diverso da quello dal secondo “task”.
Fondamentalmente, questi profili di rimozione faranno la stessa cosa fatta del primo profilo di archiviazione creato, ma in più elimineranno dal mail server le email già archiviate da oltre un certo tempo.
Questi due profili di “rimozione” in questo modo non saranno più eseguiti dopo ogni pausa di cinque minuti, ma solo una volta al giorno, o, se lo si riterrà opportuno, con ancora minore frequenza.
Questi suggerimenti sono stati da noi raccolti dalle varie email scambiate con il supporto del produttore in oltre dieci anni di collaborazione.
