看了几篇文章，对linux的进程的内存占用，又有了一点认识，记录一下。

首先 ps 看一下我的系统跑着哪些process

$ ps aux
 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
czbug     1980  0.0  1.7 180472 34416 ?        Sl   Feb25   0:01 /usr/bin/yakuake
...

我拿 yakuake 这个小程序作例子。

其中，关于内存的是 VSZ 和 RSS 这两个

man ps 看看它们的含义：

rss       RSS    resident set size, the non-swapped physical memory that a task has used (in kiloBytes). (alias rssize, rsz).

vsz       VSZ    virtual memory size of the process in KiB (1024-byte units). Device mappings are currently excluded; this is subject to change. (alias vsize).

简单一点说，RSS 就是这个process 实际占用的物理内存，VSZ 就是process 的虚拟内存，就是process 现在没有使用但未来可能会分配的内存大小。

其实这里的ps 出来的结果，是有点不正确的，如果把所有程序的 RSS 加起来，恐怕比你的实际内存还要大呢。为什么呢？？因为 ps 的结果，RSS 那部分，是包括共享内存的。这里我用 pmap 来看看。

$ pmap -d 1980
 
1980:   /usr/bin/yakuake
Address   Kbytes Mode  Offset           Device    Mapping
00110000    2524 r-x-- 0000000000000000 008:00002 libkio.so.5.3.0
00387000       4 ----- 0000000000277000 008:00002 libkio.so.5.3.0
00388000      32 r---- 0000000000277000 008:00002 libkio.so.5.3.0
00390000      16 rw--- 000000000027f000 008:00002 libkio.so.5.3.0
00394000     444 r-x-- 0000000000000000 008:00002 libQtDBus.so.4.5.2
00403000       4 ----- 000000000006f000 008:00002 libQtDBus.so.4.5.2
00404000       4 r---- 000000000006f000 008:00002 libQtDBus.so.4.5.2
00405000       4 rw--- 0000000000070000 008:00002 libQtDBus.so.4.5.2
00407000     228 r-x-- 0000000000000000 008:00002 libkparts.so.4.3.0
00440000       8 r---- 0000000000039000 008:00002 libkparts.so.4.3.0
00442000       4 rw--- 000000000003b000 008:00002 libkparts.so.4.3.0
00443000    3552 r-x-- 0000000000000000 008:00002 libkdeui.so.5.3.0
007bb000      76 r---- 0000000000377000 008:00002 libkdeui.so.5.3.0
007ce000      24 rw--- 000000000038a000 008:00002 libkdeui.so.5.3.0
007d4000       4 rw--- 0000000000000000 000:00000   [ anon ]
....
mapped: 180472K    writeable/private: 19208K    shared: 20544K

我略去了一部分输出，都是差不多的，重点在最后那行输出。

linux 会把一些shared libraries 载入到内存中，在pmap 的输出中，这些shared libraries 的名字通常是 lib*.so 。如 libX11.so.6.2.0 。这个 libX11.so.6.2.0 会被很多process load 到自己的运行环境中，同时，ps 输出的RSS 结果中，每个process 都包含了这个libX11.so.6.2.0 ，而事实上它只被load 了一次，如果单纯把ps 的结果相加，这样就重复计算了。

而 pmap 的输出中，writeable/private: 19208K ，这个就是yakuake 这个程序真正占用的物理内存，不包含shared libraries 。在这里，它只有19208K，而ps 的RSS 是34416K。

————————————————————–

我在看这方面的资料时，还看到一些关于virtual memory 的，再记录下。

以下两个命令均可查看 vmsize 。

$ cat /proc/<pid>/stat | awk '{print $23 / 1024}'
$ cat /proc/<pid>/status | grep -i vmsize

一般来说，得出来的值，是和 ps 的 VSZ 是一样的，但有一种情况例外，就是查看X server 的时候。

举个例：

$ ps aux|grep /usr/bin/X|grep -v grep | awk '{print $2}'   # 得出X server 的 pid   ...
1076
 
$ cat /proc/1076/stat | awk '{print $23 / 1024}'
139012
 
$ cat /proc/1076/status | grep -i vmsize
VmSize:      106516 kB

而 ps 的 VSZ 为 106516 ，与后者是一致的。

据说是因为

VmSize = memory + memory-mapped hardware (e.g. video card memory).

这句话我不是很理解。。。就不作解释了。。。

对OS 的理解还很肤浅，还需努力啊。。。

今天维护一个集群系统时，被人报障说集群的机器时间不对。。。我去看了一下，crontab 里有对时的命令啊。再手动执行一下，才发现，原来被我设的防火墙给墙住了。。。机器只允许特定的外网ip访问，内网无限制。。。所以ntpdate 外面一些对时服务器的时候，根本不会收到返回了。

话说这个防火墙，也是其它部门的同事建议我设的，本部门的程序员对安全这些事情好不上心的，专心于系统功能的开发，甚至连我多次建议的系统管理经验也不采纳。算了，none of my business 。

而他们说这个系统对时，很急，要不集群间的机器heartbeat 时间不对，就会以为对方挂了的了。

那我就马上在另一台对外网无限制的机器上搭一个ntpd ，就作为一个对时服务器的代理吧。

安装ntpd，这个很简单，那台机器是 centos 5，那就用yum。

#yum install ntp

装好还不能用呢，最快速度使用上的话，那就只修改一行配置，因为默认是只允许本地对时而已，我们必须加上内网都可以对时

#vi /etc/ntp.conf

把下面这行，取消注释，并加上自己网段的相关信息即可

#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

如：

restrict 10.100.20.0 mask 255.255.255.0 nomodify notrap

然后重启ntp

/etc/init.d/ntpd restart

重启成功后，如果你立刻想对时的话，是会报错的，如：

#ntpdate 10.100.20.59 # 就是我刚配的ntpd server
11 Feb 00:37:36 ntpdate[22276]: no server suitable for synchronization found

这种错误，应该是没有ntpd server 才会报的啊，究竟为什么呢？？

原来，如果ntpd server 没有进行过对时的话，也是会报这个错的。。。很汗，为什么不写得明白一点呢？？

好了，既然知道原因，只需要等待数分钟，让我的ntpd server 10.100.20.59 自己去对了一次时后，我们再操作，就会成功的了。

# ntpdate 10.100.20.59
11 Feb 00:41:30 ntpdate[22323]: adjust time server 10.100.20.59 offset -0.005792 sec

今天svn up的时候，发现一个报错：

#svn up
svn: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: a1 b0)

突然爆出的错误。。。google 了一下，这个比较靠谱

http://ryanerwin.com/2007/04/09/valid-utf-8-data-hex-followed-by-invalid-utf-8-sequence/

大意是说，你的svn工作目录，有了一个不能由当前系统的字符集识别的文件。
解决方式是：删了这些文件。

ok,那我去删咯，确实有一个目录下，有一个?????????????? 的文件，gbk 编码的文件。。。

怎么出现的呢？？不会是被某位大哥黑进来的吧，哈哈。

不追查了，就当是跑脚本失败生成的。删去，问题解决了！