OSが不安定になる原因を探そうとするが、環境変数のため悩みになります。
私が受け取ったソフトウェアは、ユーザーの.profile。
私が入力すると、set | wc結果は次のようになります。長さは9571バイトです！合計184文があります。私にとって、これは非常に大きいように見えますが、「xyzのためにこれは間違っています」と指摘し、言う明示的な内容はありません。
その中には何も見えません。ulimit ドキュメント環境変数全体のサイズについての話ですが、それが心配ですね。全体的なメモリ使用量（必要な作業を実行するのに十分なスペースがある）は心配されませんが、一部の内部制限を超えてOSが奇妙に機能することは心配です（おそらく私が尋ねる質問と密接に関連していないかもしれませんが、「奇妙な振る舞い」は、共有メモリキューが私が反対側に置いたすべてのデータを返さないということです。 5％ほど受けました。）。
すべてのスクリプトが起動し、すべてのシェルが実行され、すべてのバイナリ実行が環境変数の完全な別々のコピーを取得するため、9kは大きすぎると思います。これが問題でなければならないか、または何も気遣わないか。
私は0.5GBのRAMを搭載した組み込みx86 QNX 6.4.1 Neutrinoシステムで動作しています。
答え1
set | wcと入力すると結果は9571バイトです！
あなたが得た数字が正しいと仮定すると、実際にはかなりそうです。小さい、おそらくQNXを使っているからでしょう。一般的なデスクトップシステムでははるかに大きいです。これが私がfedora 20で得た結果です。
> set | wc --bytes
133195
133KB。ソース機能が多くて（たくさんインストールされているようですが）項目を数えていないのですが、git見てみると特に問題はないようです。最大数kBまで私のカスタムアイテムです。
一部の内部制限を超えて、オペレーティングシステムが奇妙に動作するかどうかを心配しています。
境界チェックが不足すると、実装に非常に重要なバグがあることを示しているため、これが可能かどうか疑問に思います。誰かがメモリにデータを注入するために長い変数を書くのを防ぐことは根本的な問題であるに違いありません。それ以外の言葉通り、9kBはメモリとは関係ありません。私はこれらのクエリがハッシュテーブルを介して行われると仮定しているので、アイテムの数はパフォーマンスに影響を与えません。
答え2
set環境変数だけでなく、シェル変数と一部のシェルの場合、関数も報告されます。env | wc -c環境のサイズを取得するために使用されます。
環境サイズは、最大パラメータサイズexecve（環境とコマンドラインパラメータで構成される）によって間接的に制限されます。を使用して、この制限に適用可能な値を取得できます。getconf ARG_MAX
3849バイトは特に高いようではありません。 POSIXでは、制限は4096バイトまで低くなる可能性がありますが、512 MBのRAMを使用すると、システムは低コストではなく、より多くを可能にするように設定できると言います。それにもかかわらず、この制限に達するとexecve失敗します。これは共有メモリキューには関係ありません。