just my two cents on the subject.
Rule number one of being a DBA. DON'T run your programmers application on the SQL server. The SQL server should be that and only that, a SQL server. If you separate the SQL server and the app server (dot not server) you will find where the memory issues are. If you need to reboot the web/dot net server and not the SQL server you can see where the issue is.
If your application has memory leaks, your application will take the memory away from the SQL server requiring reboots. If you isolate the code its easier to find the problem source.
Generally SQL does a fairly good job of managing memory. I don't totally agree with previous posts about dynamic memory management. If I have three gigs available to a SQL server I give two if it minimum to the SQL server. This way the OS always has a gig, and SQL always has two then they can manage their allotted memory without constant swapping back and forth. MS is supposed to write code that manages memory and allows swapping but I find I can't trust it. Also the Win OS takes for ever and a day to finally release memory when your done with it.
There is overhead in memory management if you keep giving and taking away memory to the SQL server. You will see better performance if this overhead is removed by fixing the amount of memory allocated to the SQL server.
Lets hope we never work on the same shop where you want to install your applications on the same box as MY SQL server. Heads will roll!!! Memory leaking web code or dot not code should not be allowed to pollute a clean SQL environment.
MS has historically poor memory management routines going back to the dos days. So my suggestion don't trust their memory management code any more that you have to.
Hope this helps...
The anal DBA,
Rob
|
