You should really tune for PERFORMANCE, not for magic numbers.
Zero paging file (swap) utilization is a nice goal if you can attain it, but if you have sufficient RAM for all of SQL server's needs and you are not experiencing a performance problem you probably don't need to "tune" anything. Having some data sitting in the paging file which is never going to be asked for doesn't hurt performance.
If you want to concentrate on numbers though I would concentrate more on
Memory\Available Bytes (make sure there's always a healthy amount available, where "healthy" is defined by your use case) and
Memory\Pages/sec (which should be zero or close to it, indicating that what's sitting in swap is not being actively recalled to RAM).
Remember that modern operating systems will often evict data that has never been requested from RAM, placing it in the paging file (swap space) preemptively while the system is idle so that there is more RAM available and the system doesn't have to take the performance hit of shuffling stuff to disk if it needs that RAM when it's actually busy.
As an example, consider these stats from one of my (unix) DB servers:
CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 710M Active, 730M Inact, 554M Wired, 72M Cache, 315M Buf, 862M Free
Swap: 2048M Total, 910M Used, 1138M Free, 44% Inuse
- I have "plenty" of free RAM (800MB, and nothing will ever need more than that).
- I'm using a huge chunk of my swap space
(because there's a program on this server with a memory leak that is mostly swapped out)
- System performance is excellent, and all my users are happy.
So at this time I take no tuning actions (though I do kill and restart the program with the memory leak when swap utilization hits 50%).