获取驻留在 SMB 挂载上的文件属性时性能下降

如何解决获取驻留在 SMB 挂载上的文件属性时性能下降

我有一段 C++ 代码，它列出文件夹中的文件，然后通过 Windows API 获取每个文件的属性。当文件夹是远程服务器上的 SMB 安装（安装为磁盘）时，我对这段代码的性能感到困惑。

#include <string>
#include <iostream>
#include <windows.h>
#include <vector>

//#include <chrono>
//#include <thread>

int main(int argc,char *argv[]) {
    WIN32_FIND_DATA ffd;
    HANDLE hFile;

    std::string pathStr = argv[1];
    std::vector<std::string> paths;

    hFile = FindFirstFile((pathStr + "\\*").c_str(),&ffd);
    if (hFile == INVALID_HANDLE_VALUE) {
        std::cout << "FindFirstFile failed: " << GetLastError();
        return 1;
    } else {
        do {
            paths.push_back(pathStr + "\\" + ffd.cFileName);
        } while (FindNextFile(hFile,&ffd) != 0);

        int error = GetLastError();
        if (error != ERROR_NO_MORE_FILES) {
            std::cout << "FindNextFile failed: " << error;
            FindClose(hFile);
            return error;
        }
        FindClose(hFile);
    }

    std::cout << paths.size() << " files listed" << std::endl;

    // std::this_thread::sleep_for(std::chrono::milliseconds(30000));
    
    for (const std::string & p : paths) {
        int a = GetFileAttributes(p.c_str());
        bool isDir = (a & FILE_ATTRIBUTE_DIRECTORY);
        bool isHidden = (a & FILE_ATTRIBUTE_HIDDEN);
        std::cout << p << ": " << (isDir ? "D" : "f") << (isHidden ? "H" : "_") << std::endl;
    }
}

也就是说，如果我有一个包含 250 个文件的文件夹，它会在大约 1 秒内通过。当有 500 个文件时，它会在大约 1 分钟内通过，甚至第一个文件每个都需要数百毫秒（因此，1 秒足以容纳大约 10 个文件）。试验它，我发现有一些限制，低于每秒数百个文件的处理速度，高于每秒约 10 个文件的速度。我还注意到这个数字与文件名长度不同。使用 file-001 之类的名称：510 到 520 之间。使用 file-file-file-file-file-001 之类的名称：370 到 380 之间。

我对为什么会发生这种情况感兴趣，特别是为什么当文件夹中有“太多”文件/文件夹时速度从一开始就下降。有办法调查吗？可选：有没有办法在仍然使用 GetFileAttributes 的同时克服这个问题？

（代码可能非常丑陋，我只是从网上找到的示例中拼凑起来的。我用 MinGW 编译它，g++ -static files.cpp -o files.exe，运行它 files.exe "Z:\test_folder"。我的原始代码是用 Java 编写的，我从 Hotspot JVM 的源代码中得知它使用了 GetFileAttributes WinAPI 方法，所以我创建了这个片段来查看它的行为是否与 Java 代码相同——它确实如此.我在解决这个性能问题的方法上也受到限制：我注意到 FindFirstFile/FindNextFile WinAPI 调用的执行速度始终如一，但我没有找到一种方法可以在没有 JNI/JNA 的情况下从 Java 中使用它对我来说太麻烦了。）

更新：如果我在列表（收集到向量中的文件）和在循环中获取它们的属性之间放置 30 秒的睡眠，行为就会与文件夹中的任意数量的文件保持一致——”慢”适用于任意数量的文件。我还在这里和那里阅读了一些分散的信息，Windows SMB 客户端应用缓存，受时间限制等。我想这就是我在这里看到的：列出文件夹用文件属性填充这个缓存，随后的 GetFileAttributes 没有命中远程系统如果在列表后立即运行。我猜其他行为也与缓存相关：当列出“太多”文件时，只有列表的尾部保留在缓存中。然后我们再次从第一个文件开始 GetFileAttributes，每个请求都会到达服务器。对我来说，为什么上市这么快而 GetFileAttributes 这么慢，我还是个谜......

更新 2： 我想确认它与缓存有关，但到目前为止我并不幸运。如果它与逐出“第一个”文件属性有关，那么以相反的顺序获取属性将访问许多文件的缓存——事实并非如此：要么全都快，要么全慢。

我尝试根据 this MS article 摆弄 SMB 客户端参数，希望如果我将大小设置得非常高，我就不会再注意到缓慢的行为——事实也并非如此，这种行为似乎是完全独立的从这些参数。我设置的是：

// HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
DirectoryCacheEntriesMax = 4096
DirectoryCacheEntrySizeMax = 32768
FileInfoCacheEntriesMax = 8192

此外，我注意到当“文件太多”时，列表会以随机顺序返回路径（不是按字母顺序排序）。不确定它是否与问题有关。即使将列表更改为使用 FindFirstFile/FindNextFile，这种行为也是如此。

此外，我更仔细地研究了使“缓存”“无效”所需的超时（因此，对于一个文件很少的文件夹开始缓慢运行），在我的情况下大约是 30 秒。有时，设置较低的值会显示相同的行为（对于包含少量文件的文件夹，属性获取速度较慢），但重新运行程序后又会立即发生。

我更新了上面的代码，最初使用的是 C++17 中的 std::filesystem::directory_iterator。

获取驻留在 SMB 挂载上的文件属性时性能下降

如何解决获取驻留在 SMB 挂载上的文件属性时性能下降

相关推荐