Runtime.exec 导致重复的 JVM 无限期挂起直至被杀死 (Solaris 10)

Question

所有，

我们正在 WebLogic 服务器 9.2 MP2 上运行 J2EE 应用程序，并在 Solaris 10 上使用 jrockit 64 位 JVM (27.3.1)。

我们调用 use runtime.exec 来调用名为 jfmerge 的可执行文件来创建 PDF 文档。

我们发现，在 Solaris 中，当调用 runtime.exec 时，会临时生成一个重复的 JVM 以启动 jfmerge 进程。 虽然这效率很低（我们的 JVM 是 5 GB，因此重复的 shell JVM 也是 5 GB），但主要问题在于，当我们的应用程序中此功能（PDF 生成）负载很重时，有时重复的 JVM永远不会退出。

当 JVM 挂起时，服务器会产生大问题（应用程序极度缓慢和用户会话终止），因为整个重复的 JVM 将其所有 5 GB 进程大小写入磁盘交换。

我们注意到以下挂起线程与挂起 JVM 进程相关，直到该进程被手动终止：

“[STUCK] ExecuteThread：'17'对于队列：'weblogic.kernel.Default （自调整）'" id=3463 idx=0x158 tid=3460 prio=1 活着，在本机中， 守护进程 在 jrockit/io/FileNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BII)I(本机 方法） 在 jrockit/io/FileNativeIO.readBytes(FileNativeIO.java:30) 在 java/io/FileInputStream.readBytes([BII)I(FileInputStream.java) 在 java/io/FileInputStream.read(FileInputStream.java:194) 在 java/lang/UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:227) 在 java/io/BufferedInputStream.fill(BufferedInputStream.java:218) 在 java/io/BufferedInputStream.read(BufferedInputStream.java:235) ^-- 保持锁定： java/io/BufferedInputStream@0xfffffffec6510470[薄锁] 在 gov/v3/common/form Generation/sessionbean/FormsBean.getProcessStatus(FormsBean.java:809) 在 gov/v3/common/form Generation/sessionbean/FormsBean.createPDF(FormsBean.java:750) 在 gov/v3/common/form Generation/sessionbean/FormsBean.getTemplateDetails(FormsBean.java:450) 在 gov/v3/common/form Generation/sessionbean/FormsBean.generateSinglePDF(FormsBean.java:1371) 在 gov/v3/common/form Generation/sessionbean/FormsBean.generatePDF(FormsBean.java:263) 在 gov/v3/common/form Generation/sessionbean/FormsBean.endorseDocument(FormsBean.java:2377) 在 gov/v3/common/form Generation/sessionbean/Forms_qaco28_EOImpl.endorseDocument(Forms_qaco28_EOImpl.java:214) 在 gov/v3/delegates/common/FormsAndNoticesDelegate.endorseDocument(FormsAndNoticesDelegate.java:128) 在 gov/v3/actions/common/EndorseDocumentAction.executeRequest(EndorseDocumentAction.java:68) 在 gov/v3/fwk/controller/struts/action/V3CommonDispatchAction.dispatchToExecuteMethod(V3CommonDispatchAction.java:532) 在 gov/v3/fwk/controller/struts/action/V3CommonDispatchAction.executeBaseAction(V3CommonDispatchAction.java:336) 在 gov/v3/fwk/controller/struts/action/V3BaseDispatchAction.execute(V3BaseDispatchAction.java:69) 在 org/apache/struts/action/RequestProcessor.processActionPerform(RequestProcessor.java:484) 在 gov/v3/fwk/controller/struts/requestprocessor/V3TilesRequestProcessor.processActionPerform(V3TilesRequestProcessor.java:384) 在 org/apache/struts/action/RequestProcessor.process(RequestProcessor.java:274) 在 org/apache/struts/action/ActionServlet.process(ActionServlet.java:1482) 在 org/apache/struts/action/ActionServlet.doGet(ActionServlet.java:507) 在 gov/v3/fwk/controller/struts/servlet/V3ControllerServlet.doGet(V3ControllerServlet.java:110) 在 javax/servlet/http/HttpServlet.service(HttpServlet.java:743) 在 javax/servlet/http/HttpServlet.service(HttpServlet.java:856) 在 weblogic/servlet/internal/StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) 在 weblogic/servlet/internal/StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) 在 weblogic/servlet/internal/ServletStubImpl.execute(ServletStubImpl.java:283) 在 weblogic/servlet/internal/ServletStubImpl.execute(ServletStubImpl.java:175) 在 weblogic/servlet/internal/WebAppServletContext$ServletInitationAction.run(WebAppServletContext.java:3231) 在 weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) 在 weblogic/security/service/SecurityManager.runAs(SecurityManager.java:121) 在 weblogic/servlet/internal/WebAppServletContext.securedExecute(WebAppServletContext.java:2002) 在 weblogic/servlet/internal/WebAppServletContext.execute(WebAppServletContext.java:1908) 在 weblogic/servlet/internal/ServletRequestImpl.run(ServletRequestImpl.java:1362) 在 weblogic/work/ExecuteThread.execute(ExecuteThread.java:209) 在 weblogic/work/ExecuteThread.run(ExecuteThread.java:181) 在 jrockit/vm/RNI.c2java(JJJJJ)V（本机方法） -- 跟踪结束

我们想做几件事：

1.) 防止产生重复的 JVM，因为在执行简单的 jfmerge 可执行文件时我们不需要它的任何函数，而且它会产生巨大的开销。

2.) 在短期内至少要防止这个重复的 JVM 无限期地处理。

Answer 1

这个答案来晚了，但我们也有同样的问题，而我们的问题是 Solaris 如何管理内存。

问题是，当我们有一个应用程序服务器时，在我的例子中使用大量内存 10GB，并且我们想要运行一个简单的“ls”，新进程需要 10GB 才能运行。

Solaris 需要我们的服务器中有 10GB 的额外可用空间，Linux 使用称为“写时复制”的功能，此功能减少了分叉新进程的开销

http://developers.sun.com/solaris/articles/subprocess/subprocess.html

历史背景和问题描述

传统上，Unix 只有一种方法创建新进程：使用 fork() 系统调用，通常后跟 exec() 系统调用。 fork() 调用复制整个父进程的地址空间，而 exec() 将该副本转换为新进程。

（注意：在 Solaris 操作系统中，术语交换空间用于描述为系统配置的物理内存和磁盘交换空间的组合。但是，对于其他 Unix 系统，该术语可能意味着磁盘上的交换空间，也称为后备存储为了避免任何混淆，我将使用术语“虚拟内存”(VM) 来表示物理内存加磁盘交换空间。）

一般来说，fork/exec 方法效果很好。 然而，它在某些情况下也有缺点，例如无缘无故地耗尽内存以及分叉性能不佳。

内存不足：对于大内存进程，fork() 系统调用可能会因 VM 数量不足而失败，因为 fork() 需要两倍于父内存的内存量。 即使 fork() 紧随其后的是 exec() 调用（这将释放大部分额外内存），这种情况也可能发生。 发生这种情况时，应用程序通常会终止。

例如，假设 64 位应用程序当前消耗 6 GB 的 VM，并且需要创建一个子进程来运行 ls(1) 命令。 父进程发出 fork() 调用，仅当此时还有另外 6 GB 的 VM 可用时，该调用才会成功。 如果系统没有那么多可用的 VM（这是一种常见情况），fork() 将失败并出现 ENOMEM。 显然，ls(1) 命令不需要接近 6 GB 的内存来运行，但 fork() 不知道这一点。

不仅应用程序，Sun 自己的工具也可能遇到同样的问题。 例如，已针对 dbx 提交以下 Sun RFE（增强请求）：“4748951 dbx shell 应使用 posix_spawn() 执行非内置命令，而不是 fork(2)”。

当客户的实用程序使用脚本调用 dbx 来读取巨大的核心文件时，RFE 4748951 就出现了，该脚本还需要从 dbx 中运行 cut(1) 命令。 他们收到无法分叉 - 重试错误消息，导致 dbx 中止。 一项调查显示，dbx 使用 fork/exec 来执行微小的 cut(1) 命令，并在 fork() 调用期间耗尽了 VM。

Solaris Java 虚拟机 (JVM) 目前也遇到同样的问题，如 Sun RFE 中所述：“5049299 在 S10 上使用 posix_spawn，而不是 fork，以避免交换耗尽”。

---

所以你有3个选择。

1.- 提前执行 Runtime.exec 函数。

2.- 创建与其他java服务器的进程间通信，并在那里执行Runtime.exec指令。

3.- 创建一个 JNI 类来调用系统 C 函数。 我选择了这个选项，效果非常好。

我把我的示例代码放在这里。

Java 代码。

public class CallOS {
    static {
            System.loadLibrary("CallOS");
    }

    public native int exec(java.lang.String cmd);

    public static void main(String[] args) {
            int returnValue = 0;
            returnValue = new CallOS().exec("ls -la");
            System.out.println("- " + returnValue);
    }
}

C 头代码。 这是使用 javah -jni CallOS

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class CallOS */

#ifndef _Included_CallOS
#define _Included_CallOS
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     CallOS
 * Method:    exec
 * Signature: (Ljava/lang/String;)I
 */
JNIEXPORT jint JNICALL Java_CallOS_exec
  (JNIEnv *, jobject, jstring);

#ifdef __cplusplus
}
#endif
#endif

C 代码生成的。

#include "CallOS.h"
#include <stdlib.h>

JNIEXPORT jint JNICALL Java_CallOS_exec
  (JNIEnv *env, jobject obj, jstring cmd)
{
   jint  retval;
   jbyte *str;

   str = (*env)->GetStringUTFChars(env, cmd, NULL);
   if(str == NULL) return NULL;

   retval = system(str);

   (*env)->ReleaseStringUTFChars(env, cmd, str);
   return retval;
};

我希望这对你有帮助。

Answer 2

您是否正确处理生成的进程 stdout/stderr ？ 您需要在单独的线程中使用两者以可靠地防止阻塞。 有关详细信息，请参阅此答案。 您的进程生成对于某些作业和其他作业可能正常工作（由于触发挂起的 stdout/err 数量）。

关于重复进程的问题，我希望 JVM 能够fork/exec。 这会复制 Java 进程 (fork)，然后用新进程 (exec) 替换它。 我想知道你看到的是不是这个？ 另请注意，我希望操作系统实现 COW（写时复制）以仅复制那些图像之间不同的内存页面，因此在正常情况下，JVM 不会进行复制消耗的内存与您想象的一样多。

Answer 3

正如 Brian 所暗示的，在 Unix 上，另一个进程启动另一个程序的标准方法是 fork 成一个父进程和一个子进程。 然后子进程调用 exec 以用新程序替换自身。 JVM 必须执行此操作才能启动 jfmerge 程序。

通常，子进程的内存大小不是问题，因为操作系统使用写时复制让两个进程共享相同的内存映像，直到子进程调用 exec。 可能是 JVM 的子进程模型要求它分叉两次，孙进程执行 jfmerge，子进程管理孙进程。 这可以解释为什么您会看到重复的 JVM 进程。 堆栈跟踪显示进程阻止从输入流读取。 jfmerge 可能运行缓慢，进程只是挂起等待 jfmerge 产生一些输出。

您可以做的是使用其他进程来启动 jfmerge，而不是您的 5GB JVM。 编写一个仅按需运行 jfmerge 的独立程序，并让它通过某种形式的进程间通信与主进程进行通信。 这个独立的 jfmerge 服务器不需要太多内存来运行，因此分叉子进程的影响不会那么大。