我有一个Windows Server 2008 R2（64位）在4GB物理服务器上运行64位Firebird 2.1.4.18393_0安装。
一段时间后，任务pipe理器显示所有内存都被使用，但是所有进程的内存总和不会堆栈到内存的一半。 不幸的是，它开始交换。
使用RAMMAP，我可以看到我的整个数据库文件被映射到内存中。 这只在Windows Server 2008 r2和Windows 7 64位中出现。 我可以使用火鸟32或64位安装，没关系。
我怎样才能防止这个？ 为什么这只在w2k8r2和w7出现？
tks提前
**更新
实际上，这是由文件系统caching使用所有内存造成的。 微软的文件解释说，这是在Windows XP，2K3，Vista和2K8的问题，但它在7和2K8R2解决。 还补充说这个问题在64位主机上比较常见。 （ http://support.microsoft.com/kb/976618 ）
有一些工具（DynCache，setcache和来自windows API的Get / SetSystemFileCacheSize系统调用）允许我通过fscache修复内存使用的上限，但是文档认为我不应该在w2k8r2中这样做，因为它会严重影响整体系统性能。 无论如何，我试过了，性能保持不变，使用的页面文件仍然存在，虽然现在有更多的1GB的可用内存。
那么问题毕竟解决了。 这是一个窗口tunning和一些firebird tunning一点。
在窗口方面，setcache确实在保持文件系统caching的大小的控制下，即使微软说我不需要这个技巧。 我刚刚添加了一个计划任务在每次启动时运行。
但是即使降低了内存使用量，我的firebird数据库仍然使用了我的双核四核处理器的12.5％：一个内核的100％，性能很糟糕（30秒select一个表中只有10个元组的所有元组）。
在经过sinática（www.sinatica.com）的一些监控之后，我意识到我的数据库正在清理。 所以我禁用自动扫描，并添加了另一个计划任务做2天的扫描。
这是关于这个问题的更新（希望有帮助）：
http://dyemanov.blogspot.com.br/2012/03/firebird-vs-windows-file-system-caching.html
所以唯一有效的解决scheme似乎是禁止从用于创build/打开文件的Windows API调用的随机访问请求（即删除FILE_FLAG_RANDOM_ACCESS标志）。 此外，在这种情况下，文件系统caching大小限制不应该再实际上了，因为Windows不会将caching扩展到合理的边界之外。
…
这个解决scheme已经被提交到Firebird 2.1.5，Firebird 2.5.2和Firebird 3.0分支。
此问题可以通过使用Microsoft DynCache工具来缓解。 如果您无法将FireBird服务器更改为不具有caching缺陷的版本（例如，使用需要停用版本的软件等），则此解决方法是适用的。
由于DynCache很难获取并正确设置，请参阅如何在此处使用它的说明： http : //sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memory-problems.aspx
看起来这会让你朝着正确的方向前进 – http://www.firebirdfaq.org/faq333/ 。