これ:
$ seq 100000 | xargs -P0 -n1 -I {} bash -c 'echo {};sleep {}'
:
5514
bash: fork: retry: No child processes
システムが11666個のプロセスを実行している場合、5500個あたりの文句が始まります。今11666は次の理由で私を驚かせます。
$ ulimit -u
313370
$ cat /proc/sys/kernel/pid_max
313370
$ grep hard.*nproc /etc/security/limits.conf
* hard nproc 313370
なぜ11600のプロセスしか実行できないのですか?
編集する:
他のユーザーとテストしてみると、6100個(つまり12200個のプロセス)があるため、合計24000個のプロセスがあります。したがって、制限はシステム全体には適用されません。
$ uname -a
Linux aspire 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ grep -i tasksmax /etc/systemd/*
/etc/systemd/logind.conf:#UserTasksMax=12288
/etc/systemd/system.conf:#DefaultTasksMax=
したがって、12288はおそらく犯人です。 1000に変更し、次の操作を行います。
sudo systemctl daemon-reexec
sudo systemctl restart systemd-logind
これで、以前にログインしていないユーザーとしてログインすると、新しい制限が適用されます。ただし、最後にログインしたユーザーとしてログインすると、最初のログイン時にアクティビティ制限が適用されます。したがって、制限はどこかにキャッシュされます。
上記の方法を使用して最大30,000のプロセスをテストしましたが、効果はありましたが、以前にログインしたことがないユーザーにのみ適用されました。
それでは、キャッシュの制限は何ですか
/etc/systemd/logind.conf
?このキャッシュをどのように更新できますか?
新しい制限は60000プロセス(おそらく予想された313370)よりはるかに高いです。
答え1
問題のシステムはsystemdとして実行されます。これを1つ使ってください。cgroupさまざまなプロセスグループにシステムリソースを割り当てます。
sysctlを設定できますkernel.sched_autogroup_enabled = 1
。これがcgroupを使用してシステムリソースを分割する2番目の方法です。
特定のユーザーに対してcgroupまたはcgroupグループが初期化されると、再起動するまで変更されていない可能性があります。
systemdによるか自動グループのためか、プロセス制限のためかメモリ制限(cgroup内)のためかどうかを確認する方法はなく、ソースコードから検索する方法もありません。答えの代わりにコメントしたいのですが、評判が足りません。