☰

4.3 カーネルを使用したスレッドの生成は、「リソースを一時的に使用できない」ため失敗します。

tag-icon • tag-icon linux docker limit fork thread
4.3 カーネルを使用したスレッドの生成は、「リソースを一時的に使用できない」ため失敗します。

私はArch Linux（カーネル4.3.3-2）で複数のコンテナを持つDockerサーバーを実行しています。最後の再起動後、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にダウングレードすると、すべての問題が解決されました。この問題に言及する他の投稿は次のとおりです。これそしてこれ。一つ開いたArch Linuxのバグレポート。

この問題を引き起こす可能性があるカーネルにどのような変化がありましたか？

以下は、いくつかのエラーメッセージの例です。

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 ファイルが増えていますArch Linuxのバグレポートこのパッケージでも同じ目標を達成しようとしています。いくつかの追加議論が進行中Arch LinuxフォーラムでそしてlxcのArch Linuxのバグレポートから。

DefaultTasksMax[Manager]セクション/etc/systemd/system.conf（またはユーザーが実行するサービス）を使用して/etc/systemd/user.conf制御できるデフォルト値TasksMax。

Systemd は、ログインシェルで実行されるプログラムに制限を適用します。これは各ユーザーにデフォルトとして適用され4096ます（増加する12288) 次のように構成されています。UserTasksMaxいくつか[Login]。/etc/systemd/logind.conf

おすすめ記事