ulimit -n可以设置和查询当前进程能打开的最大文件数：# ulimit -n 65536
# ulimit -n
65536
有些Unix系统还保留OPEN_MAX定义，但其实已经没用了。比如Linux系统就完全移除了OPEN_MAX。
在程序中使用sysconf(_SC_OPEN_MAX)和getrlimit来获得进程能打开的最大文件数。
参考：
Advanced Programming in the UNIX Environment: Week 02, Segment 1 – File Descriptors。
Unix/Linux系统上可以使用stat命令查看文件的inode信息。NetBSD系统：
# stat -f %i foo
1400196
Linux系统：
# stat -c %i foo
277428
也可以使用ls命令：
# ls -i foo
1400196 foo
df命令可以显示整个文件系统的inode使用情况，仍以Linux为例：
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 55113 371 54742 1% /dev
tmpfs 61625 1 61624 1% /dev/shm
tmpfs 61625 371 61254 1% /run
/dev/sda1 524288 116074 408214 23% /
cgroup 61625 13 61612 1% /sys/fs/cgroup
tmpfs 61625 3 61622 1% /tmp
要注意inode的数量是预先分配好的。我曾经经历过的一个短信网关项目最初的设计的就是每条短信都存到一个文件里，结果很快就把inode用光了:-)。
在Unix平台，如果要查看某个进程的内存分布，可以使用gdb附着在该进程，再使用“info proc mappings”命令：
$ sudo gdb -p 1
......
(gdb) info proc mappings
process 1
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x400000 0x401000 0x1000 0x0 /usr/bin/runit
0x401000 0x480000 0x7f000 0x1000 /usr/bin/runit
0x480000 0x4aa000 0x2a000 0x80000 /usr/bin/runit
0x4ab000 0x4ae000 0x3000 0xaa000 /usr/bin/runit
0x4ae000 0x4b0000 0x2000 0x0
0x62d000 0x650000 0x23000 0x0 [heap]
0x7ffe5e3f3000 0x7ffe5e414000 0x21000 0x0 [stack]
0x7ffe5e4a4000 0x7ffe5e4a7000 0x3000 0x0 [vvar]
0x7ffe5e4a7000 0x7ffe5e4a8000 0x1000 0x0 [vdso]
另外在Linux系统上，也可以使用pmap命令：
$ sudo pmap -x 1
1: runit
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 4 4 0 r---- runit
0000000000401000 508 440 0 r-x-- runit
0000000000480000 168 124 0 r---- runit
00000000004ab000 12 12 12 rw--- runit
00000000004ae000 8 8 8 rw--- [ anon ]
000000000062d000 140 8 8 rw--- [ anon ]
00007ffe5e3f3000 132 12 12 rw--- [ stack ]
00007ffe5e4a4000 12 0 0 r---- [ anon ]
00007ffe5e4a7000 4 4 0 r-x-- [ anon ]
---------------- ------- ------- -------
total kB 988 612 40
通过查看进程的内存分布，可以了解哪些地址是有效的，可写的；这对于调试有一定帮助。
同screen类似，tmux也用来管理多个终端回话。常用的就是下面几个命令：
（1）创建新会话：
# tmux
创建时指定会话的名字（2是会话名字），多用于复用之前已经退出会话的名字：
# tmux new -s 2
（2）离开（detach）会话：先输入Ctrl + b，然后输入d。
（3）列出当前管理的所有会话（冒号前面的是会话名字）：
# tmux ls
0: 1 windows (created Wed Jul 3 15:08:44 2019) [88x29]
1: 1 windows (created Wed Jul 3 16:29:19 2019) [120x39]
（4）附着（attach）某个会话（2是会话名字）：
# tmux a -t 2
（5）杀死某个会话（2是会话名字）：
# tmux kill-session -t 2
Unix系统的uptime命令可以用来检查系统的负载状况。以Linux为例：
$ uptime
01:32:50 up 40 days, 3:09, 56 users, load average: 11.72, 11.67, 11.51
load average后面的3个值分别是系统在过去1，5和15分钟负载的平均值（这里的负载包含3种进程：当前正在被CPU执行的，一切条件就绪等待CPU调度的，和等待磁盘读取结果的）。衡量当前系统是否“过载”，需要把load average同CPU的数量结合起来考虑。如果load average的值是1，并且当前系统上只有一个CPU（需要注意，这里的CPU指一个“逻辑CPU”，即需要考虑物理CPU有多个core，每个core支持hyper-thread的情况），那么系统在过去的时间就是“满负荷”运转的。但是如果系统上有4个CPU，那么系统就只有1 / 4 = 25%的时间是忙碌的，其余75%是空闲的。
Linux系统的uptime读取/proc/loadavg文件：
$ cat /proc/loadavg
12.97 11.53 11.33 12/3958 7094
前三项对应uptime中load average的输出。第四项中斜线前面的是活跃的kernel进程（线程）数，后面则是系统所有的kernel进程（线程）数。最后一项是系统最新产生的进程ID。
对于OpenBSD来说，由于其没有/proc文件系统。它的uptime实现则是通过sysctl系统调用读取vm.loadavg的值。
我从去年8月份起开始尝试使用OpenBSD，到现在已经有一年多的时间了，是时候做一个简单的分享了。
首先介绍一下我使用的OpenBSD版本。刚开始的时候，我使用的都是-release的版本。后来为了编译最新的源代码，就切换到了-current版本，也就是当前开发的版本。曾经有人评价说OpenBSD的-current版本比有些软件的-release还要稳定，这也从另一个角度说明OpenBSD代码的质量很高。但是如果你真的打算在商用环境下使用-current版本，还是谨慎为妙，因为我就碰到过用了-current版本，系统无法启动的情况；此外也有过代码回滚的先例。所以如果你的系统很重要，在使用-current版本之前还是先找另外一台机器测试一下，这样比较保险。
谈完了我使用的版本，再聊一下我使用OpenBSD的主要用途：
（1）一本好的Unix教材。OpenBSD的man手册和代码质量都很高。所以当我想深入了解一个Unix工具时，我会选择阅读OpenBSD上的代码实现和相应的手册。我曾经花费大块的业余时间阅读netcat的代码，当然收获也颇丰：不仅全面复习了网络编程的相关知识，发现bug并提交patch，还写了一本介绍netcat的英文小册子。可以说”一举多得“！
（2）一个好的测试环境。OpenBSD在编译和运行程序时经常会给出一些其它系统无法提供的有用信息，这对及时发现和解决程序问题有着很大的帮助。比如下面程序：
#include <mutex>
int main(void)
{
std::mutex m;
m.lock();
return 0;
}
在Arch Linux上编译运行没有任何提示信息：
$ clang++ -g -pthread -std=c++11 test_mutex.cpp
$ ./a.out
$
但在OpenBSD上却给了如下提示：
# clang++ -g -pthread -std=c++11 test_mutex.cpp
# ./a.out
pthread_mutex_destroy on mutex with waiters!
此外，OpenBSD还曾经帮我找到了一个很难查的内存bug，相关内容可以参考这篇文章。
（3）OpenBSD系统还提供了一些有用的工具，比如tcpbench。我自己把它移植到Linux平台（代码在这里），方便自己使用。
来而不往非礼也，我不光只对OpenBSD进行“索取”，也给予“了回馈”：
（1）提交patch。这一年来提交了十几个patch，不过都是一些简单的bug修改。
（2）撰写教程。分享了一些使用OpenBSD的经验，希望可以帮助到有需要的使用者。
（3）开发工具：
a）Linux系统上有个很好用的lscpu命令，可惜BSD系统没有。我自己实现了一个针对BSD系统的lscpu命令。因为我个人对X86的体系最熟悉，所以这个lscpu在X86平台上可以显示详尽的信息，但是对于其他的处理器，比如ARM，只能显示基本的信息。
b）为OpenBSD”量身定制“了一个free命令。
c）libtlscpp，OpenBSD自带libtls的C++封装：用户不用再操心相关资源释放，甚至不用太了解TLS协议，就可以写出TLS应用程序。
（4）移植程序。如果发现有好的开源工具不支持OpenBSD平台，我也会尝试着去移植过来，比如google/benchmark，我就把它移植到了OpenBSD上。
补充说明：OpenBSD另一个被人称道之处的是安全性，这个网上可以搜索到很多文章。此外，我并没有把OpenBSD当做一个日常办公环境，所以对OpenBSD是否是一个适合大众的操作系统这一话题也没什么发言权。
以上就是我使用OpenBSD一年的总结。
在2017年最后一个月里，发生了两件事：
（1）12月1日，从1994年创刊的Linux Journal杂志宣布停刊了（参考Linux Journal Ceases Publication），这本历史最悠久的Linux杂志正式退出了历史舞台。我个人觉得很是惋惜，有时搜索一些信息时，经常可以搜到Linux Journal的文章，虽然年代有些久远，但是内容依旧适用。
（2）昨天，也就是12月31日，BSD Magazine发布了第100期。这个去年一度要停办的杂志，还是坚持了下来，我也希望它越办越好。我很喜欢每期里关于采访程序员的栏目，这可以让我了解其他国家软件工程师的日常生活和工作经历。此外，每期也会有一些当前的热点内容，比如这一期就介绍了比特币的背景和在FreeBSD上如何安装bitcoind程序。BSD Magazine是免费的，因此如果你对BSD感兴趣，可以考虑订阅一下。一分钱不花，学到新知识，何乐而不为？
How to get the process resident set size一文不仅介绍了在Windows和Unix（包括Linux，BSD，macOS等等）操作系统上如何获取进程所使用的峰值和实时物理内存，并提供了现成的代码。在这里我只分析一下Linux上相关功能的实现：
（1）获取峰值内存：
size_t getPeakRSS() {
struct rusage rusage;
getrusage(RUSAGE_SELF, &rusage);
return (size_t)(rusage.ru_maxrss * 1024L);
}
getrusage函数获取进程资源的使用情况。当第一个参数时RUSAGE_SELF时，表示得到当前进程的统计数据。struct rusage中的ru_maxrss即表示该进程物理内存的使用峰值，因为度量单位是kilobytes，故而需要乘以1024。
（2）获得实时内存：
size_t getCurrentRSS() {
long rss = 0L;
FILE* fp = NULL;
if ( (fp = fopen( "/proc/self/statm", "r" )) == NULL )
return (size_t)0L; /* Can't open? */
if ( fscanf( fp, "%*s%ld", &rss ) != 1 )
{
fclose( fp );
return (size_t)0L; /* Can't read? */
}
fclose( fp );
return (size_t)rss * (size_t)sysconf( _SC_PAGESIZE);
}
/proc/self/statm文件共包含7个字段，第二个即是进程当前时刻占用的物理内存，单位是页面大小。要获得精确的字节数，还需通过sysconf系统调用获得页面所占据的空间，通常为4096。