标签：glibc

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?”

glibc 的 malloc per thread arenas 特性

本文准确性有待深究，只查阅过部分资料和进行过一些简单讨论，并未在代码层面进行过研究。如有纠错或补充，请在本文留言，感谢！

从 RHEL5 迁移到 RHEL6 的用户会有这样的发现：多线程程序在 RHEL6 中占用的*虚拟内存*，要比在 RHEL5 上的多。这种情况在 JAVA 程序中尤为突出，尽管 JAVA 应用是单线程的。
其中的一个原因，是 glibc 2.12 中的新特性 malloc per thread arenas 造成的。

Java 占用较多虚拟内存

通常，Java 应用会运行在 JVM 上。JVM 有自己的一套内存调用方式，一般不会使用到 glibc. 但某些对象还是会调用 malloc，从而使用使用到 per thread arenas 这个特性。

为何有 per thread arenas?

在过去的 malloc 实现中，每个程序会有一个 main arenas 供 malloc 申请使用。对于多线程的程序，每个线程调用 malloc 的时候，都需要事先检查是否有锁，确认没有锁后，才能拿到内存空间。这影响了程序的性能。

在现在的实现中，每一个线程都会有自己的 arenas，这就避免了线程之间的竞争，从而提高性能。

另外，我们可以看到 arenas 是一些大约为 64MB 的无权限匿名页（64位系统中）。
继续阅读“glibc 的 malloc per thread arenas 特性”