Unix进程能打开的最大文件数

  1. ulimit -n可以设置和查询当前进程能打开的最大文件数:
# ulimit -n 65536
# ulimit -n
65536
  1. 有些Unix系统还保留OPEN_MAX定义,但其实已经没用了。比如Linux系统就完全移除了OPEN_MAX

  2. 在程序中使用sysconf(_SC_OPEN_MAX)getrlimit来获得进程能打开的最大文件数。

参考:
Advanced Programming in the UNIX Environment: Week 02, Segment 1 – File Descriptors

查看Unix/Linux文件的inode

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/Linux进程内存分布

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

通过查看进程的内存分布,可以了解哪些地址是有效的,可写的;这对于调试有一定帮助。

Tmux简明手册

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

参考资料:
A Gentle Introduction to tmux
tmux cheatsheet

使用uptime命令检查Unix系统的负载状况

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个值分别是系统在过去1515分钟负载的平均值(这里的负载包含3种进程:当前正在被CPU执行的,一切条件就绪等待CPU调度的,和等待磁盘读取结果的)。衡量当前系统是否“过载”,需要把load averageCPU的数量结合起来考虑。如果load average的值是1,并且当前系统上只有一个CPU(需要注意,这里的CPU指一个“逻辑CPU”,即需要考虑物理CPU有多个core,每个core支持hyper-thread的情况),那么系统在过去的时间就是“满负荷”运转的。但是如果系统上有4CPU,那么系统就只有1 / 4 = 25%的时间是忙碌的,其余75%是空闲的。

Linux系统的uptime读取/proc/loadavg文件:

$ cat /proc/loadavg
12.97 11.53 11.33 12/3958 7094

前三项对应uptimeload average的输出。第四项中斜线前面的是活跃的kernel进程(线程)数,后面则是系统所有的kernel进程(线程)数。最后一项是系统最新产生的进程ID

对于OpenBSD来说,由于其没有/proc文件系统。它的uptime实现则是通过sysctl系统调用读取vm.loadavg的值。

使用OpenBSD一年的总结

我从去年8月份起开始尝试使用OpenBSD,到现在已经有一年多的时间了,是时候做一个简单的分享了。

首先介绍一下我使用的OpenBSD版本。刚开始的时候,我使用的都是-release的版本。后来为了编译最新的源代码,就切换到了-current版本,也就是当前开发的版本。曾经有人评价说OpenBSD-current版本比有些软件的-release还要稳定,这也从另一个角度说明OpenBSD代码的质量很高。但是如果你真的打算在商用环境下使用-current版本,还是谨慎为妙,因为我就碰到过用了-current版本,系统无法启动的情况;此外也有过代码回滚的先例。所以如果你的系统很重要,在使用-current版本之前还是先找另外一台机器测试一下,这样比较保险。

谈完了我使用的版本,再聊一下我使用OpenBSD的主要用途:

(1)一本好的Unix教材。OpenBSDman手册和代码质量都很高。所以当我想深入了解一个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的体系最熟悉,所以这个lscpuX86平台上可以显示详尽的信息,但是对于其他的处理器,比如ARM,只能显示基本的信息。

b)为OpenBSD”量身定制“了一个free命令。

c)libtlscppOpenBSD自带libtlsC++封装:用户不用再操心相关资源释放,甚至不用太了解TLS协议,就可以写出TLS应用程序。

(4)移植程序。如果发现有好的开源工具不支持OpenBSD平台,我也会尝试着去移植过来,比如google/benchmark,我就把它移植到了OpenBSD上。

补充说明:OpenBSD另一个被人称道之处的是安全性,这个网上可以搜索到很多文章。此外,我并没有把OpenBSD当做一个日常办公环境,所以对OpenBSD是否是一个适合大众的操作系统这一话题也没什么发言权。

以上就是我使用OpenBSD一年的总结。

Linux Journal停刊了,BSD magazine还在继续。。。

2017年最后一个月里,发生了两件事:

(1)121日,从1994年创刊的Linux Journal杂志宣布停刊了(参考Linux Journal Ceases Publication),这本历史最悠久的Linux杂志正式退出了历史舞台。我个人觉得很是惋惜,有时搜索一些信息时,经常可以搜到Linux Journal的文章,虽然年代有些久远,但是内容依旧适用。

(2)昨天,也就是1231日,BSD Magazine发布了第100期。这个去年一度要停办的杂志,还是坚持了下来,我也希望它越办越好。我很喜欢每期里关于采访程序员的栏目,这可以让我了解其他国家软件工程师的日常生活和工作经历。此外,每期也会有一些当前的热点内容,比如这一期就介绍了比特币的背景和在FreeBSD上如何安装bitcoind程序。BSD Magazine是免费的,因此如果你对BSD感兴趣,可以考虑订阅一下。一分钱不花,学到新知识,何乐而不为?

如何计算进程占用的物理内存

How to get the process resident set size一文不仅介绍了在WindowsUnix(包括LinuxBSDmacOS等等)操作系统上如何获取进程所使用的峰值和实时物理内存,并提供了现成的代码。在这里我只分析一下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