grails - 如何解决错误 java.net.SocketException : Too many open files

Question

我一直在使用 JMeter 对 REST API 进行负载测试。

当并发用户达到 1000 个时，我收到以下错误:

Too many open files. Stacktrace follows:
java.net.SocketException: Too many open files
    at java.net.Socket.createImpl(Socket.java:397)
    at java.net.Socket.getImpl(Socket.java:460)
    at java.net.Socket.setSoTimeout(Socket.java:1017)
    at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:126)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
    at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
    at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
    at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:476)
    at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:441)
    at groovyx.net.http.HTTPBuilder.request(HTTPBuilder.java:390)

我的服务器尝试访问另一个 REST API 来获取数据并对其进行处理，最后返回 JSON 响应。

如何增加 Linux 中打开文件的数量？

以下是我对另一台服务器的调用

Map getResponse(Map data, String url){
    HTTPBuilder httpBuilder = new HTTPBuilder(url);
    httpBuilder.request(Method.POST, JSON) {
        headers.'Authorization' = AppConfig.config.appKey;
        headers.'Content-type' = 'application/json'
        body = data
        response.success = { resp, reader ->
            return reader as Map;
        }
        response.failure = { response, reader ->
            return null
        }
    }
}

Answer 1

您确实打开了最大数量的打开文件/套接字。 Linux 机器上打开的文件或套接字的最大数量默认为 1024。你需要改变这一点。你可以引用这个java.net.SocketException Too many open files

您可以使用以下查询从终端进行检查，以获取允许打开的文件的最大数量

ulimit -n 

来自here :

What's happening is that the underlying sockets aren't being closed,and eventually the JVM bumps into the system's per-process limit onopen file descriptors.

The right solution would be to make the sockets close at the RightTime (which I guess is when, or shortly after, the server has closedits end of the connection). That seems hard with HttpURLConnection.It's all very confused:

• disconnect() just seems to close it immediately -- or not;the Javadocs are intentionally vague about what it actuallydoes, and especially when it does it.

• close() might be the right choice. The Evaluation section ofJava bug #4147525 says: "... call close() on the input and/oroutput stream. This will correctly result in the underlyingsocket being closed when you aren't doing keepaliveconnections and will correctly cache and reuse keepaliveconnections (and which will timeout and close themselvesafter a short time anyway)."

• But maybe not. Bug #4142971 says: "Calling the close()methods has no effect one way or the other on whether theunderlying HTTP connection is persistent."

Failing a clear answer, perhaps the HttpURLConnection objects could beadded to a list, and all disconnected at once at the end of the testrun. That'd still limit the total size of the run, but at least thelost descriptors wouldn't accumulate between runs.

Maybe the real answer is to give up on HttpURLConnection, and insteaduse the HTTP Client from Jakarta Commons. Someone suggested that inconnection with a different problem (bug#4143518).