NFS 服务器 | 挂起线程

NFS 服务器 | 挂起线程

我们有四个 lpar,每个 lpar 运行 1 个 java 实例。它们对共享 NFS 服务器执行大量读/写操作。当 NFS 服务器突然停机时,这四个服务器中试图读取图像的所有线程都会进入挂起状态。下面的跟踪显示了相同的情况(进程是 websphere 应用程序服务器进程)

1)当我们处理 NFS 服务器端的问题时,有没有办法从代码端避免这种情况?

2) 如果底层连接是基于 TCP 的 (我假设是这样的),TCP 读取/连接超时是否应该处理这个问题?基本上,我希望线程返回到池中,而不是无限期地等待另一方响应。

3) 或者这是源计算机上的 nfs“客户端”应该处理的事情?客户端上与 nfs 相关的一些配置设置(因为 FileInputStream.open 不知道它尝试读取的文件是在本地服务器上还是在 nfs 服务器中的共享文件夹中)

提前感谢您的回答:)

我们在 WAS 7.0 上使用 Java 1.6

[8/2/15 19:52:41:219 GST] 00000023 ThreadMonitor W   WSVR0605W: Thread "WebContainer : 77" (00003c2b) has been active for 763879 milliseconds and may be hung.  There is/are 110 thread(s) in total in the server that may be hung.
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:113)
        at java.io.FileInputStream.<init>(FileInputStream.java:73)
        at org.emarapay.presentation.common.util.ImageServlet.processRequest(Unknown Source)
        at org.emarapay.presentation.common.util.ImageServlet.doGet(Unknown Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1694)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1635)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:113)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:80)
        at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:965)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:508)
        at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl

答案1

这可能取决于 NFS 共享的挂载方式。默认情况下,NFS 共享使用“硬”参数挂载,这意味着对无响应的 NFS 共享的访问将无限期阻止。

您可以更改客户端挂载点,添加以下参数之一(我在这里使用 Linux 手册页,也许您的具体选项有点不同):

  • soft:如果指定了 soft 选项,则 NFS 客户端在发送重传后将使 NFS 请求失败,从而导致 NFS 客户端向调用应用程序返回错误
  • intr:选择是否允许信号中断此挂载点上的文件操作。使用 intr 选项优于使用 soft 选项,因为它导致数据损坏的可能性明显较小。仅供参考,这在 Linux 内核 2.6.25+ 中已弃用

来源:Linux nfs 手册页

相关内容