Problem with Veritas Backup Executive V9.1 (696590036026) for PC

Store.exe High Memory Utilization

Hope someone can shed some light. Need to resolve an issue with a SBS 2000 running Exchange. Over the last week, the store.exe has been taking up over 3/4 of the memory available on the server, resulting in client access being extremely slow during login and accessing data files etc.. The dual processors are no being affected as CPU usgae is below 10%. Rebooted the server a couple of times, freeing up to 600MB but over night, store.exe takes up to 750MB away from the server. Available memory is under 50MB thus bringing the LAN to a grinding halt. I have applied [url=http://support.microsoft.com/default.aspx?scid=kb;en-us;322125]http://support.microsoft.com/d efault.aspx?scid=kb;en-us;3221 25[/url] But no success. Server has 1GB, running Symantec AntiVirus Corprate ED 7.5x and Veritas SBS v9.1 Build 4691.1

Posted by avatar on Aug 10, 2005

    • By avatarhioctaine Feb 24, 2009
    • Hi i have the same problem win2003 SBS with Symantec corp av and store takes up loads of memory usage and slows everything down and if you reboot all is fine for a few days- week

Solutions (5)

Best Solution

No luck with AV, overnight process store.exe peaked at
740MB and did not release memory until the server was
rebooted.

During the day store.exe 9-6pm eat about 40MB. Overnight
there is a service / applications that must trigger the
memory leak for store.exe to peak at 740MB and will not
release.

Anti Virus was disabled, only Veritas is running overnight.

Any one any ideas, other than possibly replacing the
memory?

problems, especially if

The best thing for you to get *conclusive* proof of what's going on is to
open a ticket with Microsoft Product Support Services.  They'll get process
dumps of store.exe to find exactly what's causing the spikage and hang.

Regards,
Colby

--
Please do not send e-mail directly to this alias.  This alias is for
newsgroup purposes only.

This posting is provided "AS IS" with no warranties, and confers no rights.

I have been doing some testing to conclusively find what is triggering the
memory leak to store.exe which it does not relinquish.

1. Symantec Anti-virus diasbled only store.exe peaked -740MB.
2. Symantec Anti-virus & Veritas Back-Up Exec disabled, Information Store
maintainence between 1:00am-5:00am Store.exe peaks to 630MB.
3. Symantec Anti-virus & Information Store maintainence disabled, enabled
Veritas store.exe peaked 340MB
4. Information Store maintainence & Veritas Back-Up Exec disabled, Symantec
enabled store.exe peaked 64MB

Conclusion is that any process directly affecting store.exe such as Veritas
backing-up the Information Store / mailboxes and the Information Store
maintainence will attribute to store.exe peaking at high memory levels but
not relinquishing the memory afterwards.

The only way I have been able to get around this issue is to re-boot the
server every morning.

I see this as a software fault as I have also replaced the memory on the
server.

Is there anyone how could offer me conclusive advise on fixing this problem,
as most people are only dancing around the issue, which is by not doubt
reading on other forums and newsgroups a major issue at hand.

DBA is the algorithm that determines how large the database cache
should be. The cache should be as large as possible without making the
machine page to death. It generally works quite well. But it's not
perfect.

You're running Exchange 2000 as part of SBS 2000. That version had
some known problems with:
-Windows 2000 uniprocessor
-IIRC, Large file caches

You mention 'dual processors', so it's probably not the first problem.

The large file cache can be seen with taskmgr as 'System Cache' (I
think that's what it's called on Win2000 --- I don't have a Win2000
machine here to confirm/deny).

Why is the file cache large? Sometimes it happens if you're running it
as a file server. If you're using it as a file server, is it possible
to offload that onto a different machine?

BTW, you can just stop&restart the store service, you shouldn't need
to reboot.

Exchange 2003 has a better algorithm for determining the cache size,
although that doesn't help you much, since you're not using it.

-martin

Boring-but-necessary-disclaime­r: This posting is provided "AS IS" with
no warranties, and confers no rights.

In article ,
Colby Holland [MSFT] wrote:

Test your server with AV completely out of the picture and see if that
helps.  AV has been known to cause those sorts of problems, especially if
you're scanning Exchange drives, the M drive, etc.

C

--
Please do not send e-mail directly to this alias.  This alias is for
newsgroup purposes only.

This posting is provided "AS IS" with no warranties, and confers no rights.

Add Your Solution

See all Veritas Backup Executive V9.1 (696590036026) for Problems