VAULT server causing huge movements of DATA on the C drive

[Nick_the_contra]

Our vault server is shifting about 100 gig a day on the C drive.  There are no vaults or any applications using data on the C drive apart from MSMQ which has its storage there.  MSMQ is running in workgroup mode.

The C drive goes from 10 Gig to 12 Gig then back to 10 Gig again every few minutes and as we have replication services running at block level to our DR site, this is taking all the bandwidth !!

I cannot find what is causing this... But I have confirmed it with perfmon that it is true, and our DR company agree that this is taxing our link.  I thought MSMQ kep the messages in memory , and didnt use the C:\WINNT\system32\msmq\storage directory unless it was for backup????

There is 2.37 gig in the storage directory - but non of the files have changed for about a year ? I understand that if you go over the storage limit, the messages stop working - but our Vault is working fine? This machine is running 2000 server with Vault (how do I find the version??) and has 4 gigs of RAM (MSMQ message limits are based on RAM ?)

Could the MSMQ service be causing these huge data movements on the C Drive?

If I move using registry (MSMQ workgroup mode must use registry) the storage container to another drive do you think this will fix it?

[Micah_Wyenn]

Try moving windows temp to another drive to see if the traffic moves to that drive.  If so, you know the culprit.  Why it's thrashing so hard requires further investigation, but at least you'd have a place to start looking.

micah

[Michael_Bilsbor]

Hi,

My money is certainly on it being MSMQ.  Items on MSMQ are in memory but also on disk (MSMQ has different modes, ev uses transactional mode so that if you crash the server the items remain on the queues) and EV can carry on from where it left off.  So move MSMQ (which isn't recommended on the C: drive anyhow for performance reasons).

Whilst the TEMP location is a possibility we normally only use that if processing larger items (so as to reduce memory usage) but given the customers amount of data they are mentioning it sounds more like MSMQ.

However at the end of the day, both locations don't add value in terms of being available at the DR site and so I would consider not replicating the TEMP location as well.

[mike_niccum]

Can you explain why MSMQ does not add value at the DR site?  I tend to agree with you but I want to make sure your reasoning is the same as mine.

I currently have MSMQ on a local drive and expect pending archive messages in the Journal Mailbox to be re-processed after a timeout once the failover occurs.  This is in reference to Journaling. 

Thanks,

Mike Niccum

[Nick_the_contra]

OK moved the message queues - not the issue.

What a mission moving these in version 2.0 !!

Moved the TMP directory off the C, to the SAN - FIXED !

This was causing the issue. - Restarted the Server, and the vault then spent 5 minutes creating about 12000 files in the new location of the TMP directory - 1.3 gigs.

Is was this 1.3 gig of 12000 files that was causing the fluctuation, but why only in the last few weeks??

What I want to know is what the TMP ddirectory is used for,

 as all the files in it  start with

EV_CVT_TMPx

ExchangePerflog1354253463565474.dat - 

DFB1FD.dat etc

What does vault do here? as the whole TMP was filled up with the 1.3 gigs, before We could un-vault emails.

Thankyou for all of your help.

[Michael_Bilsbor]

These are what's called memory mapped files.  So they are normally around 5mb or so but you shouldn't have many of them.

EV_CVT_TMPx

These files are ones Outlook leaves around which we have seen, you may want to consider some kind of tidy up process when ev is shutdown or speak to Microsoft about them.

ExchangePerflog1354253463565474.dat - 

These ones don't sound like EV files.

DFB1FD.dat etc