Poor hardware on Exchange at the moment - Mails extrem slow waiting in mapidelivery queue


our customer changed all of his domains and now he uses his Exchange 2007 to manage all the mails of those domains. This machine is very poor on RAM (only 4GB). We already bought 32GB. But the ram is still on his way... so we have to handle this on the poor machine.

The server is a little slower, but everything he is making after some seconds. Only the incoming mails are stuck in MapiDelivery-queue. After some minutes 1-2 mails are delivered. But with over 800 in queue and more than 4000 on the webserver still waiting this would take weeks...
What can i do to get this faster ?

Thanks !
Who is Participating?
Malli BoppeConnect With a Mentor Commented:
I don't think a page file of 20Gb was good idea leave it 6 or  8 GB. Reboot the server and see if it makes any difference.
Also check  for any hardware failures and event viewer. As said above there could be memory leak. Even with 4 GB memory exchange should be able to run.
Mohammed KhawajaConnect With a Mentor Manager - Infrastructure:  Information TechnologyCommented:
What is the pagefile size set to?  Could you try it with pagefile set to 16 GB or 20 GB?  Also note that not only memory makes a difference but you also need fast disks,
MysidiaConnect With a Mentor Commented:
How many active mailboxes;   what is the average mailbox size; how many items?

It is not entirely out of the question to run an Exchange 2007 server with 4GB of RAM;   however,   it can handle about  30  mailboxes OK,  at  a maximum of approximately 200MB
per mailbox;  although you will be well below the recommended values.

You might expand the pagefile; and shutdown  RPC/Mapi (Outlook access) IIS, Outlook Web Access, POP, and IMAP related roles on the server,  temporarily,  pending delivery,  so  no clients can connect,  and you can observe delivery;  with all system resources being used (to the extent possible) for getting items in the queue into the mailbox database.

Make sure not to leave the Exchange management console GUI open;  or other remote login sessions open, as MMC and other graphical management tools for Exchange produce significant resource consumption;    Suggest monitoring queue activity   using the powershell  (Exchange Management Shell).

The storage I/O capacity is extremely important,  and adequate CPU is important as well,  not just the RAM.

Some examples of  major  mistakes,  some people make  with  storage design:

o  Using RAID 5   instead of RAID10.
o  Using a storage controller  that doesn't provide an adequate amount of read and write cache.
o  Using a small number of spindles.
o  Using a storage system with  7200 RPM SATA disk drives,   instead of    10,000RPM  SFF SAS  or FC.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

loosainAuthor Commented:
We have 30 Mailboxes with tons of mails (DB ist 50GB). The harddisk is all the time writing on the mailbox database.edb .
Pagefile size is set to 20GB.
I have closed IIS and console.
loosainAuthor Commented:
ok, thanks so far.
I figured out, that the problem is a very big (15GB) mail.que.
I repaired and defraged it with eseutil. Now it is 11GB for 919 mails.
Still very slow.
Has someone any idea, what to do to get those 919 Mails out of this queue?
Malli BoppeCommented:
why you don't the emails to be processed
loosainAuthor Commented:
After stopping, defraging and restarting the mailqueue 4-5 times, now all the mails are delivered. After this i started with a new small one to get most speed out of it...
thanks for helping.
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.

All Courses

From novice to tech pro — start learning today.