2015-05-13 2 views
5

Я выполнял нагрузочное тестирование для моих API REST с использованием JMeter.Как разрешить ошибку java.net.SocketException: Слишком много открытых файлов

Я получаю следующее сообщение об ошибке при ударе с 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 
     } 
    } 
} 
+0

ли http://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux помощь? – immibis

+0

Похоже, что файлы не закрыты. Отправьте свой код здесь. –

+1

Возможно, вы создали много сокетов, но не закрыли() их. Я думаю, что максимальный максимум для открытых файлов и/или сокетов на машинах Linux равен 1024. –

ответ

4

Вы, конечно, открыть максимальное количество открытых файлов/сокетов. Максимальное количество открытых файлов или сокетов на машинах Linux по умолчанию равно 1024. Вы должны это изменить. Вы можете передать этот java.net.SocketException Too many open files

Вы можете использовать ниже запрос, чтобы проверить с вашего терминала, чтобы получить максимальное количество разрешенных открытых файлов

ulimit -n 

От here:

То, что происходит в том, что основные разъемы не закрываются, и, в конечном итоге, JVM сталкивается с лимитом для каждого процесса на дескрипторах открытых файлов.

Правильное решение должно заключаться в том, чтобы сокеты закрывались справа Время (что, я думаю, когда или вскоре после этого сервер закрыл его конец соединения). Это сложно с HttpURLConnection. Это все очень смущен:

  • разъединение() только кажется, чтобы закрыть его сразу - или нет; Javadocs намеренно расплывчаты относительно того, что это на самом деле делает, и особенно когда он это делает.

  • закрыть() может быть правильный выбор. Раздел «Оценка» Ошибка Java # 4147525 говорит: «... вызвать close() на входе и/или выходном потоке. Это приведет к тому, что базовый разъем будет закрыт, если вы не выполняете keepalive соединений и будет правильно кэшировать и повторно использовать keepalive соединений (и в любом случае тайм-аут и закрытие через короткое время). "

  • Но, возможно, нет. Ошибка # 4142971 говорит: «Вызов методов close() не имеет никакого эффекта в том или ином режиме, если постоянное HTTP-соединение ».

При отсутствии четкого ответа, возможно, объекты HttpURLConnection могут быть добавлен в список, и все отсоединяется сразу по окончанию испытательного перспективы. Это все равно ограничит общий размер прогона, но, по крайней мере, потерянные дескрипторы не будут накапливаться между прогонами.

Возможно, реальный ответ - отказаться от HttpURLConnection, а вместо этого использовать HTTP-клиент из Jakarta Commons. Кто-то предположил, что в соединение с другой проблемой (ошибка #4143518).