我希望我的Windows尽快运行。如果我在Windows 7 64bit,四核CPU中拥有12GB RAM,并且所有应用程序都可以容纳在内存中,那么交换文件是否可用于任何用途?问题是将交换文件放在RAM磁盘中是否是一个好主意。
RAM磁盘会以任何方式提供帮助,还是Windows将智能地使用所有可用内存来完成其所有工作?
我也正在考虑将临时文件夹放在RAM磁盘上。我知道RAM磁盘是易失性内存,如果丢失了它,我不在乎它的内容。
我希望我的Windows尽快运行。如果我在Windows 7 64bit,四核CPU中拥有12GB RAM,并且所有应用程序都可以容纳在内存中,那么交换文件是否可用于任何用途?问题是将交换文件放在RAM磁盘中是否是一个好主意。
RAM磁盘会以任何方式提供帮助,还是Windows将智能地使用所有可用内存来完成其所有工作?
我也正在考虑将临时文件夹放在RAM磁盘上。我知道RAM磁盘是易失性内存,如果丢失了它,我不在乎它的内容。
Answers:
我不会说荒谬的;适用于32位或64位系统。
首先,显而易见的是32位窗口(大多数正在运行的系统)忽略了4GB以上的任何内容。Ramdisk能够使用PAE和36位内存寻址,据我所知,它们是使高内存区域在32位系统中有用的唯一方法。
问题是:我们如何利用闪电般快速/更安全的虚拟硬盘?只要您知道如何在Windows中分配固定的驱动器号,就可以想到临时文件并对其进行设置非常简单。与浏览器缓存相同。这些的兴趣是四倍:
至于交换文件,显然将32位系统放入无人认领的RAM中可以获得很多好处。人们可能会想到一个内存不足的程序,它本身会使用3 GB(boot.ini中的3GB开关),这很可能会引起很多交换。仍然有两个相同的奖励:真正的删除和SSD的磨损。碎片对于交换文件来说不是什么大问题。
还有更多:写得不好的程序使用虚拟内存是很常见的,无论可用的物理内存有多少,都会导致无用的磁盘访问。这对于32位和64位程序都适用。我什至遇到了在没有交换文件的情况下无法启动的程序。
最重要的是,尽管将RAM磁盘设置为4GB以下并为临时文件夹和程序缓存保存无用的磁盘访问都是有意义的,但似乎最好安装超过4 GB的内存,而在这32个内存中,内存价格都是合理的。 (具有启用了PAE的硬件)和64位系统,然后将交换文件移到此处。
应该注意的是,出于硬件支持的原因,很多专业计算机用户仍然不能使用64位。
使用与上述相同的强语言是荒谬的,只是拒绝了这个想法,不仅依赖于Microsoft的虚拟内存处理(这受到了正确的表扬),而且依赖于汇编汇编专家的应用程序程序员。高阶语言白痴,仅仅通过不良的内存处理就可以使最出色,最稳定的PC瘫痪。我已经在主流程序,生产力应用程序中看到了这样的代码,但我不骗你!
我的主系统在XP / 32上有一个8GB的ramdisk,事实证明这很有用。设置非常琐碎,我必须说,给我带来麻烦的唯一程序是google chrome,它的安装/更新策略很难调整。
除了这些之外,您还可以想到ramdisk的许多有用用法;以我为例,音频示例可从实时应用程序的磁盘上检索:在启动时将它们放到那里(非常缓慢),并可以快速访问multiGB库。但这离主题很远:)
这是我自己的经验。我希望人们不会通过使用不必要的强语言来破坏有用信息的价值。至少可以这样说,在这种情况下,可笑是一个不好的选择。
是的,即使一个人有很多RAM,也会使用分页文件。但是分页文件的简单存在本身并不是影响系统性能的因素。而且,将分页文件放在RAM光盘上是很简单的。毕竟,指向分页文件的点是当页面数据当前不在RAM中时用于保存(瞬态)页面数据的地方。RAM光盘在RAM中……
当然,将临时文件放在RAM磁盘上是完全不同的鱼。
我怀疑您将页面文件移动到ramdisk会看到很大的不同。如果要强制Windows使用ram,则可以关闭分页文件。
但是,我注意到将IE临时文件移动到ramdisk并将TEMP和TMP环境变量设置为指向ramdisk有很大的不同。
我还使用“ -user-data-dir =“ R:\ ChromeTEMP”标志运行Google chrome,因此它将临时文件存储在ramdisk上。这将导致它忘记您的设置。但是由于我使用了同步功能,因此没有最初的同步后,一切恢复正常,并且链接到虚拟磁盘上某些文件的副本后,天际加载屏幕变短了。
Windows将继续使用交换文件,这对我来说没有任何意义(由于我的困惑,因为我有相同的设置)。但是,禁用分页文件后,我看不到任何实际的性能改进。从那以后,我又回到了使用页面文件的问题,因为Windows将它用于虚拟内存以外的其他东西(我认为当您蓝屏时,它还会向它写入崩溃转储)。我还多次读取12GB的RAM,还很高兴我有了摆动室。
简而言之,Windows仍将使用页面文件,但您不应将其视为性能问题。
至于临时文件,将它们移动到ram磁盘应该会提高它们的访问速度,尽管请确保其中不需要任何内容来通过重新引导/崩溃持久化,并且ramdisk驱动程序会在任何应用程序或应用程序之前加载并创建ramdisk。系统需要使用temp文件夹。
我认为这实际上不是一个坏主意。
逻辑上,人们误解了“页面文件”或更正确地将“交换文件”理解为RAM。交换文件与RAM所保存的数据类似,这是事实。但是Windows不会像RAM那样使用它。正如您今天所看到的,在我们生活中不断发展的多任务世界中,Windows的设计初衷是通过不断在交换文件和RAM之间进行写入来处理有限数量的RAM。
Windows始终使用交换文件,因为在运行较少程序的较慢的较旧计算机上,性能提升更为明显。当您打开窗口时,程序将在您正在其中工作时被交换到RAM中。
假设您正在用Word写一封信。如果您刚刚在后台启动了具有许多程序\ windows的程序,则该程序可能会变慢,但几秒钟后运行会更加流畅。然后,当您切换到Internet Explorer时,它运行缓慢,然后变得更快,因为它位于页面文件中,然后交换到RAM中,而所有后台进程都被加载到了页面文件中。
现在让我们将RAM磁盘介绍给Windows。将交换文件而不是HDD放在ramdisk上,由于RAM的速度比HDD /硬盘驱动器的速度快,因此Windows可以执行多任务处理。但是,这在较旧的系统上无济于事,除非您购买物理RAM驱动器–并且您可能不得不在Windows中再次设置页面文件,因为没有电源,它将被删除。
对于具有8、16、32、64 Gig RAM的新型PC,页面文件变得毫无意义。
你们大多数怀疑论者都忘记了32位Windows RAM的限制,而错过了一个事实,那就是您不能在RAM中放置超过3,5GB的代码和数据。或者,您只是认为我们正在尝试从可访问的3,5 GB中“切断” 2 GB-用于快速页面文件,其代价是将可用内存减少到1,5 GB。这当然毫无意义,但这不是我们的想法。我们的想法专用于32位Windows的用户,他们拥有的RAM超过限制的3.5GB内存的PC更多。例如,一台装有8GB的计算机,运行32位XP或Vista或2003。
当您同时同时处理许多应用程序时,系统通常会面临耗尽内存的情况。为了避免严重错误,系统被迫将后台运行的应用程序的某些数据存储到pagefile中。通常,这意味着在硬盘上写入数十和数百MB。请记住-当您真正使用多任务处理(当今很常见,以及消耗内存的应用程序)时,它经常发生。而且,当您将后台应用程序置于前台时-必须将另一批来自RAM的数据发送到HDD,只是为了在RAM中腾出空间,以便上一批次从HDD返回(这次是从磁盘驱动器中读取和读取许多MB)。只需观察您的红色HDD活动LED指示灯-它会亮起而不是熄灭(您的HDD确实工作得很努力)。
现在想象所有这些操作都重定向到EXTRA RAMdisk(额外的RAM,绕过系统的操作存储区,该存储区的大小保持不变-最大)。
我不相信它在性能方面毫无意义,更不用说硬盘的可靠性了。
好的,在XP时代建造的大多数计算机不是基于能够支持超过4GB RAM的主板。因此,我知道很少有人真正关心/需要并理解这个想法。但现在...
欢迎来到虚拟化时代! 越来越多的人幸运地拥有一台具有大量RAM的计算机。新手可以将其主机系统配置为向来宾32位Windows分配4GB,并且仍然有大量RAM。那么,用一个分配给相同来宾OS的4GB RAM磁盘来丰富它,这真是非常宝贵的,它专用于页面文件,而没有来宾的RAM空间!
我管理的服务器有12GB。不用购买新系统(64-2008加上CAL!),我可以为来宾分配8GB(虚拟32-2003)并尝试测试软件RAMdisk。但是,我不信任他们,因为它们似乎是骇客,而且我不喜欢冒险获得稳定性。这就是为什么我正在寻找一种解决方案,以准备主机的Linux Ramdisk作为块设备并将其格式化为FAT或NTFS,以使其成为来宾OS的虚拟磁盘可接受的方式,以便将页面文件放在其中。我相信我的服务器可以提高并节省大量磁盘工作量。
我哪里错了? 格蕾兹!
Ramdisk对于IE,Chrome和Firefox等快速Internet缓存非常有用。
将页面文件放在64位系统的Ramdisk中是没有用的。
DisablePagingExecutive可能更适合这些需求。但是将页面文件放在具有超过4 GB Ram的32位环境中的Ramdisk上是一个巨大的改进。但是,如果您的计算机是单核处理器(根据taskmanager仅一个处理器),则会有所改进(记不清多少了,这已经有一段时间了)。但是,您还需要设置ClearPagefileAtShutdown来消除下次重新启动时的错误,因为该页面文件将不存在。
我能想到的Ramdisk的最佳用途是将您的程序文件文件夹(或选择程序)镜像到Ramdisk中。