为什么不同的 LC_ALL 设定会导致 sort 命令输出顺序不一样？

在使用 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 命令输出顺序不一样？”

比较 kdump makedumpfile 中的压缩方法

背景

在出现 Kernel Panic 的时候，kdump 可以帮助我们收集 vmcore, 以便后续对故障原因进行分析。然而，近些年的服务器动辄上百G的内存，转储一个 vmcore 所耗费的时间显得相对较长，增加了 down time.

在 RHEL7/CentOS7 中， kdump 提供了三种压缩方法(zlib, lzo, snappy)，我们可以选择一种较快速的压缩方法来节省收集 vmcore 的时间。

压缩方法可以在 kdump.conf 中的 makedumpfile 一行里设置。

# man makedumpfile

-c,-l,-p
  Compress dump data by each page using zlib for -c option, lzo for -l option or snappy for -p option.  (-l option needs USELZO=on and -p option needs USESNAPPY=on when building)
  A user cannot specify this option with -E option, because the ELF format does not support compressed data.
  Example:
  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile

zlib 是 gzip 所使用的压缩方法，通常而言它比 lzo 和 snappy 慢，而压缩比稍微高于 lzo 和 snappy.
继续阅读“比较 kdump makedumpfile 中的压缩方法”

How to request continuous physical memory in Linux?

Background

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.

May  2 10:03:56 rhel68-kmalloc kernel: insmod: page allocation failure. order:10, mode:0xd0
May  2 10:03:56 rhel68-kmalloc kernel: Pid: 22319, comm: insmod Not tainted 2.6.32-642.el6.x86_64 #1
May  2 10:03:56 rhel68-kmalloc kernel: Call Trace:
May  2 10:03:56 rhel68-kmalloc kernel: [<ffffffff8113e77c>] ? __alloc_pages_nodemask+0x7dc/0x950
May  2 10:03:56 rhel68-kmalloc kernel: [<ffffffff8117f132>] ? kmem_getpages+0x62/0x170
May  2 10:03:56 rhel68-kmalloc kernel: [<ffffffff8117fd4a>] ? fallback_alloc+0x1ba/0x270
May  2 10:03:56 rhel68-kmalloc kernel: [<ffffffff8117f79f>] ? cache_grow+0x2cf/0x320
May  2 10:03:56 rhel68-kmalloc kernel: [<ffffffff8117fac9>] ? ____cache_alloc_node+0x99/0x160

继续阅读“How to request continuous physical memory in Linux?”

Why do services like sendmail/httpd still query outdated DNS servers after resolv.conf is changed?

Question

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.

继续阅读“Why do services like sendmail/httpd still query outdated DNS servers after resolv.conf is changed?”