UNIX 上的进程大小
在 Solaris、HP-UX 和 AIX 上获取进程大小的正确方法是什么？ 我们应该使用 top 或 ps -o vsz 还是其他东西？
What is the correct way to get the process size on Solaris, HP-UX and AIX? Should we use top or ps -o vsz or something else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我总结了所有这样的进程的驻留集大小（作为 root）：
I summed up the resident set size for all processes like this (as root):
是的，你锁定 VSZ 是对的。
ps u将为您提供 VSZ 和 RSS，它们是虚拟内存大小和驻留集大小。 RSS 是已分配给进程的物理内存大小，VSZ 是进程的虚拟内存大小。 如果您有一个程序的多个副本正在运行，则 VSZ 中的大量内存将在这些进程之间共享。Yes, you are right to lock at the VSZ.
ps uwill give you the VSZ and RSS, which are the virtual memory size and resident set size. The RSS is how much physical memory has been allocated to the process, and the VSZ is the virtual memory size of the process. If you have several copies of a program running, a lot of the memory in the VSZ will be shared between those processes.在 Solaris 上，您可以使用
pmap命令获取有关进程内存使用情况的详细信息。 特别是，pmap -x显示了进程共享的内存量以及该进程专门使用的内存量。 这对于计算进程的“边际”内存使用量非常有用——通过这种技术，您可以避免重复计算共享库。On Solaris, you can get detailed information on a process's memory usage with the
pmapcommand. In particular,pmap -x <pid>shows you how much of a process's memory is shared and how much is specifically used by that process. This is useful for working out the "marginal" memory usage of a process -- with this technique you can avoid double-counting shared libraries.vsize、rss、rprvt、rshrd和其他看起来晦涩难懂的缩写的确切定义因操作系统而异。操作系统。top和ps命令的手册页会有某种描述，但所有这些描述都被大大简化了（或者基于早已灭绝的内核实现）。< br>在一般情况下，“流程规模”作为一个概念很难确定。 特定实例中的答案在很大程度上取决于操作系统中实际的内存管理实现，并且很少像大多数用户（和大多数开发人员）心中存在的整洁的“进程大小”概念那样令人满意。
例如，这些数字（也可能是它们的任何组合）都不能用来准确告诉您在给定的可用内存量中可以同时运行多少个此类进程。 但实际上，你最好的选择是从这一点出发：你为什么想要这个数字，你将用它做什么？ 有了这些信息，我想您会得到更有用的答案。
The exact definitions of
vsize,rss,rprvt,rshrd, and other obscure-looking abbreviations vary from OS to OS. The manual pages for thetopandpscommands will have some sort of description, but all such descriptions are simplified greatly (or are based on long-extinct kernel implementations)."Process size" as a concept is fiendishly difficult to pin down in the general case. Answers in specific instances depend heavily on the actual memory management implementation in the OS, and are rarely as satisfying as the tidy "process size" concept that exists in the minds of most users (and most developers).
For example, none of those numbers (nor, likely, any combination of them) can be used to tell you exactly how many such processes can run at once in a given amount of free memory. But really, your best bet is to come at it from that end: why do you want this number, and what will you use it for? Given that information, I think you'll get more useful answers.