<div id="readability-page-1" class="page"><div>
 Too many open files
 
 
 소켓 '파일'을 몰랐을 때의 위험
 
 
 
 </div><div v-pre="">
 
 <blockquote>
커버 이미지 출처: <a href="https://stablediffusionweb.com/">Stable diffusion</a> “swimming pool lane pattern”
</blockquote>
<h2 id="증상">증상</h2>
Spring framework로 만든 웹 애플리케이션에서 비동기로 HTTP 요청하는 기능을 개발하고 있었다.
요구 사항을 위해 동시에 1,000개 이상의 요청을 보낼 때가 있는데, <code>Too many open files</code> 에러가 발생했다.
작업 PC(Ubuntu 22.04)에서 문제 없이 동작하던 프로그램이
IDC에 위치한 서버(CentOS 7)에서는 <code>OutOfMemoryError</code>가 발생하면서 동작하지 않았다.
<div><pre tabindex="0"><code data-lang="sh">java.lang.OutOfMemoryError: unable to create new native thread
...
java.util.concurrent.ExecutionException: com.markruler.RuntimeException: request error
...
Caused by: java.net.SocketException: Too many open files
</code></pre></div><code>SocketException</code>인데 <code>Too many open files</code>? 이게 OOM?
이해되지 않았다.
문제를 정의하기 위해 먼저 이해부터 해야 했다.
<h2 id="분석">분석</h2>

근본적인 원인이 되는 <code>Too many open files</code>는
프로세스에서 열려 있는 파일 디스크립터의 수가 시스템 제한을 초과하면 발생한다.
로컬 환경(Ubuntu 22.04)에서 먼저 테스트해봤다.
<code>prlimit</code>를 이용해 현재 프로세스의 파일 디스크립터 제한을 확인한다.
기본적으로 4096이 설정되어 있었다.
<div><pre tabindex="0"><code data-lang="sh">RESOURCE DESCRIPTION SOFT HARD UNITS
NOFILE max number of open files 4096 1048576 files
</code></pre></div><code>ulimit</code>를 이용해 열 수 있는 파일 디스크립터 수를 제한한다.
그리고 <code>cat</code> 명령어를 실행하면 <code>Too many open files</code>가 발생한다.
<div><pre tabindex="0"><code data-lang="sh">cat /etc/os-release
# bash: start_pipeline: pgrp pipe: Too many open files
# ls: error while loading shared libraries: libselinux.so.1: cannot open shared object file: Error 24
</code></pre></div>다시 나갔다가 새로운 세션을 연다.
limit을 4로 설정하면 파일 내용이 정상적으로 출력된다.
하지만 에러가 발생한다.
<div><pre tabindex="0"><code data-lang="sh">cat /etc/os-release
# bash: start_pipeline: pgrp pipe: Too many open files
# PRETTY_NAME="Ubuntu 22.04.2 LTS"
# ...
</code></pre></div>5로 설정하면 에러가 발생하지 않고 정상적으로 출력된다.
<div><pre tabindex="0"><code data-lang="sh">cat /etc/os-release
# PRETTY_NAME="Ubuntu 22.04.2 LTS"
# ...
</code></pre></div>이유가 무엇일까?
<h2 id="파일-디스크립터-file-descriptor">파일 디스크립터 (File descriptor)</h2>
리눅스에서는 파일을 열면(open) 파일 디스크립터를 반환한다.
반환된 파일 디스크립터는 <code>fd_array</code>의 인덱스를 나타내며, 파일을 읽고 쓰는데 사용된다.
<div><pre tabindex="0"><code data-lang="c">// https://github.com/torvalds/linux/blob/v6.2/include/linux/sched.h#L1088
stuct task_struct {
 ...
 /* Filesystem information: */
 struct fs_struct *fs;

 /* Open file information: */
 struct files_struct *files;
 ...
};
</code></pre></div><div><pre tabindex="0"><code data-lang="c">// https://github.com/torvalds/linux/blob/v6.2/include/linux/fdtable.h#L49
/*
 * Open file table structure
 */
struct files_struct {
 ...
 struct file __rcu * fd_array[NR_OPEN_DEFAULT];
};
</code></pre></div><code>fd_array</code> 배열의 첫 번째 인덱스[0]는 표준 입력(<code>stdin</code>), 두 번째 인덱스[1]는 표준 출력(<code>stdout</code>).
세 번째 인덱스[2]는 표준 에러(<code>stderr</code>)다.
네 번째 인덱스[3]부터 어떤 작업을 수행하는 프로세스가 필요한 파일을 가리킨다.
그래서 <code>ulimit -n 4</code>로 설정하면 정상적으로 <code>cat</code>의 출력이 나오는 것이다.
다시 문제로 돌아가서 그럼 <code>java.net.SocketException: Too many open files</code>는 왜 발생했던 걸까?
Linux에서는 Socket도 파일로 취급한다.
그래서 소켓을 열 때마다 파일 디스크립터가 증가하고,
시스템 제한을 초과하면 <code>Too many open files</code> 에러가 발생하는 것이다.
문제가 발생했던 서버의 시스템 제한을 확인해봤다.
SOFT 값이 1024로 1024개의 파일 디스크립터를 열 수 있다.
<div><pre tabindex="0"><code data-lang="sh">RESOURCE DESCRIPTION SOFT HARD UNITS
NOFILE max number of open files 1024 1048576 files
</code></pre></div>이 제한을 늘리면 문제가 해결될 것 같았다.
그런데 다시 생각해보면 1024 만큼의 요청이 발생할 필요 없는 서버였다.
갑자기 요청이 늘어난 원인이 무엇일까?
혼자가 아닌 함께 개발할 때,
내가 사용하려는 인터페이스가 이미 팀 내에서 통용되어 사용되고 있다면
해당 소스 코드를 복사해서 사용하는 경우가 많았다.
<code>OkHttpClient</code>도 그대로 복사해서 사용했었다.
<div><pre tabindex="0"><code data-lang="java">OkHttpClient client = new OkHttpClient();
</code></pre></div>하지만 <code>OkHttpClient</code>를 생성자로 생성하면 OkHttp ConnectionPool 스레드가 생성된다.
파일 개수 제한이 4096인 로컬 환경에서 4,000개의 요청을 보내도록 테스트해봤다.
<a href="https://markruler.github.io/posts/java/jvm-monitoring/#visualvm">VisualVM</a>을 사용해서 스레드를 확인해봤다.
<img src="https://markruler.github.io/images/java/too-many-open-files/visualvm-bad-okhttp-connectionpool.png" alt="visualvm-bad-okhttp-connectionpool">
OkHttp ConnectionPool의 스레드가 4,000개가 채 못 되어 <code>java.net.SocketException: Too many open files</code>이 발생했다.
<h2 id="문제-정의">문제 정의</h2>
실제 문제는 불필요한 스레드가 과다 생성되어 발생한 것이다.
이 에러가 특히 위험한 이유는 시스템 제한을 초과했기 때문에 동일한 머신에 있는 다른 프로세스에도 영향을 준다는 것이다.
<h2 id="해결">해결</h2>
<code>OkHttp ConnectionPool</code>을 재사용하기 위해 Spring Bean으로 등록했다.
이는 <a href="https://square.github.io/okhttp/4.x/okhttp/okhttp3/-ok-http-client/">공식 문서</a>에도 있는 내용이다.
<blockquote>
OkHttpClients Should Be Shared
 
OkHttp performs best when you create a single OkHttpClient instance
and reuse it for all of your HTTP calls.
This is because each client holds its own connection pool and thread pools.
Reusing connections and threads reduces latency and saves memory.
Conversely, creating a client for each request wastes resources on idle pools.
</blockquote>
<div><pre tabindex="0"><code data-lang="java">
```java
import okhttp3.OkHttpClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class OkHttpConfig {

 @Bean
 public OkHttpClient okHttpClient() {
 return new OkHttpClient();
 }

}
</code></pre></div><div><pre tabindex="0"><code data-lang="java">import okhttp3.OkHttpClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class MyHttpClient {

 private final OkHttpClient httpClient;

 @Autowired
 public MyHttpClient(OkHttpClient httpClient) {
 this.httpClient = httpClient;
 }

 // ...
}
</code></pre></div>다시 4,000개의 요청을 보내도록 테스트했다.
더 이상 불필요하게 스레드가 늘어나지 않았고,
스레드를 새로 생성할 필요도 없으니 성능 또한 개선되었다.
(평균 10초 → 3초)
시스템 제한 설정을 변경할 필요 없이
<code>Too many open files</code> 에러도 발생하지 않았다.
<img src="https://markruler.github.io/images/java/too-many-open-files/visualvm-okhttpclient-bean.png" alt="visualvm okhttpclient bean">

 
 
 
 
 </div></div>

임창수 블로그

Changsu

커버 이미지 출처: Stable diffusion “swimming pool lane pattern”
 증상 Spring framework로 만든 웹 애플리케이션에서 비동기로 HTTP 요청하는 기능을 개발하고 있었다. 요구 사항을 위해 동시에 1,000개 이상의 요청을 보낼 때가 있는데, Too many open files 에러가 발생했다. 작업 PC(Ubuntu 22.04)에서 문제 없이 동작하던 프로그램이 IDC에 위치한 서버(CentOS 7)에서는 OutOfMemoryError가 발생하면서 동작하지 않았다.
java.lang.OutOfMemoryError: unable to create new native thread ... java.util.concurrent.ExecutionException: com.markruler.RuntimeException: request error ... Caused by: java.net.SocketException: Too many open files SocketException인데 Too many open files?

Too many open files

댓글