예전에 고객사에서 해당 값이 어떻게 측정되었는지 문의한 적이 있어 리서치 해 본 적이 있다.
사실 어떻게 설정하건 상관 없는데 너무 낮으면 문제가 생긴다. 가 결론
fs.file-max의 정의
참고 : file-max 매뉴얼
file-max is the maximum File Descriptors (FD) enforced on a kernel level, which cannot be surpassed by all processes without increasing. The ulimit is enforced on a process level, which can be less than the file-max.
간단히 얘기해서, 리눅스 커널이 동시에 열 수 있는 file handle의 갯수이다.
해당 갯수보다 많이 file handle open이 발생하면 에러가 발생하며, 해당 에러가 발생함.
EMFILE 24 Too many open files참고로 too many open files는 ulimit 등 설정에 의해서도 발생할 수 있으니, 에러 발생 시 체크해보는 것이 좋다. ulimit는 상기했듯 process level, fs.file-max는 시스템 레벨.
fs.file-max는 sysctl에서도 변경 가능하지만, /proc/sys/fs/file-max에서도 변경할 수 있다.
커널 값 설정때는 항상 그렇듯이, 이력을 볼 수 있는 sysctl.conf를 추천한다.
(example)
#> echo "8192" >/proc/sys/fs/file-max
#> cat /etc/sysctl.conf
# Improve the number of open files
fs.file-max = 8192
fs.file-max의 설정
어쨌거나... file-max를 설정을 하긴 해야 할 것인데, 어떻게 해야 할까?
사실은..file-max의 설정값은 뭐 어떻게 해도 상관이 없다.
참고 : https://serverfault.com/questions/122679/how-do-ulimit-n-and-proc-sys-fs-file-max-differ
일반적인 상황에서 file-max는 어떻게 잡아도 성능 이슈를 일으키지 않는다.
많이 설정한다고 해서 뭔가 더 자원을 잡아먹는 게 아니라는 뜻.
그럼, 어떤 값을 권장하고, 어떻게 계산해야 할까?
리눅스 2.6 커널에서 fs/file_table.c에 있던 항목을 참조하면 어느 정도 유추할 수 있다.
/*
* One file with associated inode and dcache is very roughly 1K.
* Per default don't use more than 10% of our memory for files.
*/
n = (mempages * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
애초에 file-max는 재컴파일을 통해서 적용되던 부분이지만, 커널 패치가 진행되며 property로 빠져 나온 부분이다. 그래서 default가 굉장히 낮게 잡혀 있기도 하고.
그렇다고 엄청나게 높은 값을 해 놓았을 경우 비정상적인 작동 시 대처할 수가 없으니, 해당 값을 권장하는 것이다.
해당 코드에 따르면 한 개의 file 크기를 1k로 잡고, 전체 open file의 크기가 메모리의 10% 미만일 것을 권장한다는 의미로 주석을 달아 놓았다.
그 설명에 따라 간단히 계산하는 방법은 이렇게 될 것이다.
fs.file-max = `free -k` / 10
별로 중요한 값은 아니지만, 그렇게 설정하게 된 과정을 보면 꽤 재미있다.
참고로, file-nr을 통해 현재 열린 파일의 갯수를 확인할 수 있다.
# cat /proc/sys/fs/file-nr
2432 0 9223372036854775807순서대로 열린 파일 수, 오픈되지 않은 파일 수, file-max 수치이다.
( wsl로 로컬에서 친 값인데 wsl은 굉장히 높게 잡혀 있는 듯 )
