We're a small office with 2 SQL Server instances on a Win 2003 box running inside VMWare. One instance if for the company's Backup Exec. The other instance holds one production database that is 6 GB at present. HyperBac is compressing backups on this second instance. We are using HyperBac primarily to conserve drive space.
In response to my posts regarding High Memory Usage, Jeffery Aven at RedGate suggested that we change two settings in our hyperbac.conf file as follows:
This restricts the compression buffers in the service however Jeffery warns that doing so can be detrimental to performance in some cases.
We do a full backup once per day. Differential backups occur every 2 hours and log backups every 15 minutes from from 9 am to 9 pm. Here are some comparisons before and after the .conf update.
Our 5:00 pm differential backup durations were:
8/03 00:19 (19 seconds)
8/10 00:19 (after the .conf update)
The 1st log backup after our nightly processes had the following durations:
8/03 01:06 (1 minutes, 6 seconds)
8/10 01:06 (after the .conf update)
The resulting log file sizes ranged from 1,048,034 KB to 1,064,157 KB during this period.
The primary difference that we are seeing with memory usage since the .conf change is the starting value. Prior to the change the first full backup would ramp up the memory value to the high 400,000 Ks and begin accumulating at 12 K per minute from there. Since the change it appears that the first full backup resulted in a memory value in the high 100,000 K's and accumulation began from this lower starting value. Seveny four hours later it was at 247,296 K, up 700 K per hour. So we could be back up to the 500,000 K's by the end of August.
However, as Jeffery Aven has pointed out me several times, the Memory attributed to HyperBacSrv and being displayed in Task Manager is virtual memory and it will be released if requested by any other program. So there shouldn't be a problem with any amount of memory claimed by HyperBacSvr, even 1,000,000 K.
If the memory claimed by HyperBacSrv is required by another program we should see HyperBacSrv's displayed allocation in Task Manager knocked back and accumulating at 700 K per hour from that lower point. Eventually the overall system will achieve a dynamic balance. We will always see HyperBacSrv's Memory in Task Manager increasing by 700 K per hour.
I asked Jeffery: "do you think that we've really accomplished anything of technical merit with our .conf change? Would HyperBacSrv's performance be more efficient and reliable under the original settings?"
After reviewing some of our system data he responded: "You are correct in that this should not be an issue with the allocation. Sometimes the value in task manager has a sticker shock to it, but it is really only a constraint if you do not have a large enough page file. The virtual memory is allocated in anticipation of a HyperBac operation or in the case of the initial rise you saw, a reaction to an operation. You should be OK with the new settings. The main bellwether should be system performance overall (backup, restore performance relative to native, query throughput and application responsiveness). If these drop off then changes should be made."
I'll report again to the forum when we appear to reach that dynamic balance.