Context switch 和 TLB shootdowns

2010年09月01日 Xupeng 2 条评论

memcache缓存大对象失效，因此某个涉及4万条记录的查询每次都会把压力直接施加到MySQL，致使MySQL服务器的load在几分钟内上升到60+。

问题的解决当然是找出引发问题的查询，临时屏蔽发起该查询的页面，解决缓存失效的问题后再恢复，在此不多说。

在MySQL服务器load飙升时，有几个有趣的现象：

  1. 85%以上的CPU(16个核)时间花费在system/kernel态
  2. 有80个左右MySQL查询处于sending data状态，每个查询持续20s左右
  3. 内网流量99.xMbps，但始终未突破100Mbps
  4. Context switch 78k/s
  5. TLB shootdowns 135k/s

查阅了一些资料，基本弄清楚了因果关系，先整理和翻译几段wiki，解释一下Context switch和TLB shootdowns：

  • Context switch(上下文切换):  简单说来，如果可运行的线程数大于CPU的数量，那么OS最终会强行换出正在执行的线程，从而使其他线程能够使用CPU。这会引起上下文切换，它会保存当前运行线程的执行上下文，并重建新调入线程的执行上下文。
  • TLB(Translation Lookaside Buffer) shootdowns：TLB是虚拟内存地址到物理内存地址的映射表，有软件TLB和硬件TLB， x86架构使用硬件TLB。当虚拟内存地址到物理内存地址的映射发生变化时，TLB会被刷新，就产生了TLB shootdowns中断，对于x86架构来说是硬件中断。

发生上下文切换时，TLB中的部分条目会失效，不同TLB实现会有不同做法，x86会清掉整个TLB，而有的实现可以做到选择性地只flush部分条目。

那么因果关系应该是这样:

  1. memcache失效，有很大结果集的查询直接施压到了MySQL上
  2. 80个左右的活动MySQL查询长时间处于sending data状态，CPU不停地在各个MySQL线程间切换（意味着有大量的上下文切换）
  3. 频繁的上下文切换导致频繁的TLB失效，引发大量的 TLB shootdowns中断
  4. 于是大量的CPU时间耗费在处理中断上，CPU的run队列等待了60个左右可运行线程，load飙升到60+

由MySQL所产生的99.xMbps网络流量比较奇怪，不确定是否是因为网卡的中断分布不均（事发当时所有的网卡中断全部由第一个CPU核处理），因此在CPU忙于处理上下文切换、TLB shootdowns中断以及其他中断时，网络吞吐量也受到了极大影响，但是这个接近100Mbps但又不超过100Mbps的数值的确蹊跷。

目前还没有想到有什么好的办法能够避免类似的情况再发生，facebook的patch可以限制并发的查询数，应该可以缓解这类问题带来的压力，不过现在看来还不太成熟，在正式采用facebook的patch并确认有效之前，可以依靠监控来及时发现问题，并尽快采取措施。

标签: ,

苹果的吸入式光驱很挫

2009年12月07日 Xupeng 3 条评论

苹果的吸入式光驱真的很挫。

一张状态良好的DVD RW，放到苹果的吸入式光驱里，读不出来，一直在嘎吱嘎吱地响，又弹不出来，弹出键没用，Disk Utility的弹出也无效，drutil eject也无济于事，快要绝望的时候，看到这里说实在弹不出来的话可以重新启动，然后一直按住鼠标/或触摸板，直到系统启动。没招了，重启试了一下，按了N久，光盘终于突然停止嘎吱嘎吱的声音，biu~的一声弹出来了…

标签:

换用mac一周

2009年12月04日 Xupeng 5 条评论

电脑不够用了，上周末去苹果家园买了台MBP 990，这是目前已上市最新款中最低配的MBP，标配2G内存，购机时给升到了4G，内存有些贵（650元），不过用惯了4G内存的本本，不想再倒回到一年多以前，用了几天发现，升级到4G内存实在是一个非常明知的选择，并且4G内存用snow leopard也实在不算多。

几年来用过不少桌面操作系统（或者当作桌面用），DOS -> Win95 -> Win98 -> Win2000 -> WinXP -> Windows 2003 -> Windows 7, Bluepoint -> Redhat -> Turbo Linux-> Slackware -> Debian -> Ubuntu -> Gentoo / FreeBSD 等等，从使用的层面上讲，mac/leopard算是上手最快的一个。

换用mac一周，罗列一些感受到的优缺点吧：

优点：

  • 触摸板非常好用，这是目前我最满意的地方
  • 电池的续航能力还好，不开虚拟机的话，在日常工作的状态下能用差不多5个小时，但是仅仅一周电池的健康状态就变成98%了
  • 大部分软件的UI和UE都不错
  • 封闭系统也有封闭系统的好处，苹果自己的一整套软硬件带来的便利还是很明显的
  • …

缺点：

  • 整个机器像是个吸尘器，加上办公室最近在装修施工，每天屏幕上的吸附的灰都到发指的程度
  • 这MBP的散热似乎不太好，用虚拟机或者编译软件时CPU的温度动不动就到80度以上了，我还见过95度的高温，散热这点甚至还不如我之前的Dell笔记本
  • 出现过一次四国文字，原因不明
  • mDNSResponder多次占用CPU100%，这时syslogd疯狂写日志，占满另外一颗CPU，CPU温度迅速飙升到90度以上，除去软件问题不说，这散热…
  • 跟我之前的Dell+Gentoo相比，软件系统的反应速度有些慢，这种慢是能够感觉到的
  • …

我更容易容忍软件的问题，因为软件问题至少有很快被修复的希望，而硬件问题的就比较致命了，比如散热，不知道这MBP在夏天会热得疯狂到什么程度。

似乎我的抱怨比满意多，不过其实我对mac整体的表现还是相对满意的，至少超出了我的预期…

标签:

使用nginx一分钟搭建全功能的twitter/twitter search API

2009年08月31日 Xupeng 9 条评论

现在有很多的twitter代理软件，比如tweetr和birdnest, 不过使用反向代理来做的话会更容易，并且得到的是一个全功能的twitter代理，这是我在我的VPS上使用nginx配置twitter和twitter search API代理的示例配置文件（当然了，这里写出来的域名是假的，哈哈）：

server {
    listen          0.0.0.0:80;
    server_name     tproxy.xupeng.me;

    access_log      /var/log/nginx/tproxy.xupeng.me.access_log;
    error_log       /var/log/nginx/tproxy.xupeng.me.error_log info;

    location / {
        proxy_pass              http://twitter.com/;
        proxy_redirect          off;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen          0.0.0.0:80;
    server_name     tsproxy.xupeng.me;

    access_log      /var/log/nginx/tsproxy.xupeng.me.access_log;
    error_log       /var/log/nginx/tsproxy.xupeng.me.error_log info;

    location / {
        proxy_pass              http://search.twitter.com/;
        proxy_redirect          off;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
标签:

修改OpenLDAP的base DN

2009年08月09日 Xupeng 2 条评论

在Debain里安装OpenLDAP时，Debian会提示给LDAP的admin用户设置一个密码，然后就自动地创建了一个默认的数据库，这个默认的数据库使用了一个默认的base DN，默认情况下，debian会使用本机的域名来作为base DN，比如如果我的域名是xupeng.local，那么debian就会使用”dc=xupeng,dc=local”作为我的默认base DN，但是很不幸，我没有给我的Debian测试机设置域名，于是我的LDAP默认数据库的base DN就成了”dc=nodomain”，要想修改base DN还真不是直接改了配置文件(/etc/ldap/slapd.conf)就行的，不过google一下很快就找到了解决方法：

  1. 停止OpenLDAP服务器 
    /etc/init.d/slapd stop
  2. 使用slapcat把LDAP数据库导出为ldif 
    slapcat -l backup-openldap.ldif

    这样LDAP数据库就被导出到了backup-openldap.ldif文件里

  3. 使用sed或者别的工具把backup-openldap.ldif里的默认的base DN: “dc=nodomain”改成想要的: “dc=xupeng,dc=local”
  4. 把/etc/ldap/slapd.conf里的base DN也改掉
  5. 使用slapadd把修改过的数据文件重新导入LDAP数据库: 
    slapadd -l backup-openldap.ldif
  6. 启动OpenLDAP服务，base DN应该就被修改掉了
标签: ,
FireStats icon Powered by FireStats