184の環境変数が多すぎますか？
OSの不安定さの原因を突き止めようとしていますが、環境変数が気になります。
私が手渡したソフトウェアは、信じられないほど大量の環境変数をユーザーの.profileに入れます。
set | wcと入力すると、結果は9571バイトの長さになります！184個のエントリがあります。私には、これは非常に大きいように見えますが、「xyzのため、これは間違っています」と指摘して言う明確なものは何もありません。
limitドキュメント には、環境変数の合計サイズについては何も表示されていませんが、心配しています。全体的なメモリ使用率については心配していませんが（必要なことを実行するのに十分です）、内部制限を超えてOSで奇妙な動作を引き起こすことを心配しています（おそらく質問Iに密接に関係していません質問ですが、「奇妙な動作」とは、共有メモリキューが、もう一方の端に入力したすべてのデータを返してくれないことです。約5％の出力が得られます）。
起動するすべてのスクリプト、実行されるすべてのシェル、および実行されるすべてのバイナリは、環境変数の完全な個別のコピーを取得します。9kは大きすぎると思います。 これは心配ですか、それとも私は何も心配していませんか？
半分ギガバイトのRAMを搭載した組み込みx86QNX 6.4.1Neutrinoシステムで実行しています。
Setと入力すると| wc結果は9571バイトの長さです！
その数が正しいと仮定すると、おそらくQNXを使用しているため、実際にはかなりsmallです。通常のデスクトップシステムでは、はるかに大きくなります。これが私がFedora20で得たものです：
> set | wc --bytes
133195
133kB。それらの多くはソース関数であるため（gitはこれらの多くをインストールしているようです）、エントリを数えませんでしたが、それらをざっと見て、不利なことは何もないようです。せいぜい数kBは、私がカスタムしたものです。
内部制限を超えてOSで奇妙な動作を引き起こすのではないかと心配しています
境界チェックがないことは、実装に非常に重大なバグがあることを示しているため、これが可能かどうかは非常に疑わしいです。誰かが長い変数を書き込んでデータをメモリに挿入できないようにすることが基本的な懸念事項でした。それを超えて、あなたが言うように、9kBはメモリに関して何も賢明ではありません。これらのルックアップはハッシュテーブルを使用して行われると思いますので、エントリの数によってパフォーマンスが低下することはありません。
setは、環境変数だけでなく、シェル変数、および一部のシェルでは関数も報告します。 env | wc -cを使用して、環境のサイズを取得します。
環境サイズは、execveへの引数の最大サイズ（環境とコマンドライン引数で構成されます）によって間接的に制限されます。この制限の該当する値は、getconfARG_MAXで取得できます。
3849バイトは特に高くはないようです。 POSIXによると、制限は4096バイトまで低くすることができますが、512 MBのRAMを使用すると、システムはローエンドではなく、さらに多くの容量を許可するように設定されている可能性があります。いずれにせよ、その制限に達した場合、execveは失敗します。これは共有メモリキューとは何の関係もありません。