184 环境变量太多?

184 环境变量太多?

我试图找到一些操作系统不稳定的原因,并且担心环境变量。

我收到的软件将大量的环境变量放入用户的.profile.

当我输入的set | wc结果是9571 字节长!有 184 个条目。对我来说,这似乎非常大,但我没有任何明确的指出并说“这是错误的,因为 xyz”。

我在其中什么也没看到ulimit 文档这谈到了环境变量总大小,但我很担心。我不担心整体内存利用率(有足够的空间来做我需要的事情),但我担心超出一些内部限制并导致操作系统出现奇怪的行为(可能与我问的问题没有密切关系,但“奇怪的行为”是共享内存队列没有返回我在另一端输入的所有数据。我得到了大约 5% 的收益)。

每个启动的脚本、运行的每个 shell 以及运行的每个二进制文件都会获得环境变量的完整、单独的副本,我认为 9k 太大了。这应该是一个担忧,还是我什么都不担心?

我正在一个具有半 GB RAM 的嵌入式 x86 QNX 6.4.1 Neutrino 系统上运行。

答案1

当我输入 set | 时wc 结果是 9571 字节长!

假设你得到的数字是正确的,它实际上是相当的小的,可能是因为您使用的是 QNX。在普通的桌面系统上,它要大得多。这是我在 fedora 20 上得到的结果:

> set | wc --bytes
133195

133 KB。我没有计算条目数,因为其中许多都是源函数(git似乎安装了很多这样的函数),但我确实浏览了它们,似乎没有任何问题。最多几 kB 是我自定义的东西。

我担心超出某些内部限制并导致操作系统出现奇怪的行为

我非常怀疑这是可能的,因为缺乏边界检查将表明实现中存在非常重要的错误 - 阻止某人只编写长变量将数据注入内存必须是一个基本问题。除此之外,正如你所说,9kB 与内存无关。我假设对这些的查找是通过哈希表完成的,因此条目的数量不会影响性能。

答案2

set不仅报告环境变量,还报告 shell 变量,在某些 shell 上还报告函数。用于env | wc -c获取环境的大小。

环境大小间接受到参数最大大小execve(由环境加上命令行参数组成)的限制。您可以使用 获取此限制的适用值。getconf ARG_MAX

3849字节看起来并不是特别高。 POSIX 表示限制可以低至 4096 字节,但对于 512MB RAM,您的系统并不是低端系统,并且可能设置为允许更多。无论如何,如果达到了这个限制,那么execve就会失败;这与共享内存队列无关。

相关内容