feichashao's Blog
在使用 sort 命令对文本进行排序时，如果语言环境不同，得到的排序结果也会不同。
[root@rhel674 tmp]# export LC_ALL=C; sort test.txt 1234 AAA BBB aaa aab [root@rhel674 tmp]# export LC_ALL=en_US; sort test.txt 1234 aaa AAA aab BBB
如果用 C (POSIX) 作为语言环境，得到的排序结果是按照字符对应的 ascii 码大小来排序的。而如果用 en_US 等语言环境，得到的排序结果会不同(从上可以看到，先按字母顺序排序，字母都一样的时候才区分大小写)。
继续阅读“为什么不同的 LC_ALL 设定会导致 sort 命令输出顺序不一样？”
不能。
用户发现，尽管设置了 'performance' 作为 cpuspeed 的 governor (/etc/sysconfig/cpuspeed), 但是 CPU 并不是一直处于最高频率运行。用户希望保持最高频率运行，不考虑节能，要发挥出 CPU 的最高性能。
继续阅读“锁定 C-state 能提高 CPU 性能吗？”
在出现 Kernel Panic 的时候，kdump 可以帮助我们收集 vmcore, 以便后续对故障原因进行分析。然而，近些年的服务器动辄上百G的内存，转储一个 vmcore 所耗费的时间显得相对较长，增加了 down time.
在 RHEL7/CentOS7 中， kdump 提供了三种压缩方法(zlib, lzo, snappy)，我们可以选择一种较快速的压缩方法来节省收集 vmcore 的时间。
压缩方法可以在 kdump.conf 中的 makedumpfile 一行里设置。
zlib 是 gzip 所使用的压缩方法，通常而言它比 lzo 和 snappy 慢，而压缩比稍微高于 lzo 和 snappy.
继续阅读“比较 kdump makedumpfile 中的压缩方法”
A customer noticed an issue. His system has 100+GB free memory (which is pure free memory, not buffer/cache), but system starts reclaiming pages from buffer/cache and swapping out pages at some point.
From system log, we can see things like below at the reclaiming moment.
One of my colleague raised a question: After changing resolv.conf, sendmail still query the old resolver, why?
Steps:
1. Set 192.168.122.65 as nameserver in resolv.conf, start sendmail service, send a mail to root@hat.com, and take a tcpdump. We can see there's a query asking 192.168.122.65 for MX record of hat.com .
2. Change nameserver from 192.168.122.65 to 192.168.122.72 in resolv.conf, send a mail to root@hat.com and take a tcpdump again. This time we expect a query to 192.168.122.72 (new), but the actual query is to 192.168.122.65 (old).
3. Restart sendmail service, send a mail to root@hat.com, this time we can see a query to 192.168.122.72 (new) as expected.
When we were thinking about what's going wrong with sendmail, another colleague joined in discussion, and she mentioned that httpd and some other long-running services also have this behavior.
Since sendmail is not the only case, I think we should have a check on glibc.
A dirty trick.
Install packages
# yum groupinstall "Server with GUI" # yum install motif xterm # cat /etc/sysconfig/desktop PREFERRED=/usr/bin/mwm
Start X from multi-users.target
# systemctl isolate multi-user.target # startx
在 debug pacemaker/pcs/pcsd 的时候，我们通常需要知道，敲下 `pcs xxxx xxxx` 命令后，发生了什么动作。
在应用 pcs 进行管理的 pacemaker 集群中，每个节点都会启动一个 pcsd 守护进程，监听 2224/tcp 端口。随后，我们可以从任一节点中，通过 pcs 命令管理整个集群。
按照套路，通常这是一种 client/server 架构， pcs 命令行工具向相应节点的 pcsd 发送请求， pcsd 在相应节点完成动作。
然而实际与此有所出入。
实际上，真正对 pacemaker 执行操作的，是 pcs 这个命令行工具。pcsd 负责接收来自其他节点的请求，随之调用本地的 pcs 工具，最后由本地的 pcs 执行操作。
以 `pcs cluster start` 命令为例。在 Node A 中执行 `pcs cluster start`， Node A 本地的 cluster 相关服务将被启动。
在此操作中，不需要经过 pcsd. 即， pcs ---> execute. 具体过程如下。
继续阅读“Pacemaker管理工具中 pcs/pcsd 的关系”