msftesql.exe high CPU usage, exchange 2007 sp3 rollup 10

We are running Exchange 2007 SP3 Rollup 10 on Server 2003 x64. From time to time the msftesql.exe is running very high CPU usage.  From all the looking I've done including Microsoft, its usually recommended to patch to SP3 rollup 2 (I think).  Since we're on the RU 10, we should be covered.  What else can I do?
rivkamakAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AmitIT ArchitectCommented:
I remember there is a patch for this issue, unable to recall it. Let me check, if i can find the patch number.
0
rivkamakAuthor Commented:
were you able to find the patch number?
0
AmitIT ArchitectCommented:
Unable to recall. It was few years back, i applied. If you have MS support open us a case, then will give you the exact number.
0
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

rivkamakAuthor Commented:
but like I said above, I'm currently running the latest rollup which would include all previous patches so.......
0
rivkamakAuthor Commented:
I just did a restart on the MS Exchange search indexer service and that seemed to do the trick at this point, I guess I'll see how long it lasts.
0
AmitIT ArchitectCommented:
Ok, if you same issue next time, use RAMMAP tool and check where you have maximum memory leakage issue.
0
rivkamakAuthor Commented:
Memory was always normal, it was only CPU that was getting hammered.
0
AmitIT ArchitectCommented:
My bad i forget that, also is this a part of CCR cluster or a standalone.
0
rivkamakAuthor Commented:
stand alone
0
AmitIT ArchitectCommented:
how many CPU's you have in total on this server? Is this a VM?
0
rivkamakAuthor Commented:
Its a VM, which I configured with 1 CPU
0
AmitIT ArchitectCommented:
That is pretty low. I suggest you to add one more CPU.
0
rivkamakAuthor Commented:
From my researching, adding additional CPU in a VM environment doesn't help things it actually can decrease performance, due to "CPU Waiting Time".

See:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005362
0
AmitIT ArchitectCommented:
Then you can wait and watch.
0
rivkamakAuthor Commented:
CPU is back to 100%.  I've read that this has to do with the index with is why I restarted that service.  I read about rebuilding the index, are you familiar with this?  ever done it?
0
rivkamakAuthor Commented:
It seems for me that restarting the service did the trick
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AmitIT ArchitectCommented:
This is not the solution, it will come back again.
0
rivkamakAuthor Commented:
You're saying it has nothing to do with the index or that just restarting the service is not the solution?
0
rivkamakAuthor Commented:
The other poster didn't offer any real suggestions.  my own suggestion worked.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.