我有一个大中型服务器，我的所有工程用户都在使用它。这是一个 32 核、256GB 的系统，托管 19 个 Xvnc 会话以及过多的工具、登录会话，以及这样的用户群所暗示的。所有用户都通过 NIS 进行配置，并在 NFS 上拥有主目录。各种自动化进程也使用 NIS 定义的用户和 NFS 安装的文件系统。
有问题的计算机运行的是 CentOS 6.5，所涉及的文件服务器是 NetApp。
有时，在计算机运行一段时间后，人们会在删除某些内容时遇到间歇性问题；该错误与“设备/资源繁忙”类似。lsof 没有显示任何保留相关项目（文件或目录）的内容；经过一些不确定的时间（通常少于找到管理员并让他查看问题所需的时间）问题消失并且可以删除该项目。
大约在同一时间，使用 SVN 的自动化流程之一出现如下错误：
svn: E155009: Failed to run the WC DB work queue associated with '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images', work item 930 (file-install doc/verif/verification_environment/learning/images/my-sequence.uml 1 0 1 1)
svn: E000018: Can't move '/home/local-user/tartarus/project8/.svn/tmp/svn-j3XrNq' to '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images/my-sequence.uml': Invalid cross-device link
如果我们尝试删除有问题的文件，我们会得到：
rm: cannot remove `project8/doc/verif/verification_environment/learning': Device or resource busy
谷歌搜索“无效的跨设备链接”导致了很多关于 svn 版本的讨论，并且不支持跨设备写入，这与我们无关，因为这通常有效并且我们没有运行跨版本的 svn 存储库。或者跨设备存储库，因为 .svn 目录与工作副本所在的设备位于同一设备（nfs 挂载）上。
重新启动计算机会使问题消失数周或数月——在我目前的情况下，计算机的正常运行时间刚刚达到 185 天。但是工程师们并不热衷于比必要的更频繁地重启他们的世界。
我们已将文件服务器排除在外，因为其他计算机不会出现相同的问题，除非该问题在主系统上出现。也就是说——如果主系统不能移动/重命名文件，我们可以复制文件不能被移动/重命名的事实，但是其他计算机从来没有独立地表现出这种行为。
NFS 文件系统的挂载选项是： rw,intr,sloppy,addr=10.17.0.199
我认为这必须是某个内核值被过度填充，要么是工程师正在运行的某些泄漏的副作用，要么是由于临时负载而导致的突发。
它不是正在打开的文件总数，因为该限制类似于 25M 文件，而这台计算机的峰值低于 200K 文件。
有谁知道我应该看什么/为了什么？
小智 2
简短回答：您的本地 NFS 认为不存在文件或目录。（是的，你有点怀疑）
NFS 是一项古老的技术。它不适用于高访问量、快速变化的文件。对于动态共享文件系统，请尝试集群解决方案，例如 OCFS2（我的最爱）或 gluster（嗯，Dark Side）。
几年前，我们有 4 台服务器安装了一个通用的 NFS，并且多次发现其中一台服务器会创建其他服务器看不到的文件。这 4 台服务器是 Web 应用程序服务器。用户将启动一个操作，让服务器创建一个包，并在完成后使用该文件的 NFS 路径更新数据库中的一行。用户的浏览器将每隔 10 秒检查一次，看看工作是否完成，以及是否需要下载文件。您可以看到问题即将到来 - 服务器将更新数据库中文件所在的行，但另一台服务器将从用户浏览器获取请求 - 它将读取文件并收到“文件未找到”错误。
正如你所说，当管理员查看它时，文件就在那里。我们几个工程师花了几周时间才找到问题所在。基本上，我们运行了一个 10 秒的睡眠循环，它将获取数据库中指示的最后创建的文件路径，并尝试将文件写入日志。创建该文件的系统始终可以看到该文件，但其他系统在一段时间内看不到该文件。随着服务器负载的增加，时间间隔变得更长。
尖头老板们不想将底层 NFS 更改为集群文件系统，因此我们还让工作服务器保存“他”是在数据库中创建文件的人。用户的请求将不断重试，直到作业完成并且请求到达创建该文件的服务器，以便该文件始终可供读取。是的，我知道。克鲁奇。但这就是当你决定保留旧技术时你会得到的结果——你必须拼凑才能让事情发挥作用。旧技术是第一个拼凑，而与之相关的所有工作都只是更多的拼凑。欢迎回到 80 年代，Max Headroom 的 FS 选择。
NFS 并不能让所有客户端实时同步所有更改。因此，您会不断遇到这样的情况：一个客户端创建文件/目录，而另一个客户端看不到它，或者一个客户端删除文件/目录，而其他客户端认为它仍然存在（直到他们尝试使用它 - 哎呀） ）。
我们尝试了各种技巧，让系统在尝试读取文件之前重新同步其客户端缓存。没有发生。
我的建议：把你的FS带入这个世纪。（尝试通量电容器 @ 88mph）
| 归档时间： |
|
| 查看次数： |
2754 次 |
| 最近记录： |