系列top

top

top – display Linux tasks

iotop

iotop – simple top-like I/O monitor

iftop

iftop – display bandwidth usage on an interface by host

ntop

ntop – display top network users

atop

atop – Advanced System & Process Monitor

ftop

ftop – show progress of open files and file systems

mytop

mytop – display MySQL server performance info like ‘top’

htop

htop – interactive process viewer

 

关于安装： 如果幸运的话，都可以通过yum install 搞定

tcprstat

tcprstat is a free, open-source TCP analysis tool that watches network traffic and computes the delay between requests and responses.

tcprstat is related to the tcpstat tool, but it focuses on response time measurements, not on the amount and size of the network traffic. This makes it useful for response time analysis, which is needed for techniques such as Goal-Driven Performance Optimization.

The advantages of tcprstat are as follows:

  • It is lightweight and unobtrusive. No bulky log files need be written and analyzed.
  • Requests and responses are timed with microsecond resolution.
  • The output is easy to import into spreadsheets, manipulate with command-line scripts, graph with gnuplot, and so on.
  • It is protocol-agnostic, and works well for a large variety of client-server protocols that have a simple request-response model.

参考资料：

https://www.percona.com/docs/wiki/tcprstat:start

mysql监控管理工具–innotop

INNOTOP是一个通过文本模式显示MySQL和InnoDB的监测工具。INNOTOP是用PERL语言写成的，这使它能更加灵活的使用在各种操作平台之上，它能详细的的监控出当前MYSQL和INNODB运行的状态，以DBA根据结果，可以合理的优化MYSQL，让MYSQL更稳定更高效的运行。

官方地址： http://innotop.googlecode.com/svn/html/index.html

github地址： https://github.com/innotop/innotop

 

安装： 先试试yum search innotop

 

参考资料： http://blog.csdn.net/wyzxg/article/details/8609981

 

gitlab 安装问题

安装方式：

  1. 通过百度离线下载功能下载gitlab的rpm（这样下载速度回快些）
  2. 安装rpm
  3. 修改配置文件

测试：

出现问题如下：

刚安装好就出现这样的问题，太让人不解了（关键是在不同的机器上用相同的方式安装，有时候就是好的）

经过N翻折腾，无果，还是直接去代码里面调试吧；

信息1： pre-receive hook

信息2： The project you were looking for could not be found.

在目录 /opt/gitlab 中搜索关键字： The project you were looking for could not be found.

发现文件： /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/git_access.rb  修改此文件：

重新测试，不报错了，而且提交成功了。先这样吧

由于ruby实在一点儿也不了解，没法debug，遂在z.cn买了一半ruby的入门书

纠结的进程关系

进程P起了两个进程p1和p2，然后wait(p1); p1通过管道写数据到p2；当p2工作异常后，p1写给p2的数据不能被处理，导致管道阻塞了p1；当发现p2异常后，试图kill -9 杀死p2；纠结出现了：

P当前只wait(p1),对于p2的死不做任何反应，由于暂时没人为p2收尸，p2只能处于<defunct>状态，虽然p2已经注定了死亡的命运，但是p1和p2之间的管道依然存在（还没被销毁，可见，p2的资源是需要P来回收的），p1将不会得到任何异常通知，依然在等待； 于是乎，出现了循环等待了。

解决办法倒是比较简单，把P给kill了就行了；只是这个状态比较纠结

gitlab 里面的runsvdir 居然能把进程的错误写到进程名上，如下（省的你看不见？）：

nginx+fpm 之长连接问题

长连接避免了每次请求都重新建立连接，理论上是好事儿，欣然用之；后发现nginx偶尔会报如下错误：

而且有同事A反应，调用同事B的接口时，收到了200响应码，但是没有收到响应的其他数据，而且确认不是因为超时所致；同事B反馈说，接口执行正常，应该有数据返回，而且确认接口执行速度很快，日志为证。

双方说的都对，事实却是如此，我试图模拟这种情况的出现，模拟办法：

让接口输出响应码后，直接杀死fpm进程，nginx果然报出了几乎一样的错误；但是实际场景中，没有发现fpm猝死的任何蛛丝马迹，也找不到fpm会在响应头输出之后就猝死的理由；

按照以前的风格，我将通过看源码、调试等方式查个水落石出，现在不想了，先把长连接关掉试试吧；（凭啥直接怀疑长连接？凭直觉）

现在，长连接关了有一周时间了，没有再出现类似错误；还有好多更重要的事情要做，先不纠结这个了；服务器端建立连接的代价也没有大到不可以接受，先这样吧！

wordpress 环境搭建

WordPress 环境搭建需要安装： PHP、Mysql、Apache（当然nginx+fpm也行）

源代码编译安装很拽吗？不，我不喜欢，全部yum安装。

安装的mysql5.1，不支持utf8mb4；

添加yum源：

这个yum源有好些很新的东西，如：php7，好吧，也体验下php7

原本WordPress使用的httpd，需要的.htaccess都在，基本不需要设置，只注意修改:

其实yum安装挺方便的。

卸载后低版本的mysql后，安装高版本的mysql，数据会被保留，包括数据库的密码

php gd 库编译

前言

。。。

安装依赖

安装devel的时候会自动安装相应的lib的，所以这样就行；gd支持的更多的libvpx  libxpm  这些用不到，就不编译进去了

编译

完事儿会有一个gd.so

 

当有了gd.so后，在其他机器上就没有必要再编译了，直接copy gd.so 自然不好使，因为依赖的库文件可能没有，需要：

注意，这里是不需要devel的