Dec 31
手头项目中有一个模块,一般情况下需要用python将数十万条数据加载到一个dict中处理,其中每条数据是一个小的dict,整体速度稍微有点慢(毕竟python不适合处理大量琐碎的小对象),由于在性能要求范围内,所以也没怎么在意。

但是在最近的性能测试中用160w+数据来压的时候,发现性能恶化得厉害。虽然算法是线性的,但是实际运行时间却明显不对劲。增加一些log后,发现在处理过程中,每隔几万条数据就会出现一个很明显的lag,而且lag的时间越拉越长。

由于不像是算法本身的问题,初步猜测可能是python中dict的rehash带来的时间开销。但是根据一般哈希表的实现方法,lag出现得太平均,又不是很符合逻辑。

大胆假设,小心求证,翻了一下python源码,Objects/dictobject.c 中 "static int dictresize(PyDictObject *mp, Py_ssize_t minused)" 函数被多处调用,其中PyDict_SetItem的末尾的调用是:"dictresize(mp, (mp->ma_used > 50000 ? 2 : 4) * mp->ma_used)",也就是说,在需要rehash的情况下,按4倍(少于50000个item)或2倍的规模扩大。

用下面这段代码测试1600w数据,将输出数据拷贝到Excel并生成图表,可以很明显地看出lag的出现规律与上述扩张规则非常相符。
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = i


{图一}
点击在新窗口中浏览此图片

将上述代码稍作修改,每次插入的value是个dict,测试100w数据,生成图表,每隔10w左右产生一个lag,且lag时间越拉越长,与遇到的问题现象一致。
from copy import deepcopy
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = deepcopy(data)


{图二}
点击在新窗口中浏览此图片

因此大体可以判断问题出在大量零碎小对象上,很自然地,就联想到会不会是gc在捣蛋。查了一下,虽然Python对象内部是引用计数的管理方式,但是为了避免循环引用导致的内存泄漏,解释器还是内置了一个gc,当现有对象数量超过某个阈值以后扫描一下,看看是否可以回收一些空间。由于我们的代码中并不存在循环引用的对象,这种gc其实是没有意义的,于是把gc关掉再测:
from copy import deepcopy
import gc
gc.disable()
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
    i += 1
    if i % 50000 == 0:
        print '%d\t%.4f' % (i, time.time() - begin)
    d[i] = deepcopy(data)


{图三}
点击在新窗口中浏览此图片

一条直线。
Nov 30
最近项目上有需要,大概就是有一个list里的东西需要处理,例如一堆文件什么的,于是有一个file_processor——按顺序处理一个文件列表。简单封装了一下multiprocessing这个库,发现用起来很方便,很轻松地就实现了多进程并行处理(进程间无交互):

import multiprocess

slices = multiprocess.split_list(filelist, 8) #分成8份
processes = map(lambda slice: multiprocess.spawn(file_processor, slice), slices)
sys.exit(multiprocess.start_and_join(processes))


multiprocess.py 则是这样的:
#!/usr/bin/python
#coding: utf-8

import sys
from multiprocessing import Process

def split_list(data, n_slice, hash_func=lambda i, d: i): #default: sequential
    slices = []
    for i in range(n_slice):
        slices.append([])

    for i, d in enumerate(data):
        slices[hash_func(i, d) % n_slice].append(d)

    return slices

def spawn(target, *args, **kwargs):
    return Process(target=target, args=args, kwargs=kwargs)

def start_and_join(processes, killall_if_fail=True):
    for p in processes:
        p.start()

    exitcode = 0
    for p in processes:
        p.join()
        if p.exitcode != 0:
            exitcode = p.exitcode
            break

    if exitcode != 0:
        for p in processes:
            if killall_if_fail and p.is_alive():
                p.terminate()

    return exitcode
Oct 14
我大约从2010年起,就一直在自己的机器上使用 Windows宿主机+Ubuntu Server@VBox虚拟机 这种组合,一方面不用抛弃windows上早已熟悉的众多GUI软件,另一方面又可以享受到Linux带来的便利,在上面做开发等等。

虽然仅仅用一个NAT就可以解决网络的问题,但是如果每次新增一个服务就要添加一个端口映射也很麻烦,所以我开了双网卡,另一个使用Host-Only,这样主机和虚拟机之间可以直接互访。

虽然有人说用Bridged Network也能解决这个问题,但是前述方法却有更多好处:首先因为是外网无法直接访问这台机器,所以可以使用弱密码;其次虚拟机里使用NAT通过宿主机访问外部网络,因此像我现在主机上的双网卡的目标网络也可以免配置直接访问。

不过昨天遇到了个问题(貌似以前也曾经遇到过),就是突然不能访问外网了(但是仍然能ping通192.168.56.1,即宿主机的Host-Only IP),经过测试发现如果把Host-Only的网卡去掉就没问题,所以看起来像是这两个网络冲突了。

经过放狗搜索,SuperUser上的一个问题提醒我,这个其实是路由表的问题,由于没有指定默认网关,因此不知道为什么Ubuntu(WinXP也会)就把Host-Only的gateway当成默认网关了。

解决问题很简单,先删掉错误的默认网关,再添加新的默认网关:

    $ sudo route del default
    $ sudo route add default gw 10.0.2.2

不过这个重启以后就会消失,需要保持的话,就在 /etc/network/interfaces 添加一行

    up route add default gw 10.0.2.2
Oct 9

"挪窝"的N次方 不指定

felix021 , 13:48 , 杂碎 , 评论(4) , 引用(0) , 阅读(1169) , Via 本站原创
博客又搬家了,主要是因为mk802用了两年,好像有点老了,让人有点不太放心,所以还是决定花点钱买点省心。

这次终于还是搬到了DigitalOcean,5$/month,512M RAM + 20G SSD,性价比很高,而且可以选择Singapore的机房,ping值也很让我满意,SSH上去几乎感觉不到什么延迟,各种倒腾以后算是安定下来了,就这样吧。

如果你也想用DigitalOcean,可以用我的Referrer链接来注册:https://www.digitalocean.com/?refcode=1a51e0fbce00 ,这样在你支付25$你的帐号里就会打入10$,我的帐号上也会收到25$,这个项目还是挺给力的。

p.s. 如下面@whusnoopy同学所述,Github的Student Pack有100$的Digital Ocrean Promo Code,只要有edu邮箱就可以注册,快来薅(hāo)羊毛吧。
Sep 27
#update@09.28 注意,根据CoolShell这篇文章指出,官方的patch25并没有真正解决问题,仍然可以使用这种方式来实现注入(具体解释详见那篇文章): $ env X='() { (a)=>\' bash -c "echo date"; ,经过测试,Ubuntu官方更新的Bash不受影响,但是自己patch的bash还是不能解决这个问题。

大概大家都知道了,最近bash爆出来了个大漏洞,名号ShellShock,影响范围是bash 1.14 ~ 4.3(最新版),基本上你能想到的Linux/Unix机器都中招了,包括果粉们的macbook。

当然有些人还是心怀侥幸,那么就执行下面这个命令试试看:

    $ env x="() { :;}; echo vulnerable" bash -c "echo this is a test"

如果输出是:
引用
vulnerable
this is a test
恭喜你中奖了,bash将环境变量的定义直接执行了,说明被注入了。

而打过补丁的系统里,输出应当是:
引用
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test


解决方法其实很简单,大多数发行版都迅速针对这个问题推出了安全更新,比如常用的ubuntu,只需要在 sudo apt-get update 以后运行 sudo apt-get install bash 就可以了。redhat什么的也类似,网上搜一下就能找到相应说明。

而对于raspberry pi或者是mk802这种就比较蛋疼,ports.ubuntu.com 还没有及时更新,因此只能手动打补丁了:
【UPDATE】patch-25并没有完全解决问题,可以在另一个ubuntu下apt-get source bash来获取完全免疫版本的源码
#!/bin/bash

mkdir bash-patched
cd bash-patched
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #截止到2014/9/27最新的patch编号是25
#build and install
./configure --prefix=/
make && make install


打完补丁心里放心了,就可以来安心看看shellshock是怎样影响到你的系统的。

一个最简单的例子是CGI(Common Gateway Interface),最早的动态页面都是通过CGI实现的:http server除了给出一些CGI中规定的环境变量之外,还有解析HTTP Header中的字段,加上前缀HTTP_也设置为环境变量;准备好env以后,才去调用对应的CGI程序,CGI程序通过解析变量的值来获取用户的输入,并给出相应的返回。

比如说Ubuntu上的apache,默认是开启了mod_cgi,并且cgi目录是 /usr/lib/cgi-bin ,我们可以在下面放一个最简单的cgi脚本,名叫 test (并chmod +x),其内容是

#!/bin/bash

echo    #输出一个空行,用来分隔httpserver的HTTP Header和下面的HTTP Entity
echo "Hi"

访问 http://127.0.0.1/cgi-bin/test ,你就可以看到一个页面,内容是Hi。你可以在CGI程序的末尾追加一个env命令,用来查看环境变量,可以看到诸如REQUEST_URI、REMOTE_PORT之类Server自动填充的内容,也可以看到HTTP_USER_AGENT之类浏览器添加的内容。

注意,浏览器可以影响到(这个cgi脚本及其子进程的)环境变量——这就是突破点了,因此可以很容易地构造一个攻击请求,让服务器执行指定的命令,例如:
引用
$ nc 127.0.0.1 80
GET / HTTP/1.1
Host: 127.0.0.1
X: () { :;}; echo ""; cat /etc/passwd

服务器返回的内容就变成了:
引用

HTTP/1.1 200 OK
Date: Fri, 26 Sep 2014 16:52:21 GMT
Server: Apache/2.2.22 (Ubuntu)
Transfer-Encoding: chunked

455
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...
username:x:1000:1000:username,,,:/home/username:/bin/bash


经过我的测试,php-fpm和apache的mod_php方式都不不受shellshock的影响,但是不要认为你没有跑上面这种CGI程序就放心了,例如常见的基于CGI的perl和php(据说fastcgi没问题,但我没测试),有时会通过system之类的函数调用shell命令,这也会导致bash被调用,而且据说openssh和dns client也有类似的问题(具体情形我没有了解),所以就不要侥幸了,尽快升级你的bash吧!

p.s. 说一句马后炮的话,这个BUG实际上非常简单(以至于我这么容易就弄懂了),bash遍历环境变量的时候会(用yacc生成的解释器)检查它的值,如果它看起来像是一个函数的定义(就像 x="() { echo hello!; }" 这样),那么bash会eval这段代码,然而如前面的例子所示,虽然它看起来像是一个函数定义,但是它实际上可以是用分号分隔的多个语句,依然满足bash的语法……看了一下bash43-025这个patch,修改了几十行,主要就是增加了 SEVAL_FUNCDEF 和 SEVAL_ONECMD 两个类型以及相应的用于进一步区分环境变量的检测代码,从而避免了上述情况。
Sep 26
二选一应该就行了:

(1) 客户端:修改/etc/ssh/ssh_config ,

    增加ServerAliveInterval 15,这样客户端会在空闲时每15s给Server发送一个null包

    增加ServerAliveCountMax 3 (默认值就是3),如果连续3次null包没有收到回应就会断开连接

(2) [类似地] 服务端:修改/etc/ssh/sshd_config,

    增加ClientAliveInterval 15,这样服务端会在空闲时每15s给Client发送一个null包。

    增加ClientAliveCountMax 3 (默认值就是3),如果连续3次null包没有收到回应就会断开连接

详情可以 man ssh_config 或者 man sshd_config 查看。
Jul 2
UPDATE@9.24 在淘宝上弄了个Google Cardboard的国内山寨版,效果不是很好,一个是焦距调得不好,我得带上眼镜才能看,另一个是瞳距好像不太对,看着容易晕。还是自己DIY的用着舒服啊。等暴风魔镜正式版出来以后可以再弄个来试试看。

Oculus Rift DK2自从3月发布以来,大家都翘首以待,今天终于确定了,7月发货1w台,比预期的少,后下订单的估计有得等了。想起去年ChinaJoy在Intel展区体验了一下1代的Oculus Rift,演示程序是RiftCoaster,就是那个经典的过山车,回想起来还是很带感。这么火爆的设备,估计在今年的ChinaJoy也可以体验到,真是令人相当期待。在这等待的时间里,还是可以做点其他事情的,比如DIY一个属于自己的虚拟现实设备。

网上早就在流传把诸如小米3之类的手机改造成VR设备,之前也有了解过,看起来貌似很复杂的样子;直到前几天GOOGLE I/O大会,发布了一个Cardboard,然后到Oculus Rift贴吧里看了一下,发现有些网友的自制设备可寒酸了,就是拿了个纸盒子打孔,固定手机和透镜就行,才意识到其实自己DIY一个也很简单的,手机可以作为显示屏,自己手头有瓦楞纸(就是快递用纸箱的那种纸皮)、宽胶带、小刀、剪刀、尺子,唯一缺少的材料就是一对合适的凸透镜——求助万能的淘宝就行了。
Jun 15
挺早之前就有设想过这样一个Python模块,基于共享内存(Linux下的mmap)的哈希表实现,使得多个Python进程之间可以方便地共享一些数据。

某天心血来潮,花了几个小时居然写出来了,然后花了两天时间陆陆续续修补完善。

由于偷懒,没有做信号量/锁之类的东西,所以只适合一些简单的场景。

性能还凑合,但是没经过正经的测试和实际使用,仅供参考。

pypi页:https://pypi.python.org/pypi/pyshmht

Github:https://github.com/felix021/pyshmht
分页: 1/91 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]