@brucmao 报警的原因是用了workspace.v2ex.com的证书，而两者是在同一个IP上的。建议@Livid 用SNI做两个证书吧

因为是打算买来当APN Proxy的，所以居然没测IO……现在补上
dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 85.9005 s, 3.1 MB/s

hdparm -tT /dev/xvda
/dev/xvda:
Timing cached reads: 14864 MB in 2.00 seconds = 7439.12 MB/sec
Timing buffered disk reads: 90 MB in 3.05 seconds = 29.55 MB/sec

帮你cc @Livid 一下

楼上两个都说错了，这个问题产生的原因并不是多线程的问题，而是Python多线程的实现问题。
Python由于GIL的存在，并不是真正的多线程。虽然线程是系统的实线程，但线程里的代码却由一个全局的GIL控制，在以下情况下才会发生线程切换，保证所有的线程都得到解释器的执行。
IO的处理，P-code的执行行数。
所以会发生楼主的问题。由于IO阻塞，导致代码停滞，两个切换的条件都不存在，所以就把整个程序都锁死了。
解决的方法是把可能阻塞的部分用multiprocessing分开，性能可能会降低。
当然Python多线程执行的这个问题，也导致了在不手动加锁的情况下，del xx["key"]这样的操作是线程安全的，因为始终只会有一个线程访问Python的内部变量。

@ISSAY 只能用ProxyDroid模拟了

S3，相信我，HTC的做工不是一般的烂，去修一次就明白了，传说中的胶布大神，里面布满了防绝缘的胶布，而且电路设计有问题，如果进水，直接烧主板没救。另外系统上也有问题，摄像头有传说中的黑点
三棒子的东西，至少电路清晰，不用胶布来做补救，而且进水后，只要在黄金72小时内去修，一般只用换小部件。

曾经在年初的时候给年夜饭写过个类似的
https://gist.github.com/1627198
支持因为某个号码不在而取消某个号码重新抽奖。

@chaker 果然杀毒软件就是最大的病毒

@mckelvin 麻烦看清楚，pythonbrew的包隔离也是用virtualenv做的……

随便外包，几千块，做个垃圾站好了，收集网上大学的段子什么的，收入也不菲的。

@lwjefSub 能在创建env的时候，指定使用哪个Python，甚至可以指定为PyPy。具体请仔细阅读virtualenv的文档。

请求root权限的时候，是可以看到它要用root干什么的。不要随便勾选“不再提示”

干嘛要更换默认的Python版本？
这就是项目不用virtualenv的悲剧。
用virtualenv能解决你所有的问题。

分析很简单，主要的瓶颈就是在去日本的途中 219.158.33.22，从日本来的途中219.158.33.21，结合上下文，这个地方的上下站都是日本，所以应该就是出国网关的位置。
再结合BGP信息 http://bgp.he.net/ip/219.158.33.22 这个是联通的出国口。所以肯定是出口有问题。
可能是带宽不足，也可能是某墙的影响，毕竟所有的防火墙都会消耗掉很多带宽的。
不过国内的网络也确实渣，日本境内都是个位数的延迟，国内都是两位数的。