☰

smb-share 连接时间会增加 Windows PE 上每次重新启动的时间

tag-icon • tag-icon debian samba performance smb
smb-share 连接时间会增加 Windows PE 上每次重新启动的时间

我们目前正在开发一个系统，可以为我们的计算机自动更新 BIOS。

系统在通过 PXE-Boot 启动的 Windows 10 PE 中运行。第一步是连接到存储所有所需数据的 SMB 共享。

该共享本身托管在 Debian 4.9.88-1+deb9u1 上，带有 smbd 版本 4.5.12-Debian。

问题

该过程需要多次重新启动并再次启动 Windows PE。

我们发现，每个系统在首次启动时运行良好，但每次重新启动到 Windows PE 时，与 SMB 共享的连接需要更多时间，有时甚至会超时并出现 Windows 错误 63。

由于 Windows PE 在每次重新启动时都会“新”存储在 RAM 中并且不是持久的，因此我们认为问题必须出在服务器端。

Samba 的日志文件不包含任何有关主机连接的错误。

PE中的挂载命令

NET USE B: \\SERVER\buffet \user:user password

由于 Windows 10 不允许匿名来宾登录或在没有密码的情况下共享，因此不使用登录凭据不是一个选择，尽管我个人认为问题与身份验证无关。

Samba 配置

正如您所看到的，我们已经尝试了许多超时配置：

[global]
    workgroup = WORKGROUP
    security = user
    server role = standalone
    disable netbios = no
    server string = %h
    map to guest = Bad User
    obey pam restrictions = Yes
    passdb backend = tdbsam
    pam password change = Yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    unix password sync = Yes
    log file = /var/log/samba/log.%m
    log level = 10 winbind:5 auth:3
    max log size = 1000
    dns proxy = No
    usershare allow guests = Yes
    panic action = /usr/share/samba/panic-action %d
    create mask = 0777
    directory mask = 0777
    map hidden = no
    map system = no
    map archive = no
    store dos attributes = yes
    dos filemode = Yes
    acl map full control = Yes
    server min protocol = SMB3_10
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    read raw = yes
    write raw = yes
    server signing = no
    strict locking = no
    min receivefile size = 16384
    use sendfile = Yes
    aio max threads = 250
    aio read size = 1
    aio write size = 1
    ldap timeout = 3
    deadtime = 1
    winbind request timeout = 10
    name cache timeout = 0
    winbind max domain connections = 50
    winbind max clients = 750
    inherit owner = No

[buffet]
    path = /share/buffet
    public = yes
    writeable = no
    browseable = yes
    guest ok = yes
    force user = nobody
    force group = nogroup
    read only = yes
    case sensitive = no
    default case = lower
    preserve case = yes
    short preserve case = yes

我们如何修复配置，以便主机可以无限重新启动并仍然立即连接到共享？

尝试修复它

正如您在上面看到的，我们已经尝试了几种超时设置smb.conf，但它们都对我们的问题没有影响（结论是，它们不可能是问题所在）。

我们还提取并分析了大量的 samba 日志文件，我们试图避免这些日志文件任何“失败”或“超时”或任何可能由于配置错误而导致错误的内容，最后我们全部解决了，但问题仍然存在。

我们还尝试了一些不同的 DHCP 服务器设置，例如将默认租用时间设置为非常小的值（例如 10 秒），但同样，这对我们的问题没有影响。

我们还尝试强制 Samba 使用 SMB2 或 SMB3_11，但将使用的 SMB 协议设置为固定值也无法解决问题，在我们的 winPE 客户端重新启动三到四次后，SMB 共享将不再连接立即地。

快速 ping 成功后，服务器上不会出现高 CPU/内存负载，同时会继续尝试挂载共享。此外，我们使用速度计监控网络带宽，我们只能看到连接上的负载非常低（上下只有几 KB/s）。在这些缓慢的挂载共享尝试过程中，ping 时间本身不会增加。

答案1

作为进一步的跟进，我想通知您，今天我们将文件传输架构从 samba 转移到 HTTP，以检查延迟是来自服务 (samba) 还是来自主机/网络。我们决定使用 apache2 来托管我们的应用程序所需的文件，因此我们尝试了半天来面对与 samba 相同的问题，但没有成功。在四个多小时的测试中（我们在从 apache 共享成功下载负载后自动重新启动客户端），我们没有看到任何不成功的连接尝试！

因此，我们决定将 samba 配置减少为裸机配置，实际上看起来像这样，以防止我们所做的不同设置之间的干扰：

[global]
workgroup = WORKGROUP
security = user
server role = standalone
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
map to guest = Bad Password
log file = /var/log/samba/log.%m

但即使使用这种非常有限的配置，我们仍然会看到这样的问题：在非常有限的重新启动次数之后，成功 ping 到服务器（以检查其可用性）和连接到 smb 共享之间的延迟开始增加，直到最终时间并抛出“未找到网络路径”错误。

在这种情况下，有趣的事实是，我们可以对任何可用的客户端重复此行为。我们只需启动 WinPE，让它 ping 服务器，如果能 ping 通，则连接 samba 共享，下载一些所需的文件（仅几 MB）并让客户端重新启动。即使我们在多个客户端上进行并行测试，这些客户端会延迟两次重新启动，我们也可以看到，如果一个客户端“挂起”，另一个新客户端会立即启动。结论是，该问题一定是由客户端/Samba 干扰引起的，或者是某个特定客户端与 Samba 共享的同时连接过多的原因。

我们认为，我们将问题完全缩小到了 samba，因为使用 apache 半天都不可能导致问题出现。此外，由于 apache 一切都按预期工作，我们认为服务器或网络配置不可能是这种情况。

你会不会也有同样的想法并说这一定是桑巴舞？

我们将不胜感激任何可能有帮助的想法。由于我们已经解决了这个特殊情况（我们的解决方案是不使用 samba），我们想知道这个问题的根本原因，因为我们在另一个工厂部门也有类似的问题，我们无法避免使用 samba 来共享文件通过网络。据此，如果大家有更多的意见，我们愿意继续调试这个问题。

为了避免进一步的混乱，我想告诉您，Marcel Kohlmeyer 和我是同事，他们同时研究同一问题。

相关内容