James is correct here and I misunderstood what people were saying, mainly because people always assume that SQL has a memory leak. Generally, the running of SQL will use nearly the same amount of memory, but you will notice some memory going from 0 to 1GB. Many would consider that a "memory leak" which is not correct. It doesn't leak memory. Many 32-bit OS with 4GB of memory which then translates to 3.2GB of useable memory will crash or become very slow once SQL grabs the memory it wants. If SQL is allowed to use 10GB of memory or some can get 64PBs of memory, it will try to use all that memory. The settings can be controlled.
The aforementioned OS has 3.2GBs of usable memory. Then SQL takes an 1GB of memory. Subtract all of the memory being used, and you run out of memory and your computers run VERY slowly. When you reboot the server, you may think that was the reason, but basically SQL releases all the stored memory. That is NOT a good thing. As James said, that is cache or what some would call pages. Every time you query information from AC's database, SQL says correctly, "This information is likely to be asked for again. Let's store it in memory as a page." The next time you use that query, SQL gets the info from memory and not from the database on the hard drive. Eventually, that page gets copied over after time as it has not been used.
James knows more about this than I, but it would be nice if the cache could be saved during reboots.
I guess it is the definition of the word hog. Intensive programs such as SQL or Exchange are going to use more RAM than other programs. If you have enough RAM which is why you need 64-bit OS, then it doesn't matter. If you install 64 GB of RAM it is of little or no consequence if SQL takes 3.5 GB of that. If in the end, you need 30 GBs of RAM, you still have 34 GBs of RAM left.
It should also be asked here if everyone is configuring their page files to work effectively. These are not the same as the page files contained in cache with SQL.
