4.3 커널을 사용한 스레드 생성이 "리소스를 일시적으로 사용할 수 없음"으로 인해 실패합니다.

4.3 커널을 사용한 스레드 생성이 "리소스를 일시적으로 사용할 수 없음"으로 인해 실패합니다.

저는 Arch Linux(커널 4.3.3-2)에서 여러 컨테이너가 있는 Docker 서버를 실행하고 있습니다. 마지막 재부팅 이후, 도커 서버와 컨테이너 모두의 임의 프로그램이 스레드를 생성할 수 없거나 (흔하지 않지만) 분기된다는 메시지와 함께 충돌했습니다. 구체적인 오류 메시지는 프로그램에 따라 다르지만 대부분 특정 오류를 언급하는 것 같습니다 Resource temporarily unavailable. 이 문서 끝부분에 있는 몇 가지 오류 메시지 예를 참조하세요.

이제 많은 사람들이 이 오류 메시지를 받았고, 많은 사람들이 이에 응답했습니다. 정말 답답한 점은 모두가 이 문제를 어떻게 해결할지 추측하고 있는 것 같은데, 누구도 그 방법을 지적하지 않는 것 같다는 것입니다.확인하다문제의 가능한 원인은 무엇입니까?

오류의 5가지 가능한 원인과 해당 오류가 내 시스템에서 발생하는지 확인하는 방법을 수집했습니다.

  1. /proc/sys/kernel/threads-max(원천). 제 경우에는 로 설정되어 있습니다 60613.
  2. 각 스레드는 스택에서 일부 공간을 차지합니다. 스택 크기 제한은 ulimit -s(원천). 예전에는 쉘의 한계가 있었는데 8192넣어서 늘려서 이제 돌아왔습니다. 나는 또한 이것을 넣어서 (* soft stack 32768/etc/security/limits.confulimit -s32768LimitSTACK=33554432/etc/systemd/system/docker.service원천, 그리고 docker 컨테이너 내부를 보고 실행하여 /proc/<pid of docker>/limits이 제한이 적용되는지 확인했습니다 .ulimit -s
  3. 각 스레드에는 약간의 메모리가 필요합니다. 가상 메모리 제한은 를 사용하여 구성됩니다 ulimit -v. 내 시스템에서는 으로 설정되어 있으며 unlimited3GB 메모리 중 80%를 사용할 수 있습니다.
  4. 사용되는 프로세스 수에는 제한이 있습니다 ulimit -u. 이 경우 스레드는 프로세스로 간주됩니다(원천). 내 시스템에서는 제한이 로 설정되어 있으며 30306, docker 데몬과 docker 컨테이너 내부의 제한은 입니다 1048576. 현재 실행 중인 스레드 수는 실행 ls -1d /proc/*/task/* | wc -l또는 다음을 실행하여 확인할 수 있습니다 ps -elfT | wc -l(원천). 내 시스템에서는 700와 사이에 있습니다 800.
  5. 일부 계정에 따르면 열린 파일 수에 제한이 있습니다.원천s는 스레드를 생성할 때도 관련이 있습니다. 이 제한은 를 사용하여 구성됩니다 ulimit -n. 내 시스템과 내부 도커에서는 제한이 으로 설정되어 있습니다 1048576.lsof | wc -l원천), 내 시스템에서는 약 30000.

마지막 재부팅 전에는 커널 4.2.5-1을 실행 중이었는데 지금은 4.3.3-2를 실행 중인 것 같습니다. 4.2.5-1로 다운그레이드하면 모든 문제가 해결되었습니다. 이 문제를 언급하는 다른 게시물은 다음과 같습니다.이것그리고이것. 하나 열었어요아치 리눅스 버그 보고.

이 문제를 일으킬 수 있는 커널의 어떤 변화가 발생했습니까?


다음은 몇 가지 오류 메시지 예입니다.

Crash dump was written to: erl_crash.dump
Failed to create aux thread

 

Jan 07 14:37:25 edeltraud docker[30625]: runtime/cgo: pthread_create failed: Resource temporarily unavailable

 

dpkg: unrecoverable fatal error, aborting:
 fork failed: Resource temporarily unavailable
E: Sub-process /usr/bin/dpkg returned an error code (2)

 

test -z "/usr/include" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/include"
/bin/sh: fork: retry: Resource temporarily unavailable
 /usr/bin/install -c -m 644 popt.h '/tmp/lib32-popt/pkg/lib32-popt/usr/include'
test -z "/usr/share/man/man3" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/share/man/man3"
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: Resource temporarily unavailable
/bin/sh: fork: Resource temporarily unavailable
make[3]: *** [install-man3] Error 254

 

Jan 07 11:04:39 edeltraud docker[780]: time="2016-01-07T11:04:39.986684617+01:00" level=error msg="Error running container: [8] System error: fork/exec /proc/self/exe: resource temporarily unavailable"

 

[Wed Jan 06 23:20:33.701287 2016] [mpm_event:alert] [pid 217:tid 140325422335744] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread

답변1

이 질문의 원인은 다음과 같습니다.TasksMax시스템 속성. 이는 systemd 228에 도입되었으며 Linux 커널 4.3에 도입된 cgroups pid 하위 시스템을 활용합니다. 512커널 4.3 이상이 실행 중인 경우 systemd에서 작업 제한이 활성화됩니다. 이 기능이 발표되었습니다.여기그리고 소개받다이 풀 요청기본값은 다음과 같이 지정됩니다.이 풀 요청. 커널을 4.3으로 업그레이드한 후 systemctl status docker다음 줄이 나타납니다 Tasks.

# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/etc/systemd/system/docker.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2016-01-15 19:58:00 CET; 1min 52s ago
     Docs: https://docs.docker.com
 Main PID: 2770 (docker)
    Tasks: 502 (limit: 512)
   CGroup: /system.slice/docker.service

섹션 의 설정으로 TasksMax=infinity문제가 해결되었습니다. 일반적으로 에 위치하지만 패키지 관리자가 덮어쓰는 것을 방지하기 위해 배치/복사할 수도 있습니다.[Service]docker.servicedocker.service/usr/share/systemd/system/etc/systemd/system

풀 리퀘스트TasksMaxdocker 예제 systemd 파일이 증가하고 있으며아치 리눅스 버그 보고이 패키지에서도 동일한 목표를 달성하려고 합니다. 일부 추가 논의가 진행 중아치 리눅스 포럼에서그리고lxc에 대한 Arch Linux 버그 보고서에서.

DefaultTasksMax[Manager]섹션 /etc/systemd/system.conf(또는 사용자가 실행하는 서비스)을 사용하여 /etc/systemd/user.conf제어할 수 있는 기본값입니다 TasksMax.

Systemd는 또한 로그인 셸에서 실행되는 프로그램에 제한을 적용합니다. 이는 각 사용자에게 기본값으로 적용 4096됩니다(증가하다12288) 다음과 같이 구성되었습니다.UserTasksMax일부 .[Login]/etc/systemd/logind.conf

답변2

cdauth의 답변은 정확하지만 추가해야 할 또 다른 세부 사항이 있습니다.

systemd 229 및 4.3 커널이 있는 Ubuntu 16.04 시스템에서는 UserTasksMax가 새롭게 증가된 기본값인 12288로 설정된 경우에도 기본적으로 세션 범위에 512 pid 제한이 적용됩니다. 따라서 모든 사용자 세션 범위는 512개 스레드로 제한됩니다.

제한을 제거하는 유일한 방법은 설정 DefaultTasksMax=unlimited/etc/systemd/system.conf( systemctl daemon-reexec또는 재부팅)입니다.

systemctl status세션 범위를 발행하고 선택하여 이러한 일이 발생하는지 확인할 수 있습니다 cat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max.

답변3

읽고 나서이것철사.

이 솔루션은 저에게 효과적이었습니다. docker -d --exec-opt native.cgroupdriver=cgroupfs.실제로 이것을 추가 OPTIONS했습니다 /etc/sysconfig/docker...

답변4

[3178:4:0817/094911.485035:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11)

podman run매개변수를 사용하여 --pids-limit=-1이 문제를 해결할 수 있었습니다.

관련 정보