0%

uptime

1
2
3
huting3@ai23:~$ uptime
13:47:32 up 160 days, 20:21, 3 users, load average: 0.00, 0.01, 0.05
huting3@ai23:~$

查看系统负载最方便的方式,但是要结合其他工具理解。

dmesg | tail

1
2
3
4
5
6
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.

查看系统消息

vmstat 1

1
2
3
4
5
6
7
8
$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0

检查所有cpu的平均使用情况。

Columns to check:

r: Number of processes running on CPU and waiting for a turn. This provides a better signal than load averages for determining CPU saturation, as it does not include I/O. To interpret: an “r” value greater than the CPU count is saturation.

free: Free memory in kilobytes. If there are too many digits to count, you have enough free memory. The “free -m” command, included as command 7, better explains the state of free memory.

si, so: Swap-ins and swap-outs. If these are non-zero, you’re out of memory.

us, sy, id, wa, st: These are breakdowns of CPU time, on average across all CPUs. They are user time, system time (kernel), idle, wait I/O, and stolen time (by other guests, or with Xen, the guest’s own isolated driver domain).

mpstat -P ALL

1
2
3
4
5
6
7
8
9
10
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]

查看每个cpu的使用情况,用来检查不均衡的状况。

pidstat 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat

07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat

查看进程的内存使用情况

iostat -xz 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]

查看硬盘的使用情况。

r/s, w/s, rkB/s, wkB/s: These are the delivered reads, writes, read Kbytes, and write Kbytes per second to the device. Use these for workload characterization. A performance problem may simply be due to an excessive load applied.

await: The average time for the I/O in milliseconds. This is the time that the application suffers, as it includes both time queued and time being serviced. Larger than expected average times can be an indicator of device saturation, or device problems.

avgqu-sz: The average number of requests issued to the device. Values greater than 1 can be evidence of saturation (although devices can typically operate on requests in parallel, especially virtual devices which front multiple back-end disks.)

%util: Device utilization. This is really a busy percent, showing the time each second that the device was doing work. Values greater than 60% typically lead to poor performance (which should be seen in await), although it depends on the device. Values close to 100% usually indicate saturation.

free -m

1
2
3
4
5
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0

sar -n DEV 1

1
2
3
4
5
6
7
8
9
10
11
12
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

查看网络吞吐量。

sar -n TCP,ETCP 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00

12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00

12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00

12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00

查看网络连接情况

top

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched

查看系统性能。

参考链接

init

service是一个脚本命令,分析service可知是去/etc/init.d目录下执行相关程序。service和chkconfig结合使用。
服务配置文件存放目录/etc/init.d/

1
2
3
4
# 启动sshd服务
service sshd start
# 设置sshd服务开机启动
chkconfig sshd start

systemd

centos7版本中使用了systemd,systemd同时兼容service,对应的命令就是systemctl
Systemd 是 Linux 系统中最新的初始化系统(init),它主要的设计目标是克服 sysvinit 固有的缺点,提高系统的启动速度
使用systemd的目的是获取更快的启动速度。
为了减少系统启动时间,systemd的目标是
尽可能启动较少的进程
尽可能将更多进程并发启动
可以去查看系统进程的pid,initd的pid是0,如果支持systemd的系统的systemd进程pid为1

systemd把不同的资源称为Unit
每一个 Unit 都有一个配置文件,告诉 Systemd 怎么启动这个 Unit
存放目录:/etc/systemd/system和/usr/lib/systemd/system

对于有先后依赖关系的任务
systemctl融合service和chkconfig功能
systemctl的使用例如

1
2
3
4
5
# 开启服务
systemctl start sshd.service
# 设置开机启动
systemctl enable sshd.service
# 本质上是建立一个软链接 ln -s /usr/lib/systemd/system/sshd.service /etc/systemd/system/multi-user.target.wants/sshd.service

总结:

systemd功能更加强大,是某些linux发行版用来代替系统启动init和service的一个新的系统工具,同时还没有失去兼容对init的兼容性。

只清除pagecache

1
sync; echo 1 > /proc/sys/vm/drop_caches

清除dentries and inodes

1
sync; echo 2 > /proc/sys/vm/drop_caches

清除PageCache, dentries and inodes

1
sync; echo 3 > /proc/sys/vm/drop_caches

清除swap空间

1
swapoff -a && swapon -a

原文链接

通常,在类Unix环境中编程,Vim是非常重要的编辑代码的工具,而且操作系统均会自带,免除了安装软件的烦恼。

但是操作系统原生自带的Vim之具有最基本的一些功能,使用起来还是不大方便,因此,给Vim安装好用的插件成为了大家的选择。

Vim的插件多种多样,自由度极高。经过长时间的努力寻找,终于找到了一种非常好的插件,特此记录一下。这个插件就是:

Spf13-vim

为了vim支持neocomplete这个插件,必须使得vim支持lua

之前在网上看通过源码编译vim,但是我试了很多次都没有成功

最后索性通过Mac自带的homebrew解决了问题:
brew install vim –with-lua

brew install macvim –with-lua

这两个命令都有效,简单快捷。

然而这样又引入了一个新的问题:

python-mode初始化时报错,初步猜测是因为我使用了anaconda

但是我已经不想折腾了,现在也用不到,索性在.vimrc.local 中设置:
g:py_mode = 0
关闭了python-mode,反正现在也用不上,以后要用的时候再解决吧。就酱。

最近将YOLO项目的代码移植到Windows环境下。遇到了一些问题,因此记录下来。

free

头文件:#include <stdlib.h>

free() 函数用来释放动态分配的内存空间,其原型为:

void free (void* ptr);

free() 可以释放由 malloc()、calloc()、realloc() 分配的内存空间,以便其他程序再次使用。

【参数说明】ptr 为将要释放的内存空间的地址。

free() 只能释放动态分配的内存空间,并不能释放任意的内存。下面的写法是错误的:

1
2
3
int a[10];
// ...
free(a);

如果 ptr 所指向的内存空间不是由上面的三个函数所分配的,或者已被释放,那么调用 free() 会有无法预知的情况发生。

如果 ptr 为 NULL,那么 free() 不会有任何作用。

注意:free() 不会改变 ptr 变量本身的值,调用 free() 后它仍然会指向相同的内存空间,但是此时该内存已无效,不能被使用。所以建议将 ptr 的值设置为 NULL,例如:

1
2
free(ptr);
ptr = NULL;

内联函数(inline)和宏定义(define)

关键点:

1、内联函数在可读性方面与函数是相同的,而在编译时是将函数直接嵌入调用程序的主体,省去了调用/返回指令,这样在运行时速度更快。

2、内联函数可以调试,而宏定义是不可以调试的。

内联函数与宏本质上是两个不同的概念如果程序编写者对于既要求快速,又要求可读的情况下,则应该将函数冠以inline。下面详细介绍一下探讨一下内联函数与宏定义。

一、内联函数是什么?

内联函数是代码被插入到调用者代码处的函数。如同 #define 宏(但并不等同,原因见下文),内联函数通过避免被调用的开销来提高执行效率,尤其是它能够通过调用(“过程化集成”)被编译器优化。

二、 内联函数是如何在安全和速度上取得折衷?

在 C 中,你可以通过在结构中设置一个 void* 来得到“封装的结构”,在这种情况下,指向实际数据的 void* 指针对于结构的用户来说是未知的。因此结构的用户不知道如何解释void指针所指内容,但是存取函数可以将 void 转换成适当的隐含类型。这样给出了封装的一种形式。

不幸的是这样做丧失了类型安全,并且也将繁琐的对结构中的每个域的访问强加于函数调用。(如果你允许直接存取结构的域,那么对任何能直接存取的人来说,了解如何解释 void* 指针所指内容就是必要的了;这样将使改变底层数据结构变的困难)。

虽然函数调用开销是很小的,但它会被累积。C++类允许函数调用以内联展开。这样让你在得到封装的安全性时,同时得到直接存取的速度。此外,内联函数的参数类型由编译器检查,这是对 C 的 #define 宏的一个改进。

三、为什么我应该用内联函数?而不是原来清晰的 #define 宏?

因为#define宏定义函数是在四处是有害的:
和 #define 宏不同的是,内联函数总是对参数只精确地进行一次求值,从而避免了那声名狼藉的宏错误。换句话说,调用内联函数和调用正规函数是等价的,差别仅仅是更快:
// 返回 i 的绝对值的宏
#define unsafe(i)
( (i) >= 0 ? (i) : -(i) )

// 返回 i 的绝对值的内联函数
inline
int safe(int i)
{
return i >= 0 ? i : -i;
}

int f();

void userCode(int x)
{
int ans;

ans = unsafe(x++);   // 错误!x 被增加两次
ans = unsafe(f());   // 危险!f()被调用两次

ans = safe(x++);     // 正确! x 被增加一次
ans = safe(f());     // 正确! f() 被调用一次

}

和宏不同的,还有内联函数的参数类型被检查,并且被正确地进行必要的转换。
宏定义复杂函数是有害的;非万不得已不要用。

四、如何告诉编译器使非成员函数成为内联函数?

声明内联函数看上去和普通函数非常相似:
void f(int i, char c);
当你定义一个内联函数时,在函数定义前加上 inline 关键字,并且将定义放入头文件:
inline
void f(int i, char c)
{
// …
}

注意:将函数的定义({…}之间的部分)放在头文件中是强制的,除非该函数仅仅被单个 .cpp 文件使用。尤其是,如果你将内联函数的定义放在 .cpp 文件中并且在其他 .cpp文件中调用它,连接器将给出 “unresolved external” 错误。

五、如何告诉编译器使一个成员函数成为内联函数

声明内联成员函数看上去和普通函数非常类似:
class Fred {
public:
void f(int i, char c);
};

但是当你定义内联成员函数时,在成员函数定义前加上 inline 关键字,并且将定义放入头文件中:
inline
void Fred::f(int i, char c)
{
// …
}

通常将函数的定义({…}之间的部分)放在头文件中是强制的。如果你将内联函数的定义放在 .cpp 文件中并且在其他 .cpp 文件中调用它,连接器将给出“unresolved external”错误。

六、 有其它方法告诉编译器使成员函数成为内联吗?

有:在类体内定义成员函数:
class Fred {
public:
void f(int i, char c)
{
// …
}
};

尽管这对于写类的人来说很容易,但由于它将类是“什么”(what)和类“如何”(how)工作混在一起.

小结

总之,在嵌入式C(或C++)编程里面,懂得使用内联函数(inline)与宏定义(#define),并使用好它们,对我们是大有裨益的。

我的环境是Ubuntu14.04,利用Hexo将博客部署到github。

安装git

一条命令即可

1
$ sudo sudo apt-get install git

安装Node.js

Node.js的安装有很多种方式,使用编译源码安装的方式安装。

安装前配置安装g++编译器

1
$ sudo apt-get install build-essential

Node.js官网下载源代码,选择最后一项,Source Code

解压到某一目录,然后进入此目录,依次执行以下3条命令

1
2
3
$ ./configure
$ make
$ sudo make install

安装时间比较长,可以喝杯咖啡。

安装Hexo

一条命令即可

1
$ sudo npm install -g hexo

创建博客

1
2
3
$ hexo init blog
$ cd blog
$ sudo npm install

生成静态页面

1
$ hexo generate

启动本地服务

1
$ hexo server

部署到github

注册github账号之类的就不多说了

建立博客目录

博客目录名称必须为yourusername.github.io

配置_config.yml

翻到最下面,改成我这样子的

deploy:
type: git
repo: https://github.com/yourusername/yourusername.github.io.git
branch: master

执行命令

1
$ sudo npm install hexo-deployer-git --save

推送到github

1
$ hexo deploy

至此工作基本完成,可以访问你的博客了。