对速度缓慢的 Windows 文件共享上的 MS-Access 进行故障排除?

对速度缓慢的 Windows 文件共享上的 MS-Access 进行故障排除?

我们在文件共享上有一个 MS-Access 数据库。我们遇到了性能缓慢和错误消息,我们怀疑文件访问速度太慢有关。要找出瓶颈,首先要检查什么?

它在本地运行良好,因此我们非常确定这不是应用程序本身的问题。

答案1

您可以使用 fsutil 命令在服务器计算机上创建一个大型临时文件,然后对到客户端计算机的传输进行计时,以对文件服务器吞吐量进行“快速而粗略”的测试:

fsutil file createnew temp-file-name 209715200

这将创建 200MB 的临时文件。您可以使用以下脚本进行快速复制(从您在服务器上创建临时文件的目录,并假设您有权连接到客户端计算机的“C$”共享):

@echo off
echo.|time
copy temp-file-name \\remote-computer-name\c$
echo.|time

从开始时间中减去结束时间,转换为秒数,然后将 209715200 除以经过的秒数以获得每秒的字节数。

在 100Base-TX LAN 上,您应该看到每秒 7,000,000 字节(大约 56Mbps)以上。如果低于这个数字,我就会开始怀疑有什么问题。假设服务器计算机相当现代,它应该能够毫无问题地填充 100Mbps 管道。如果您看到的传输速度低于这个数字,我会开始查看服务器和客户端所连接的交换机的管理界面中的错误计数器。您可能存在电缆故障、双工不匹配或 NIC 驱动程序问题。这只是有条不紊地追踪问题的问题。

答案2

尝试缩短文件名和完整路径。听起来很奇怪,但在某些设置中确实如此。请参阅此知识库

您还可以确保在服务器和工作站上都​​禁用 SMB 签名(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Para meter\enablesecuritysignature 设置为 0)(请参阅此线)。

还有一个与 LDB 锁定相关的有点奇怪的问题,您可以测试一下。请参阅这一页

答案3

答案4

可以尝试的其他几件事是压缩数据库本身(我假设 Access 仍然具有此功能)并对执行共享的计算机上的实际数据库文件进行碎片整理。对于对单个文件进行碎片整理,我建议使用 sysinternals重叠群命令行实用程序。

您还可以通过长时间运行 ping 来测试网络状况,我相信“ping -t”是该命令的正确 Windows 用法,并查看是否丢失数据包或是否出现较高的网络延迟。

相关内容