Exchange 2013 running out of space.
Hello!
We have a small DAG configuration based around Exchange 2013 CU7, on top of Server 2012. Our OS drive was pretty full since the get go, but we are getting close to the 90% full mark (on a 135GB disk). When looking at the server the main culprits appear to be:
-DailyPerformanceLogs folder - about 5.5GBs
-Mail.que file - about 12GBs
-V15/Logging folder - around 29GBs
-Paging file - around 13GBs (auto-managed, one location, based on 96GBs RAM, normal utilization about 50%
What are the specific suggestions for dealing with the situation? Some of our ideas were:
We have a secondary location which could be used to store the V15/Logging folder - I assume that "junctions" program might need to be used? Is there a walk-through for accomplishing this? Other option would be to run a PowerShell script deleting anything older in there than 14 days. Are these logs used ONLY for troubleshooting with MS, and could this be a safe thing to do? I assume that there is no global setting to change the retention here from 30 days down to 14 (I think the default is 30 days)?
Also, what would be a procedure to follow for replacing the mail.que file with a fresh one - I assume that is a supported way to "shrink" that file.
Paging file - obviously the old rule of setting up the 1.5 times the amount of RAM is not working in the world of loaded servers and virtual environments too well - is there a risk with lowering that value to 4-8GBs on such server?
Thank you!
We have a small DAG configuration based around Exchange 2013 CU7, on top of Server 2012. Our OS drive was pretty full since the get go, but we are getting close to the 90% full mark (on a 135GB disk). When looking at the server the main culprits appear to be:
-DailyPerformanceLogs folder - about 5.5GBs
-Mail.que file - about 12GBs
-V15/Logging folder - around 29GBs
-Paging file - around 13GBs (auto-managed, one location, based on 96GBs RAM, normal utilization about 50%
What are the specific suggestions for dealing with the situation? Some of our ideas were:
We have a secondary location which could be used to store the V15/Logging folder - I assume that "junctions" program might need to be used? Is there a walk-through for accomplishing this? Other option would be to run a PowerShell script deleting anything older in there than 14 days. Are these logs used ONLY for troubleshooting with MS, and could this be a safe thing to do? I assume that there is no global setting to change the retention here from 30 days down to 14 (I think the default is 30 days)?
Also, what would be a procedure to follow for replacing the mail.que file with a fresh one - I assume that is a supported way to "shrink" that file.
Paging file - obviously the old rule of setting up the 1.5 times the amount of RAM is not working in the world of loaded servers and virtual environments too well - is there a risk with lowering that value to 4-8GBs on such server?
Thank you!
@Will,
The RAMx1.5 is pretty old recommendation actually, and although I have been using it for a long time we actually got into a debate about it at work and well.. they were right. Here is the latest guidance, which is even more confusing: http://support.microsoft.com/kb/2860880
Basically I do RAM + 512MB. This is enough for the system to still function *yet* allow for a full memory dump to take place.
@ rr2r
Is this physical or virtual? Either or I say attach another virtual disk (or pair of HDD for RAID1) and move some files off:
- Move that page file off to the new drive. Older article, but same concept
- Recreating the mail.que file will reduce the size, I believe the default size is around 100MB or something. Bloat can cause further issues down the road (along with consuming space) but here are directions for that.
- Depending on the logs in the V15 folder, I typically once a month have one of the admins clean it up (except for the last week). Stuff like transport logs you do not want to touch, but the IIS logs can go along with some of the other logs found within there
If you need further help feel free to drop a note below.
The RAMx1.5 is pretty old recommendation actually, and although I have been using it for a long time we actually got into a debate about it at work and well.. they were right. Here is the latest guidance, which is even more confusing: http://support.microsoft.com/kb/2860880
Basically I do RAM + 512MB. This is enough for the system to still function *yet* allow for a full memory dump to take place.
@ rr2r
Is this physical or virtual? Either or I say attach another virtual disk (or pair of HDD for RAID1) and move some files off:
- Move that page file off to the new drive. Older article, but same concept
- Recreating the mail.que file will reduce the size, I believe the default size is around 100MB or something. Bloat can cause further issues down the road (along with consuming space) but here are directions for that.
- Depending on the logs in the V15 folder, I typically once a month have one of the admins clean it up (except for the last week). Stuff like transport logs you do not want to touch, but the IIS logs can go along with some of the other logs found within there
If you need further help feel free to drop a note below.
ASKER
@Will
Thank you for your comments. I perhaps was not clear in the logs - we are only keeping the default "health and system" logs on the C Drive. The DB files/logs are on a separate drive already.
RAM - so far the only reason that I have seen to have more Paging space than RAM was to enable to save full memory dumps in case of a crash. I have not ever seen a need to review such dump yet, therefore I question the Page Size > RAM mantra... My typical utilization is about 50% of memory.
Thank you for your comments. I perhaps was not clear in the logs - we are only keeping the default "health and system" logs on the C Drive. The DB files/logs are on a separate drive already.
RAM - so far the only reason that I have seen to have more Paging space than RAM was to enable to save full memory dumps in case of a crash. I have not ever seen a need to review such dump yet, therefore I question the Page Size > RAM mantra... My typical utilization is about 50% of memory.
ASKER
@Adam
Thank you for your post. As far as the logs inside the "V15/Logging" folder those seem to be all health/service related logs used for troubleshooting issues. None of the logs related to the flow of messages should be there. Do you do a blanket "wipe everything that is 7+ days old" PoweShell script or are you more selective?
Thank you for your post. As far as the logs inside the "V15/Logging" folder those seem to be all health/service related logs used for troubleshooting issues. None of the logs related to the flow of messages should be there. Do you do a blanket "wipe everything that is 7+ days old" PoweShell script or are you more selective?
ASKER
Moved paging file away - have more breathing room for some time... Will not be able to try anything more till next week though. Thanks!
ASKER
Hello Adam - are you able to comment on my previous question?
When it comes to blowing away mail, you've got to be careful of regulation compliance for your industry. I recommend using a larger timeframe than 7 days ... maybe a couple years.
How come you have a disk that small. If its in a SAN or virtual OK, but then you should be able to grow the drive.
if you have partitioned a drive and what you really mean is that the "C" partition is full then move things around to make "C" bigger.
If you have DB or LOGS on the SAME physical drive then partitioning degrades performance as it ensures the heads are always moving from the front of the disk where the OS and Swap file is, to the back of the disk where the Database and/or logs are.
Server 2008 will support re-sizing "C" but you might need to temporarily remove the other partitions to do it.
if you have partitioned a drive and what you really mean is that the "C" partition is full then move things around to make "C" bigger.
If you have DB or LOGS on the SAME physical drive then partitioning degrades performance as it ensures the heads are always moving from the front of the disk where the OS and Swap file is, to the back of the disk where the Database and/or logs are.
Server 2008 will support re-sizing "C" but you might need to temporarily remove the other partitions to do it.
Be aware that clearing messages inside your store will not regain disk space. The store file will remain the same size until an offline defrag is completed. Not - you cannot do an offline defrag if you don't have sufficient disk space to hold the original store and the defragmented store.
ASKER
Thank you for the responses!
@Delphineous
This is a retail shop so I am not sure that we would have specific requirements beyond what is imposed internally. So far we have no limits on mailbox size and we don't delete anything. Not my choice...
@Dave
This is a physical server and we have no way to add drives. The DBs/LOGs are using separate drives with loads of space so there is no issues there. We are really hoping to find out if we can deal in any way with the two objects now:
-Mail.que file - about 12GBs - any sensible way to wipe that file and have Exchange recreate it?
-[...]/V15/Logging folder - around 29GBs - is there a way to limit the time the logs sit there to a week lets say?
Thanks!
@Delphineous
This is a retail shop so I am not sure that we would have specific requirements beyond what is imposed internally. So far we have no limits on mailbox size and we don't delete anything. Not my choice...
@Dave
This is a physical server and we have no way to add drives. The DBs/LOGs are using separate drives with loads of space so there is no issues there. We are really hoping to find out if we can deal in any way with the two objects now:
-Mail.que file - about 12GBs - any sensible way to wipe that file and have Exchange recreate it?
-[...]/V15/Logging folder - around 29GBs - is there a way to limit the time the logs sit there to a week lets say?
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@Dave
Thank you - I will plan to schedule some time later this week to perform this procedure. If that works I will accept your answer as a solution :)
Thank you - I will plan to schedule some time later this week to perform this procedure. If that works I will accept your answer as a solution :)
ASKER
Thank you!
I would personally not have your database logs on the c drive. I would be moving this to a drive specific for logs. You can use powershell to accomplish this respectively.
http://msexchangeguru.com/2014/11/20/move-db-logs-e2013/
Moving the Paging file to another drive boots performance and would be recommended. Best practice is always RAM Sizex1.5 but in some scenarios that does not really work. I have seen environments with custom settings with the page file having less then half of the RAM (RAM=32GB,Page= 16GB) and have had no issues. Now you need to be cognicent of where you RAM is setting at. If you are utilizing 90% or more of physical memory i would not use this approach.
Having said that if you use a lower then recommended RAM you do risk the chance of your machine crashing is RAM comsumtion is high.
Will.