Every so often there is a question: "Should we run file-level defragmentation software on Exchange servers?" Usually, this comes from confusion that file system defragmentation actually helps Exc...
Updated Jul 01, 2019
Version 2.0
Blog Post
Interesting observation.
Based on my own experiences I’ve experienced quite a noticeable increase in performance after running regular file-level defrag. This is done off peak hours of course and only after backup as run its due course.
Further more I’ve been in disaster recovery situations where we had Eseutil taking 7-8 hours before completing even one pass at a 9Gb badly corrupted store. The reason we found out was 30’000+ fragments at the file level. After we ran defrag a few rounds hours spent with Eseutil decreased to a “mere” 4-5. Obviously the store was in deep trouble regardless.
Since Exchange accesses the stores in a random fashion it makes sense that defrag should not make out to a huge difference, but I personal experience is that with regular file-level defrag, you will not really notice the I/O hit. For a system that is continuously busy 24/7 I agree that this might be a problem.
Based on my own experiences I’ve experienced quite a noticeable increase in performance after running regular file-level defrag. This is done off peak hours of course and only after backup as run its due course.
Further more I’ve been in disaster recovery situations where we had Eseutil taking 7-8 hours before completing even one pass at a 9Gb badly corrupted store. The reason we found out was 30’000+ fragments at the file level. After we ran defrag a few rounds hours spent with Eseutil decreased to a “mere” 4-5. Obviously the store was in deep trouble regardless.
Since Exchange accesses the stores in a random fashion it makes sense that defrag should not make out to a huge difference, but I personal experience is that with regular file-level defrag, you will not really notice the I/O hit. For a system that is continuously busy 24/7 I agree that this might be a problem.