Yep, whatever is there isn't needed often - if at all.
Time to name and shame a few processes?
Kevin
VMWare is obviously biggest culprit - all of OOF's servers' RAM is set not to page, along with other VMs that are running (currently, when screenshot taken, 2 Linux, one Windows).
Some pretty big databases live on there (fallback for my brother's shops), and RDBMS do like to hog memory, plus quite a few IIS asp and aspx sites. Some of the apps grab memory for performance reasons.
Most importantly, a fast disk subsystem to page quickly when required.
Thats funny the server we use doesn't hog memory too much. And its performance is fine, the biggest single site glass processor in the UK uses it!
Ah, but you servers most likely are nowhere as busy as this one. Leaving aside the VMs (The OOF VM is fairly busy, the other Linux one is so-so, the Windows VM is incredibly busy), there are a few 'several hundred Mb' databases constantly replicating, and other applications running, including some big asp and .NET apps, many themselves access smaller databases. Then there is the email system, and lets not forget WSUS 3 (itself a server killer). Backup software, as I'm sure you know, can be a resource hog. The offsite FTP backup scripts, and google submission scripts are obviously using server resources. Keeping that lot running smoothly does need a fair amount of resources. Remember, the old server was on its knees, due to being only a 2.6GHz (I think) P4, 2G RAM.
Yes, SQL Server does try to claim all available memory (like all decent RDBMS), whether needed or not, as query memory. Generally part of the reason why SQL and Oracle are generally the quickest on Windows servers. But it is equally willing to give up when not required. Its actually using a measly 35Mb at the moment, as a load of processes kicked off at midnight, and the backups have kicked in as well.
Author
Topic: One for the IT Techies... (Read 3117 times)