Exchange 2010 journaling performace

Hmmm, when that happens, can you have a look at things like memory usage and such on the processes before you restart?

I remember working with AndrewB and he discovered that the MonitoringMiddleTier had a slow leak and journaling was performing painfully slow, but when restarting the Admin Service, it killed and restarted the monitoringmiddletier and suddenly everything was faster again

I'm keeping an eye on the MonitoringMiddleTier and the CPU is zero and the memory is 11-12MB - doesn't really seem to be an issue.

I opened a case with our VAR on Friday (required before being escalated to Symantec). They had me re-crate the journal task on Friday afternoon, but no luck. The current queues in my two journal mailboxes on E2010 are 92K and 130K while the two on E2K7 are both around 3200. 99% of the messages are in the (EnterpriseVault PendingArchive Part) queue - so EV has started to process them. Based on my limited knowledge of this product, the root cause seems to be with either EV or MSMQ.

Is there any performance tweaking that can be done for MSMQ or is it pretty much all defaults? Whem messages are moved to the J2 queue, is that an SMTP transfer or a file copy?

So an item goes from IPM.Note to IPM.Note.EnterpriseVault.PendingArchive.Part item
After 5 minute elapses and it no longer needs to wait for a journal report, it changes it to a Pending message class and posts to J2

The Journal task then connects and takes the item via MAPI and places the actual message in to Storage Archive in 1.5MB chunks (so a 9MB message, you'd expect to to see Six seperate messages in Storage Archive queue)

Then the EV StorageArchive.exe would pick up that item from Storage Archive, and then create the DVS files and check to see if the item has any shareable parts and whether its already shared, and adds the relevant details to the database.... after storage has been succesful, it then passes a pointer to the item in to the J1 queue, and then the Journaling Task picks that up and finds the message in the mailbox and performs a hard delete against the item.

So if you see items just stuck waiting in the .PART section, then it wouldn't even have reached MSMQ at this point, unless it physically cannot post to the MSMQ, usually you see that with the MSMQ 1GB quota being breached, and upping to 8GB resolves it (8GB used to the be the default, but it was bought down by MS to 1GB)

Sometimes people enable Journaling on MSMQ, meaning every copy of a message that goes in to an MSMQ has a copy made, and that counts towards quota, its useful for troubleshooting sometimes, but people forget to disable it, and then it fills up the quota and nothing more can be done.

There are also throttling mechanisms that EV uses, for instance if the Storage Archive queue gets really backed up, then it won't post until it clears down, in order to avoid making whatever situation worse.

Major slow downs like this though, i've sometimes seen by different filters.
So i know of one company that uses Orchestria as a filter, and for whatever reason, DL Expansion takes 30 seconds, so EV just sits waiting for a response from Orchestria to perform its custom tagging and what not before it can move on to the next item.

Compliance Accelerator also installs a custom filter for journaling as well for random sampling. and you may have your own selective journaling or custom filter set in the registry for different purposes (maybe deleting items from certain users, or adding custom index properties based on key words etc)

Interesting, the Balanced should have just been about shutting down disks after 15 mins idle and such and shouldn't have had any impact to the best of my knowledge, but can't argue with the increase in performance!

Glad you have it sorted out.