1. 内存错误检测工具: valgrind
2. 进程和代码的CPU使用情况分析工具:oprofile
3. 程序内计时函数:clock_gettime,可精确到纳秒(10e-9秒),统计的是wall clock time; 不能用clock(统计的是CPU时钟周期数,IO等待时间不算)
4. C++11中的原子操作数据类型: #include <atomic> atomic_llong count(0);
5. 查看网络使用率:nload -u MB
6. 查看处理器型号和物理核个数: cat /proc/cpuinfo
processor 包括这一逻辑处理器的唯一标识符。
physical id 包括每个物理封装的唯一标识符。
core id 保存每个内核的唯一标识符。 (该逻辑核所对应的物理核id)
siblings 列出了位于相同物理封装中的逻辑处理器的数量。
cpu cores 包含位于相同物理封装中的内核数量。(一个芯片上有几个物理核)
7. oprofile分析程序CPU瓶颈:
sudo opcontrol --init
sudo opcontrol --no-vmlinux
sudo opcontrol --reset #必须清空!!
sudo opcontrol --start #开始统计
./run_my_app
sudo opcontrol --dump #导出统计信息
sudo opcontrol --stop
sudo opcontrol --shutdown
sudo opannotate -s run_my_app # 源码级分析
sudo opreport -l # 函数级分析
8. 性能相关的程序,编译时必须使用-O3选项,一般速度可增快1倍以上!
9. 读磁盘文件用什么函数快:探寻C++最快的读取文件的方案
fread+自己解析,可以比fscanf快将近10倍!mmap+自己解析,比fread+自己解析快10%左右
10. gflags使用 链接
11. Hadoop的文件在上传过程中,会以_COPYING_后缀命名,完成后才会改名去掉该后缀;如果上传到一半客户端停止上传,那这个半截文件会留在那里,后缀名_COPYING_标识它是个半截文件;
12. mpirun,启动MPI-job, 必须满足2个前提条件:1. 所有机器上相同的目录下都有这个可执行文件;2. 启动job的目录(即视为进程工作目录)在所有机器上必须存在
13. 生成库文件:
14. 极易出bug: 浮点数绝对值,用fabs, 不是abs(返回整数!)!!!
15. top里的VIRT,ps aux里的VSZ, 内存单位都是KB!
16. 倒排索引的建立:对整个doc集,跑一个MapReduce任务,进行半结构化和按重要性排序;再跑一个MapReduce任务,Mapper输入每个doc, 输出<Token, dockId-offset等>,Reducer把他们写到倒排索引即可,因为doc是按重要性排序的,所以token也按doc重要性排序的。
索引更新的时候,采用swap方式,改动一个链接即可,把链接改为新索引的地址。
索引服务器们,是按doc来划分的,每个索引服务器负责一部分doc,存放该部分doc的正排索引和倒排索引。好处是,求交的时候,可以在每个索引服务器内部去做。缺点是每台服务器提供前100个优质doc,有可能导致真正第101个优质doc的丢失(当前101个优质doc都在同一个索引服务器上时)
17. 打印第一列,且排序,去重,才能调comm:awk '{print $1}' <filename> | sort | unqi
找出两个文件不同的地方: comm <A> <B> 显示3列,1是A-B; 2是B-A; 3是A交B; 可以用-1 -2 -3选项来指定不输出哪列;
18. 全局变量,编译报错“未定义的引用”
解决:虽然只能定义一次,但不能任意定义,而应该定义在一个“基文件”。比如你编译一个文件main.cpp 生成一个main文件, 然后这个main还依赖另外一个base.cpp编译生成的base.o文件才能编译完成,那么这个base.cpp就是基文件,按照软件来说就是依赖包。倘若你在main里定义了 然后在base里引用但没定义就会报错未定义,要是都定义会报错重复定义。
19. gdb调试:
sudo ulimit -c unlimited (设置core文件大小无上限)
ulimit -c (查看core文件上限,确认上一步已生效)
gcc ...... -g
出来core.XXX文件后,gdb <exe_file> core.XXX
bt (查看出错位置的调用栈)
20. 查看进程里各个线程hang在哪里: pstack
21. 文件没被close,即是被rm掉,其实磁盘空间还是没被释放!!
上周有个客户说服务器空间满了,要帮忙清理下空间。到现场删掉了一个几G的log文件,但是使用df查看文件空间,依然还是使用100%,空间一直未释放出来。上网查了一下,原来是调用那个文件的进程还在,只要Kill掉就可以了。
原因其实很简单,主要是因为被删除的文件在删除的时侯还是进程在操作(打开、访问等)的缘故,rm只完成了在磁盘上文件实体的释放,而类似free list结构中相应的文件系统因进程的操作相应的inode并未释放。
解决的方法:这样的问题解决起来也很简单,找到操作的进程,kill掉就可以了,可是找到操作的进程恰恰是本问题的难点和关键。这样的问题也可以通过重启机器和nmount/mount文件系统这样的方式解决,但这样的方法我是不提倡的,小小的问题就重启机器,小题大做。
linux及solaris可以这样做:
a、下载一个lsof软件装上,google上可以搜到
b、找到正在用被删文件的进程
lsof | grep deleted
c、kill掉相应的进程空间就释放了
避免fclose忘掉:不再使用C的fopen,改用C++的库,函数返回即关闭;或者grep "fopen"和grep"fclose"看看个数是否一样!
22. 系统服务的查看和添加修改: chkconfig命令
23. "Too many open files"报错的原因:linux有同时打开文件个数的上限(默认一般是1024),可用ulimit -n看到;可通过修改limits.conf文件和sysctl命令来修改这个上限;
24. top命令各字段含义:
available = free + buffer + cache
第4行"Mem:"是物理内存占用情况;
第5行"Swap"是磁盘交换区使用情况,用多了说明物理内存不够用了,程序性能会大幅度下降,该吃药了;
buffers: 写文件的内存缓冲区,OS定期flush进磁盘,也可手工用sync命令;
cached: 读文件的内存缓存,读操作先访问这里,不命中才去访问磁盘;
进程列表:VIRI是进程使用的虚存大小;RES是进程使用的物理内存大小;%MEM是进程使用的物理内存百分比;
只显示某个进程:top -p 进程id
25. ps aux | grep 进程名字
26. 查看系统中启动的端口:netstat -lntup
查看80端口的连接情况:netstat -nat | grep 80
27. 列出某个进程打开的所有文件: lsof -p 进程id
28. 显示到达主机所经路由:traceroute
29. 查看程序的依赖库(特别是load library报错时需要看加载库需要的路径): LD_DEBUG
30. 替代nohup sh XXX.sh 2>&1 1>>log.txt &和ps aux | grep XXX和kill -9 XXX这套组合拳的方式: supervisor
31. 把git上的代码复制到本地:git clone http://XXX:100/kmind/calculate
32. 压缩整个文件夹:tar -czvf logs.tar.gz ./logs
解压缩之:tar -xzvf logs.tar.gz
注意不要使用gzip直接压缩,会把文件夹里的每个文件都压缩成一个.gz文件的,乱死了。。。
33. 查看某个进程打开的所有文件和库的路径: lsof -p <PID>
34. 查看目录大小:切换到cd ~,运行这个命令:
find $(pwd) -type d -print0 | xargs -0 du | sort -n | tail -10 | cut -f2 | xargs -I{} du -sh {}
35. 清空垃圾站:trash-empty (rm -rf ~/.local/share/Trash/*)
36. 查看实时网速:nload (上下左右键切换网卡)
37. 有的进程,使用nohup和&,在终端关闭后,仍然会结束掉。解决方法:使用exit命令退出中端。
38. 查看文件的md5: md5sum <FilePath>
39. 比nvidia-smi -l 1更好用的查看GPU使用情况:watch -n1 nvidia-smi