我有一台第三方面向对象数据库服务器，运行在具有24 GB RAM的Windows Server 2003 x64机器上。 除了一些系统进程和监视工具之外，数据库服务器是在这台机器上运行的唯一的东西。 我打开了10〜130GB和1〜5GB的数据库文件，后者是最常访问的，是给我的问题。
每当数据库服务器刷新这个数据库文件，似乎需要永远完成。 因为一旦数据写入磁盘，DBMS将放弃其事务日志，因此必须等待刷新完成。
我在Process Monitor中查看了IO文件，看到在正常操作之前，在冲刷之前，有很多缓冲写入（通常是128字节，有时多一点）随机的文件偏移量。 这是可以预料到的，因为小数据块以不可预测的模式添加到数据库中并在数据库中更新。
当事务日志已满并发生刷新时，有大约8000次写入4K的倍数（相关计算机上的页面大小），在我分析的一个实例中总计大约35 MB。 刷新大约需要12秒钟，数据库服务器挂起。 我们的存储人员告诉我，每次写入1.5ms（12秒除以8000次写入）就是SAN的正常性能，没有任何事情可以加快速度。
我已经读过Windows Internals 4中文件caching的工作方式，它提到cachingpipe理器会尝试在后台线程上定期写脏页面到磁盘，即使应用程序没有请求刷新（懒惰的作者） 。 有什么办法可以使页面更快地写入磁盘，所以当应用程序调用FlushFileBuffers时，应用程序只能等待写入磁盘，只剩下一些脏页了？
本书还提到，cachingpipe理器中只有一个给定文件的副本。 这是否意味着我可以通过在单独的进程中打开相同的文件并定期调用FlushFileBuffers来触发刷新，因此当数据库服务器请求刷新时再次刷新会更less？
还有其他的操作或文件系统参数，我应该看看？
我听到的一个build议是增加文件系统中的页面大小，因为这样可以通过增加每个IO写入SAN的字节数来提高吞吐量。 由于在刷新过程中保存的页面是非连续的，所以我怀疑这会做什么，对不对？