一直到现在,还是未能完全理解这个机制。现在把找到的资料汇总一下,时间允许的情况下,我会继续学习,争取把这个坑早日填上。
最近在排查一个用户同步数据非常慢的问题。使用perf trace -S -p $pid发现,进程的大部分时间花费在了select函数上: 凭直觉觉得有些异常。按照Linux手册上对select的说法: select() allow a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become “ready” for some class of I/O operation (e.g., input possible). A file descriptor is considered…
今天测试了一下aliyun Linux 2.0,想看看它自带的ebcc工具到底如何。结果在跑一个bpftrace示例脚本的时候报错。
lxd是Canonical/Ubuntu发布的一个container管理工具。技术角度上说,lxd是一个后台服务进程,它的作用是提供一个REST API用于更好的管理lxc container。类似于当初的docker是一个便于使用、管理container的工具一样。
最近在排查一个文件系统相关的lock contention的问题。通过前面的排查,已经确定遇到的性能问题是lock contention导致,但却不知道究竟是哪些文件或资源导致的。
## 更新: 在CentOS 7.7中,文件已经解决。直接`yum install bcc-tools`就可以了。 目前公司的CentOS 7.6系统上已经有bcc-tools软件包了,直接yum install bcc-tools就可以。遗憾的是,安装了之后程序运行报错。 CentOS 7.6 1810, with kernel 3.10.0-957.27.2.el7.x86_64 #1 运行tcplife,报错如下:
有些时候,Linux系统上会发起一些TCP连接,但很快就结束。传统的netstat、ss或者lsof这类工具很难追踪到是谁(UID)或者哪一个程序(binary)发起的。我觉得perf可以追踪到,但是还不知道具体该怎么操作。
上周折腾了一下gitlab runner的安装。遇到了一些问题,这里记录一下解决的办法,以备下次要用的时候又要再折腾一遍。 这里这个链接包含了runner的介绍,如果你对相关概念不理解,可以先过一遍: https://docs.gitlab.com/runner/
最近几周来我的USB硬盘盒性能突然急剧下降,播放上面的几百兆的影片都卡到不行,夸张的时候只要一快进就要卡住好几分钟。 因为硬盘盒里的是一块很早以前买的希捷SATA2的机械硬盘,一年前上面的hammer文件系统还出过一次故障,不得已重新格式化。就怀疑是不是又出现机械故障或者磁盘的寿命将尽。
昨天使用uwsgi和Nginx在Debian 9上部署一个python程序。完成后给uwsgi写了一个systemd文件,想通过systemd来管理uwsgi的启动和停止。