有时候为了让 CPU 贡献最大的能力, 我们会想尽办法让 CPU 在最高频上达到100%使用率, 可是无论怎么优化都达不到100%, 到底问题出在哪里?

1. 各种 IO 拖慢了 CPU (waiting), 导致 CPU 在等取指令, 从网络到本地, 从磁盘加载到内存, 从内存加载到缓存, 从缓存到寄存器, 在内核态和用户态直接复制;
2. 各种锁 线程/进程被 block;
3. 线程数不够多;

namespace 表示一种对全局资源使用的隔离方式, 同一 namespace 下的进程能看到一样的资源, 不同的 namespace 不能看到其他 namespace 的变动.
ls -l /proc//ns/
UTS IPC PID User Net Cgroup Mount Time

1. UTS (Unix Time Sharing) namespace
   隔离跟主机名称相关的数据, 其内容包括: hostname, domain name, OS name, OS version, kernel 版本, 处理器信息等信息. 隔离之后使用 uname 这个系统调用就返回不同的值. 参看 uname 系统条用和 Linux uname 命令

   ~$ uname --help
   Usage: uname [OPTION]...
   Print certain system information.  With no OPTION, same as -s.
   
   -a, --all                print all information, in the following order,
                           except omit -p and -i if unknown:
   -s, --kernel-name        print the kernel name
   -n, --nodename           print the network node hostname
   -r, --kernel-release     print the kernel release
   -v, --kernel-version     print the kernel version
   -m, --machine            print the machine hardware name
   -p, --processor          print the processor type (non-portable)
   -i, --hardware-platform  print the hardware platform (non-portable)
   -o, --operating-system   print the operating system
    --help     display this help and exit
    --version  output version information and exit

2. IPC
   隔离跟 IPC 相关的资源: System V IPC objects & POSIX message queue. 每个 IPC namespace 都有自己的 System V IPC identifiers 和它自己的 POSIX message queue filesystem. 系统必须设置 CONFIG_IPC_NS选项.
3. PID
   用来隔离 PID 数字的命名空间, 不同 PID 的进程号可以重复, 新的 PID namespace 的进程号从 1 开始.
4. User
5. Net
6. Time

参考:

1. https://www.kernel.org/doc/html/latest/admin-guide/namespaces/compatibility-list.html
2. https://windsock.io/uts-namespace/
3. https://www.informit.com/articles/article.aspx?p=23618&seqNum=16#:~:text=The%20uname%20system%20call%20fills,h%3E%20if%20you%20use%20uname.
4. http://www.linfo.org/uname.html
5. https://man7.org/linux/man-pages/man7/namespaces.7.html
6. https://man7.org/linux/man-pages/man7/pid_namespaces.7.html

async-profiler 是一个对 Java 应用影响很小的 profiler 工具, 不仅能 sample Java 栈, 还能获取 perf event 的数据.

常见的基本步骤:

1. 下载最新 async-profiler, 并且复制到远程目标机器

   scp ~/async-profiler-1.7.1-linux-x64.tar.gz  [email protected]:/home/user1
   rsync ~/async-profiler-1.7.1-linux-x64.tar.gz  [email protected]:/home/user1

2. 解压, 并给运行 Java 应用的用户执行权限

   mkdir /tmp/profiler
   tar -xvf -C /tmp/profiler/  async-profiler-1.7.1-linux-x64.tar.gz
   sudo chown -R app1:app /tmp/profiler/
   sudo chmod -R 755 /tmp/profiler

3. 执行 profiler

   /tmp/profiler/profiler.sh -e itimer -d 60 -o svg  -f c.log.html 74211
   /tmp/profiler/profiler.sh -e lock  -d 60 -o svg  -f f.log.html --reverse  74211 
   /tmp/profiler/profiler.sh -e com.ebay.configuration.console.CalServlet.service  -d 60 -o svg  -f f.log.html --reverse  74211
   /tmp/profiler/profiler.sh -d 30 -e itimer -o svg -t --reverse -f t.log.html 74211

4. 展示

   sudo nc -v -4 -l 7070 < f.log.html
   sudo nc -v -l -p 7070 < f.log.html

   http://server.tianxiaohui.com:7070/

https://github.com/jvm-profiling-tools/async-profiler

经常在线上看到一些应用直接因为连接池无法获得连接, 导致整个应用不在响应任何请求. 常见的有数据库连接池连接泄漏, Http 连接池泄漏. 对于这种连接泄漏的问题, 一般是应用没有考虑到某些特殊情况, 特殊异常的处理导致不能用完之后返回连接到连接池. 这里就针对 Apache HttpClient 连接池泄漏这种清楚, 分析一下基本的求解思路.

- 阅读剩余部分 -

异步 IO 的使用, 使得线程不再 block 在 IO 上面, 可以做更多的事情, 所以 Java 的 NIO 在很多地方都使用起来了. 同时由于微服务的广泛普及, 企业内部各种服务直接的相互调用更多了. 之前很多都是使用 Apache 社区的 HttpClient 来相互调用, 如今更多的代码转向了 HttpAsyncClient. 这里就记录一个由于 HttpAsyncClient 的错误使用引起的内存泄漏的案例.

- 阅读剩余部分 -