Tạo chủ đề không thành công với Tài nguyên trong thời gian tạm thời không có sẵn với kernel 4.3

Tôi đang chạy một máy chủ docker trên Arch Linux (kernel 4.3.3-2) với một số container. Kể từ lần khởi động lại cuối cùng của tôi, cả máy chủ docker và các chương trình ngẫu nhiên trong vùng chứa đều gặp sự cố với thông báo về việc không thể tạo luồng hoặc (ít thường xuyên hơn) để rẽ nhánh. Thông báo lỗi cụ thể là khác nhau tùy thuộc vào chương trình, nhưng hầu hết trong số họ dường như đề cập đến lỗi cụ thể Resource temporarily unavailable. Xem ở cuối bài này cho một số thông báo lỗi ví dụ.

Bây giờ có rất nhiều người đã có thông báo lỗi này và rất nhiều phản hồi cho họ. Điều thực sự gây thất vọng là mọi người dường như đang suy đoán vấn đề có thể được giải quyết như thế nào, nhưng dường như không ai chỉ ra cách xác định nguyên nhân nào trong số nhiều nguyên nhân có thể gây ra sự cố.

Tôi đã thu thập 5 nguyên nhân có thể gây ra lỗi này và cách xác minh rằng chúng không có trên hệ thống của tôi:

1. Có giới hạn trên toàn hệ thống về số lượng luồng được cấu hình trong /proc/sys/kernel/threads-max( nguồn ). Trong trường hợp của tôi, điều này được đặt thành 60613.
2. Mỗi chủ đề có một số không gian trong ngăn xếp. Giới hạn kích thước ngăn xếp được cấu hình bằng cách sử dụng ulimit -s( nguồn ). Giới hạn cho vỏ của tôi đã từng 8192, nhưng tôi đã tăng nó bằng cách đưa * soft stack 32768vào /etc/security/limits.conf, vì vậy ulimit -sbây giờ nó trở lại 32768. Tôi cũng đã tăng nó cho quy trình docker bằng cách đưa LimitSTACK=33554432vào /etc/systemd/system/docker.service( nguồn và tôi đã xác minh rằng giới hạn áp dụng bằng cách xem xét /proc/<pid of docker>/limitsvà chạy ulimit -sbên trong một container docker.
3. Mỗi chủ đề mất một số bộ nhớ. Giới hạn bộ nhớ ảo được cấu hình bằng ulimit -v. Trên hệ thống của tôi, nó được đặt thành unlimitedvà 80% bộ nhớ 3 GB của tôi là miễn phí.
4. Có giới hạn về số lượng quy trình sử dụng ulimit -u. Chủ đề được tính là quá trình trong trường hợp này ( nguồn ). Trên hệ thống của tôi, giới hạn được đặt thành 30306và đối với daemon docker và bên trong các container docker, giới hạn là 1048576. Số lượng chủ đề hiện đang chạy có thể được tìm thấy bằng cách chạy ls -1d /proc/*/task/* | wc -lhoặc bằng cách chạy ps -elfT | wc -l( nguồn ). Trên hệ thống của tôi, chúng nằm giữa 700và 800.
5. Có giới hạn về số lượng tệp đang mở, theo một số nguồn cũng có liên quan khi tạo chủ đề. Giới hạn được cấu hình bằng cách sử dụng ulimit -n. Trên hệ thống của tôi và bên trong docker, giới hạn được đặt thành 1048576. Số lượng tệp đang mở có thể được tìm thấy bằng cách sử dụng lsof | wc -l( nguồn ), trên hệ thống của tôi 30000.

Có vẻ như trước lần khởi động lại cuối cùng tôi đã chạy kernel 4.2.5-1, bây giờ tôi đang chạy 4.3.3-2. Hạ cấp xuống 4.2.5-1 khắc phục tất cả các vấn đề. Các bài viết khác đề cập đến vấn đề này và điều này . Tôi đã mở một báo cáo lỗi cho Arch Linux .

Điều gì đã thay đổi trong kernel có thể gây ra điều này?

Dưới đây là một số thông báo lỗi ví dụ:

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

Vấn đề được gây ra bởi TasksMaxthuộc tính systemd. Nó được giới thiệu trong systemd 228 và sử dụng hệ thống con pid cgroups, được giới thiệu trong kernel linux 4.3. 512Do đó, giới hạn tác vụ được kích hoạt trong systemd nếu kernel 4.3 hoặc mới hơn đang chạy. Tính năng này được thông báo ở đây và được giới thiệu trong yêu cầu kéo này và các giá trị mặc định được đặt theo yêu cầu kéo này . Sau khi nâng cấp kernel của tôi lên 4.3, systemctl status dockerhiển thị một Tasksdòng:

# 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

Thiết lập TasksMax=infinitytrong [Service]phần docker.servicesửa lỗi. docker.servicethường ở trong /usr/share/systemd/system, nhưng nó cũng có thể được đặt / sao chép /etc/systemd/systemđể tránh bị ghi đè bởi trình quản lý gói.

Một yêu cầu kéo ngày càng tăng TasksMaxcho các ví dụ Docker systemd tập tin, và một báo cáo lỗi Arch Linux đang cố gắng để đạt được tương tự cho các gói. Có một số cuộc thảo luận bổ sung đang diễn ra trên Diễn đàn Arch Linux và trong một báo cáo lỗi Arch Linux liên quan đến lxc .

DefaultTasksMaxcó thể được sử dụng trong [Manager]phần trong /etc/systemd/system.conf(hoặc /etc/systemd/user.confcho các dịch vụ do người dùng điều hành) để kiểm soát giá trị mặc định cho TasksMax.

Systemd cũng áp dụng giới hạn cho các chương trình chạy từ shell đăng nhập. Các mặc định này cho 4096mỗi người dùng (sẽ được tăng lên12288 ) và được định cấu hình như UserTasksMaxtrong [Login]phần của /etc/systemd/logind.conf.

Câu trả lời của cdauth là đúng, nhưng có một chi tiết khác để thêm vào.

Trên hệ thống Ubuntu 16.04 của tôi với systemd 229 và kernel 4.3, giới hạn 512 pid được áp dụng theo phạm vi phiên theo mặc định ngay cả khi UserT taskMax được đặt thành mới, mặc định tăng 12288. Vì vậy, bất kỳ phạm vi phiên người dùng nào cũng bị giới hạn ở 512 luồng.

Cách duy nhất tôi tìm thấy để loại bỏ các giới hạn là để thiết lập DefaultTasksMax=unlimitedtrong /etc/systemd/system.confvà systemctl daemon-reexec(hoặc khởi động lại).

Bạn có thể kiểm tra xem điều này có xảy ra hay không bằng cách phát hành systemctl status, chọn phạm vi phiên và cat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max.

Sau khi đọc chủ đề này .

Giải pháp này hiệu quả với tôi : docker -d --exec-opt native.cgroupdriver=cgroupfs. Tôi thực sự đã thêm nó OPTIONSvào /etc/sysconfig/docker...