• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 494
  • Last Modified:

Partition resizing


I have a problem of space on C:\ on the exchange server. Basically server has 3 primary partitions as the below.

C:\ - OS (Primary Partition - 70GB)
D:\ - Exchange 2010 database files (Primary Partition - 200GB)
E:\  - Exchange 2010 log files (Primary Partition - 200GB)

Recently I have realised that C:\ drive only has free space of 2GB and when I investigated the problem I have understand that the size of page.sys file is about 35GB. I have ample free space on both D: and E: drives. Now my question is, can I shrink E: drive and when I do so can I extend the C: drive after? Would this be affected the functioning of Exchange server in some way?

Thanks in advance.
4 Solutions
Simon Butler (Sembee)ConsultantCommented:
If Windows will allow to change the drive size, then there is nothing in the way and Exchange will continue to operate fine.
However another option would be to just move the pagefile. That will require a reboot, but would release the space and is risk free.

SHALINDRAAuthor Commented:
Hi Simon,

Thanks for your reply. Is there any real advantage to have the page file in OS partition?

Seth SimmonsSr. Systems AdministratorCommented:
unfortunately C is too small and E is probably too big
how many mailboxes do you have?

i normally wouldn't recommend, but if it's not too much activity on the box, probably best to move the pagefile to E

if the volumes are on different disks or raid arrays then no, you can't shrink one to extend the other
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

I know this is outside of the scope of your question but how much memory is in your server and is dedicated to Exchange only?

I agree with the previous posters that moving the page file is the simple answer but you may want to limit the page file size as an alternative. If you have sufficient physical memory you may benefit from limiting the page file size. 2x the amount of physical memory is overkill when you have sufficient physical memory. Exchange will eat up as much memory as you allow it to. When the page file is set to 'system managed' or manually set to 2x physical, store.exe will eventually grow out the page file to its max, SQL has that same lovely attribute.

Relocating the page file to a different drive than the system drive is the recommended configuration for performance purposes, but since your server doesn't have a volume that just hosts data shares or some other low I/O load I would try to keep it on the c: drive and leave those dedicated Exchange drives alone.

My recommendation:

16gb Physical Memory-- Set page file start to 6gb - 8gb max size
24gb Physical Memory-- Set page file start to 8gb - 12gb max size
32gb Physical Memory-- Set page file start to 12gb - 16gb max size

No matter the page file size, store.exe will fill it up as it would cache the entire database in memory eventually if you let it. Your performance will likely go up as the page file size goes down as well.

Microsoft does acknowledge this as an acceptable practice in servers with a lot of physical memory.
David Johnson, CD, MVPOwnerCommented:
If C,D,E are on the same physical hard disk then moving the pagefile from C to E will free up space on C but it will cause a slowdown as there will be excessive head seeks every time the pagefile is accessed.
SHALINDRAAuthor Commented:

Thanks for all of your replies. All C:, D: and E: partitions are on a RAID 5 array built with 3 SAS drives. So according to seth2740, I believe the shrink and extend is not a possibility at all and it seems to be the only solutions are limit the pagefile or move it to E: drive, is that correct?

Also will the server get slower response if I moved the page file to E: drive as it is in the same RAID 5 array?

Thanks in advance
David Johnson, CD, MVPOwnerCommented:
The seek times will still be huge, use the Microsoft debugger xperf to confirm.  These increases in seek times may not be a problem, just something to consider.
SHALINDRAAuthor Commented:
Thanks everyone
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now