マーベリックスの前は、/etc/launchd.conf
ファイル。システムリソースの最大消費量を変更します。次に例を示します。
limit maxfiles 16384 unlimited
limit maxproc 16384 unlimited
Mavericksでは動作しなくなりました。
OS Xの最新バージョンでそれを行う正しい方法は何ですか?
ファイル/etc/launchd.conf
を作成し、その中にコマンドを入れるとうまくいくようです。
機能しない場合は、おそらく/etc/rc.local
ファイルを編集または作成して、その中にコマンドを追加できます。Appleは、コマンドの制限のサポートを削除する可能性がほとんどないためです。ライン。
編集1:
それから始めるべきです、launchd
man page 次のファイルを参照してください:
~/Library/LaunchAgents Per-user agents provided by the user.
/Library/LaunchAgents Per-user agents provided by the administrator.
/Library/LaunchDaemons System-wide daemons provided by the administrator.
/System/Library/LaunchAgents Per-user agents provided by Mac OS X.
/System/Library/LaunchDaemons System-wide daemons provided by Mac OS X.
私の賭けは、コマンドを~/Library/LaunchAgents
または/Library/LaunchDaemons
のどちらかに置く必要があるということです。
両方を試す必要があります。
編集2:
launchdにはスクリプトだけでなくxmlファイルが必要であることにも注意してください。 GUIはそのようなタスクを支援するために設計されています自由ではありません1つは Lingon です。多分他の無料の製品が存在します。
これらの2行を.bash_profile
に追加しました
魅力のように機能します
ulimit -n 1024
ulimit -u 1024
/etc/launchd.conf
または/etc/rc.local
での制限の変更は、最近のmacOSではサポートされなくなりました。参照: 古いシステムとテクノロジー 。
代わりに、新しい起動エージェントを作成する必要があります。
以下は、PlistBuddy
コマンドを使用したコマンドの例です(man PlistBuddy
を参照):
Sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.launchd.maxfiles.plist \
-c "add Label string com.launchd.maxfiles" \
-c "add ProgramArguments array" \
-c "add ProgramArguments: string launchctl" \
-c "add ProgramArguments: string limit" \
-c "add ProgramArguments: string maxfiles" \
-c "add ProgramArguments: string 10240" \
-c "add ProgramArguments: string unlimited" \
-c "add RunAtLoad bool true"
maxproc
の制限についても同様です:
Sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.launchd.maxproc.plist \
-c "add Label string com.launchd.maxproc" \
-c "add ProgramArguments array" \
-c "add ProgramArguments: string launchctl" \
-c "add ProgramArguments: string limit" \
-c "add ProgramArguments: string maxproc" \
-c "add ProgramArguments: string 2000" \
-c "add ProgramArguments: string unlimited" \
-c "add RunAtLoad bool true"
上記のファイルをロードするには、Sudo launchctl load /Library/LaunchAgents/com.launchd.*.plist
を実行します。
ノート:
cat
またはPlistBuddy -x -c Print /Library/LaunchAgents/com.launchd.maxfiles.plist
を実行します。tail -f /var/log/system.log
を実行します。launchd
の制限を確認するには、launchctl limit
を実行します。.plist
file は、ユーザーごとまたはシステム全体のエージェントフォルダー(LaunchAgents
)に配置できます。詳細については、man launchd
および man launchd.plist
、または this または that の回答を参照してください。上記の Launchd システム制限はカーネルによって制限されているため、カーネル状態変数で設定されている実際の制限よりも高く設定することはできません(ヘルプ:man sysctl
を参照)。
現在のカーネル制限を確認するには、sysctl -a | grep ^kern.max
を実行します。
maxfiles
制限を増やすには、Sudo sysctl -w kern.maxfiles=20480
を実行します。
それらを永続化するには、同様の方法を使用して、スタートアップ.plist
ファイルを作成します。
Sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.kern.maxfiles.plist \
-c "add Label string com.kern.maxfiles" \
-c "add ProgramArguments array" \
-c "add ProgramArguments: string sysctl" \
-c "add ProgramArguments: string -w" \
-c "add ProgramArguments: string kern.maxfiles=20480" \
-c "add RunAtLoad bool true"
シェル制限については、関連するulimit
コマンドを、個々のユーザーの場合は~/.bashrc
または~/.bash_profile
スタートアップファイルに、すべてのユーザーの場合は/etc/bashrc
に追加します。参照: Macで永続的なシェルのulimit設定を追加する方法
追加する推奨行:
# Changes the ulimit limits.
ulimit -Sn 4096 # Increase open files.
ulimit -Sl unlimited # Increase max locked memory.
ulimit
(単一のプロセスが開くことができるファイル数の弱い制限)に達している単一のプログラムがある場合、ulimit
をより大きな数に調整すると、特に.bash_profile
にulimit
コマンドを置くだけです。さらに、いくつかの理由により、/etc/launchd.conf
や/etc/sysctl.conf
などのファイルを編集したり、/Library/LaunchDaemons/
の下にplistファイルを追加したりしないことを強くお勧めします。
これらのファイルへの変更はバックアップに残り、アップグレードすると、macOSの新しいバージョンと新しいコンピューターに引き継がれます。
これらの変更が問題を引き起こす場合(これは実際の可能性です)、変更を加えたこと、および変更内容を覚えてから、ファイルを再編集して元に戻します。これは数年後に起こります。
数年のアップグレードの後、以前は制限の増加であったものが現在は制限の減少であることに気付くかもしれません。ただし、(a)変更を行ったことを覚えておらず、(b)最初からオーバーロードしたために新しい制限を確認できないため、おそらくそれはわかりません。
一般に、システムの個々のパラメーターを調整してシステムのバランスを崩す(および単一のプログラムがすべてのリソースを占有することによってシステムをクラッシュさせる可能性がある)のではなく、デフォルトのシステム制限がニーズに不十分である場合は、調整することをお勧めします「サーバーパフォーマンスモード」、または少なくとも試してみてください。これに必要なのは、OS X/macOS 10.8 Mountain Lion以降で、少なくとも16 GiB搭載されているメモリです。早い段階でこれを支払う必要がありましたが、OS X 10.8 Mountain Lion以降、それは標準OSでは 無料で、Appleによって公式にサポートされています です。
このモードをオンにすると、システムの制限、特に実行できるプロセスの数と開くことができるファイルの数が劇的に増加しますが、システムカーネルにより多くのメモリが割り当てられます。サーバーパフォーマンスモードによって何が変更されるかについては、質問の回答 "serverperfmode = 1がmacOSで実際に何をするのか?" を参照してください。
このモードには、他の回答で提案されているように、構成ファイルを編集するよりもいくつかの利点があります。
サーバーパフォーマンスモードをオンにするには、ターミナルを使用して次のコマンドのいずれかを実行し、再起動して有効にします。
Sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"
そしてそれをオフにします
Sudo nvram boot-args="$(nvram boot-args 2>/dev/null | sed -e $'s/boot-args\t//;s/serverperfmode=1//')"
上記のコマンドは、Appleが公式に推奨するものですが、実際にはそれらに問題があります。つまり、「オンにする」コマンドを2回実行すると、「オフにする」コマンドを実行する必要があります。 "コマンドを2回実行してオフにします。実行して変更を加えた後、オンかオフかを確認してください
nvram boot-args
出力に「serverperfmode = 1」が含まれている場合は設定がオンになり、含まれていない場合は設定がオフになります。
serverinfo --setperfmode 1
そしてそれをオフにします
serverinfo --setperfmode 0
設定を確認してください
serverinfo --perfmode
この設定は、システムを再起動するまで有効になりません。
設定を確認すると、再起動後に有効になるように設定されているかどうかがわかります。現在アクティブであるかどうかをテストするには(私のアドバイスに従っていて、設定を変更する構成ファイルを編集していない場合)、次のコマンドを実行します。
sysctl kern.maxproc
システムが許可するプロセスの最大数である数値が表示されます。その数が 532の倍数 の場合、サーバーパフォーマンスモードはオフです。ラウンド数(2500の倍数)の場合、現在実行中のシステムでサーバーパフォーマンスモードがオンになります。