Linux环境

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