我们最近将用户主文件夹和共享驱动器从 Novell Netware 6.5 服务器移到了 Novell OES 服务器上。所有文件夹都存储在通过 iSCSI 连接连接到服务器的 LeftHand SAN 上。
在我们其中一栋建筑物的某些实验室中，当尝试大量访问某些文件夹时，资源管理器在工作站上冻结/崩溃。（一次一组 30 名学生）这是间歇性的，通常发生在 3-5 台机器上。这不会发生在我们的任何其他实验室/建筑物中，但我们已经消除了我们能想到的所有现场可能性。（计算机图像、接线、开关、光纤、计算机硬件等）
如果我将这些文件夹放回 Netware 服务器上，就不会出现崩溃问题。我们正试图摆脱我们所有的 Netware，所以保持这种配置是不可能的。
我们一直试图隔离这个问题，但运气不佳。
长话短说，知道我们能做些什么来找出问题所在吗？我一直在查看 Lefthand SAN 的性能数据，但一切似乎都井然有序。
我们喜欢 2.x 中的非专用服务器，但他们说所有 3.x 的服务器都是专用的（男孩，今天没有人会理解这个笑话）
我们喜欢 Bindery，但他们迫使我们在 4.x 中迁移到 NDS
我们喜欢 IPX，但他们迫使我们在 5.x 中迁移到 IP
毕竟我们喜欢 NetWare，但现在他们试图强迫我们在 6.x 中迁移到 Linux
决定权在你。慎重决定
OES-on-Linux 需要比 NetWare 更多的 CPU 来处理 NCP 连接。造成这种情况的原因有很多，但事实是 NetWare 上的无数连接会使 CPU 飙升到 40%，而与 OES 的相同连接将在系统中的处理器数量上运行负载平均。这在教育环境促进的各种高并发情况中尤为明显。当负载平均峰值超过客户端 CPU 性能的数量时，就会真正下降。
另外，请记住，Novell 在 OES-fcs、OES-SP1、OES-SP2 甚至 OES2、OES2-SP1 之间对 Open Enterprise Server 进行了一些重大改进。如果您还没有使用 OES2，请到那里。此外，如果您不是在运行 64 位，那么您真的需要努力去做。32 位 Linux 内核有一些缓存限制，会阻碍像 OES 这样的文件服务器，而 64 位内核在这方面更加宽容。