阻塞VM的整体性能更好，因为同步，线程生成和恢复等待值的阻塞客户端都不会浪费时间。因此，如果您愿意不时接受更高的延迟，则阻塞VM是一个不错的选择。尤其是如果交换很少发生并且大多数经常访问的数据恰好适合您的内存。
这是Redis的默认模式（这是唯一的前进模式，我相信现在2.6中已弃用VM），让OS处理分页（如果需要）。我的理解是正确的，启动/启动将需要一些时间才能变得“热”。当在具有16gb数据集的1gb RAM节点上工作时，Redis是否会在引导时尝试将其全部加载到虚拟内存中，从而立即将90％+的页面调出，并且仅在经过大量使用后上述语句才成立吗？
Redis VM已在Redis 2.4中弃用，并已在Redis 2.6中删除。这是一个死胡同：不要使用它。
我认为您正在将阻塞的VM与OS分页混淆。他们是两个不同的东西。
如果根本未配置Redis VM（无论阻塞模式），则OS分页是Redis的默认模式。如果操作系统不适合物理内存，则它将交换Redis内存。事件循环可以随时冻结。发生这种情况时，性能非常糟糕，因为没有Redis内部数据结构是为此目的而设计的（没有局部性，没有分页系统）。
可以在非阻塞模式下（使用I / O线程）配置Redis VM。I / O完成后，事件循环不会被阻塞，Redis仍会响应。但是，当堆积过多的I / O时，I / O线程将完全忙碌，最终您将得到响应式Redis，但无法处理任何需要I / O的查询。
Redis VM也可以配置为阻止模式。在这种模式下，所有I / O在主事件循环线程中同步执行。因此，在I / O情况下（例如在键丢失的情况下），事件循环被冻结。所有客户都会受到影响。但是，由于节省了一些线程调度/同步，因此总体性能（CPU消耗和延迟）比非阻塞模式要好。
实际上，操作系统分页和Redis阻止VM之间的区别在于粒度级别。使用Redis VM，粒度是关键。使用OS分页时，它就是页面（一个4 KB的块，可以跨越几个不相关的键）。
在所有3种情况下，转储文件的初始加载都将非常慢，并且会在系统上产生随机I / O的峰值。如您所指出的，大多数对象将被加载然后换出。预热时间将很长。
除非您的数据具有极高的局部性，或者您根本不关心延迟，否则将Redis VM与16 GB数据集一起使用1 GB RAM是科幻小说IMO。
逐步淘汰Redis VM是有原因的。从设计上讲，它永远不会像基于磁盘的数据存储那样好（它可以利用文件映射或直接I / O来避免双重缓冲，并使用像B树一样的适应数据结构）。
Redis作为内存存储非常好。但是，如果您需要存储大于RAM的内容，请不要使用它。其他（基于磁盘）存储将都表现得更好。
