OK, I think you're misunderstanding or mis-estimating a few basic concepts here, so in the order I see them in your question, here we go:
(1) Your assertion that Windows makes heavy use of the pagefile even with ample RAM is incorrect. It doesn't.
- The pagefile may stay the same size, but whether it's actually utilized to store anything or not it a whole other matter. Allocation (how much stuff is in it) is also very different from utilization (how heavily/frequently it's used), and just because Windows loads a large amount of memory contents to the page file does not mean they will be heavily used, or even used at all. Virtual memory, or the Windows page file, conceptually is just a place to put data ("stuff") that's not needed urgently enough or frequently enough to be stored in RAM, but is needed more urgently or more frequently than an arbitrary data chunk elsewhere on the hard disk (some random file).
(2) Your idea to solve this non-existent problem with a [very large] RAM disk won't work.
- You could cram a petabyte RAM disk in there, and Windows (and operating systems in general) will still utilize any virtual memory space you allow them for any data it determines ought to be stored in virtual memory, because virtual memory, at a conceptual level is "just" somewhere faster to access than the normal disk, but slower to access than RAM. Since RAM has historically been much more expensive and scarce than disk space, this was (and even still is) a great compromise the keep the costs of computing down - if the data isn't frequently accessed, or expected to be accessed soon, it doesn't need to be on high cost, extremely fast access chips (RAM), so you can put it somewhere cheaper [and thus slower] (a "hard disk") to allow prioritized data to occupy that finite resource.
(3) You are worrying about something totally insignificant to SAN performance.
A SAN is a system of networking and storage that is specifically designed for the express purpose of transferring large amounts of data from computer systems that access them to the disks in your SAN's storage controller. (There are other functions as well, of course, but that's the main one.) There are people whose sole job, and primary function in life is to design these systems to do that. They have put a lot more thought, study scientific methodology and higher math into doing so than any of the rest of us ever will. They do know what they're doing, and they're far better equipped to fuss over those nitty-gritty details than you or I.
Perhaps even more to the point, swapping (transferring to/from virtual memory) memory contents is going to be a minute portion of your SAN bandwidth, unless you have a whole lot of machines doing obscene volumes of swapping, which would be noticeable, in that this level of swapping would render the machine unusable. So unless that's the case in your environment, the relative volume of data transfer to and from the SAN as a result of swapping is insignificant. Your SAN will see the greatest portion of traffic (by a vast, vast margin) from activities more normally associated with accessing the hard disk. These would be things like moving files, saving or changing data, reading and updating the databases, and so on. If there's actually a need to optimize traffic to and from your SAN (and why do you think that - are your system response times actually degraded due to a SAN bandwidth or throughput bottleneck?), there are a very long list of far more important considerations than how much the Windows servers are swapping virtual memory.
(4) Regarding your statement about how Microsoft should get rid of paging...
You mean to say "virtual memory" and not "paging," because paging is not a actually synonym for virtual memory, but is actually a memory management scheme which includes the use of virtual memory.
In either instance, that's not going to happen, won't help... anything... anyway, and is largely irrelevant, because even if Microsoft got rid of virtual memory, most of the world's servers, appliances, and computing devices in general do not run on Microsoft-based operating systems. The majority run *nix based operating system, and other even older operating systems that you'll be even less familiar with than UNIX or Linux.
EDIT:
In response to your comment (@LukePuplett), I'll add the below to my answer as well.
OK, since it seems, after all that, you're still not convinced, and still think Windows paging is degrading SAN performance, let me suggest that you "do the math" on what impact Windows swapping is having on your SAN I/O. You'd do so by:
- Monitoring (via
perfmon or whathave you) on your Windows servers (or at least a decent sample thereof) to determine/estimate how many hard page faults you have. This would be the number of swap events that go to your SAN. Probably will be in, and best to get as, a per second rate. Call this [A].
- Same monitoring with different counters to determine the average size of your page events. Probably will be in
kiloBytes, convert to Bytes (multiply by 1000). Call this [B].
- Compute your theoretical maximum throughput bottleneck of your SAN. This is probably (and certainly most easily to compute) the network speed rating of your SAN switches/fiber, for example, an 8 Gb/s fibre-channel SAN would (or could) have a max theoretical throughput value of 8Gb/s. Since this is in
bit/s, (in this example) and your other values would be in Bytes/s, divide the value by 8. Call this [C].
Take ([A]*[B]*2)/[C] to get the percentage of maximum throughput which your paging data is consuming. (Multiply by 2, as the hard faults only measure data transfer in one direction, and there will usually be, at least in theory, a corresponding data transfer in the other direction too. An instance of moving data from RAM into virtual memory should usually correspond to moving disk-stored data into RAM as well.)
Unless your environment is highly abnormal, this value will the same order of magnitude as one tenth of one percent (0.1%) of your SAN's maximum throughput, based on a my metrics from dozens of different environments over the span of about a decade. As mentioned above, in the original answer text, there are a very long list of other factors (literally a couple dozen discrete configs or factors I could rattle out off the top of my head) that you'd be able get more than a 0.1% "performance" improvement out of your SAN by tuning, if your SAN would actually benefit from performance tuning at all, which is something you've provided absolutely no evidence to suggest.
