grp file (de)fragmentation
Idea shared by markus - November 7, 2016 at 2:26 AM
Proposed
the daily data amount for each users mailbox (+ new - deleted messages) are stored in grp files for each users mailbox and subfolders.
 
So that files on some days can become quite large. For example after imports from external PST files, extraordinary activity (bulk mailing) or migrations from other mailservers. 
And they also can stay locked from user activity (pop3 imap EWS access, ...) so that normal defragmentation will continuously time out on this files. This results in really long running but quite ineffective defrag tasks.
 
Would it be an idea to provide an API function that delocks a certain group file (or mailbox) ?
This way defragmentation could by analyzed on a running server, the worst performance killers can be picked out and then delock+defraged in a short timeframe:
1.) analyze and rank top defraged files
2.) smartermail api => delock one file
3.) immediately defrag that file with contig.exe
 
For sure it wouldn't work without sending some unexpected "connection terminated" to the locking client. But as this can be timed on out of office times and happens only for that particular client, the defrag process should be finished very fast and the same client can reconnect immediately - now with faster reaction.

Reply to Thread