12月 17

CentOS上使用python和C开发leveldb库学习测试

  测试环境为阿里云,单核Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz,内存512M,最基础的配置,测试系统为CentOS 64位。测试数据就是把双色球所有组合进行排列,共17721088行,文件名为di.txt,体积363421k。leveldb推荐使用SSD硬盘,当前虚拟硬盘的速度肯定是不行,此处只是学习,测试对比。

官方网址
http://code.google.com/p/py-leveldb/

安装命令
svn checkout http://py-leveldb.googlecode.com/svn/trunk/ py-leveldb-read-only
cd py-leveldb-read-only/
# 需要注意,下面的脚本里需要使用git获取leveldb。所以要把git客户端装好。
./compile_leveldb.sh
python setup.py build
python setup.py install

  python遇到的问题
  报错
../snappy-read-only/snappy.h:45:33: error: snappy-stubs-public.h

  解决:
yum -y install autoconf automake libtool
再次编译还是不成功,手动安装压缩工具。
网址:http://code.google.com/p/snappy/
使用命令
wget http://snappy.googlecode.com/files/snappy-1.1.1.tar.gz
./configure –enable-shared=no –enable-static=yes
make CXXFLAGS=’-g -O2 -fPIC’
make install
再次安装编译py-leveldb通过。

  C语言编译问题
  报错
/usr/bin/ld: cannot find -lleveld
collect2: ld 返回 1

  解决
将.so .a拷贝到系统lib目录中,测试系统64位,直接拷贝到lib64中。
cp libleveldb.* /usr/lib64/

python测试部分
顺序写代码

批量写代码

随机读1000万次代码:

测试结果
# python write_seq.py
use sec 329.217786074
每秒写入53827

# python write_bacth.py
use sec 173.626176119
每秒写入102064

# python read.py
use sec 288.070755005
每秒随机读取34713

C部分代码,为了方便,我把两个代码分开写。
C顺序写入

C 1000万次随机读

测试
C顺序写入
编译
gcc -Wall -std=c99 write-leveldb.c -lleveldb -O3 -o write-leveldb
结果
# ./write-leveldb
225
每秒钟处理78760

C 1000万次随机读
编译
gcc -Wall -std=c99 read-leveldb.c -lleveldb -O3 -o read-leveldb
结果
# ./read-leveldb
143
每秒处理69930

  写入过程CPU肯定是全部跑满。使用snappy压缩,所以写入data目录为175M,压缩了一半。
  随机读将CPU跑满。python内存占用23%。C语言占用内存最终增加到39%。
  之后又做到了一个测试,硬件内存只有512M,硬盘数据插入826M。使用python代码再次随机读取1000万次,使用347.94秒,每秒随机读28740。所以数据超出物理内存不会出错只是速度下降。
  还有问题一没有测试,leveldb默认的每块2M如果64G则数据文件65536个,达到系统打开文件最大数,不知道会不会出问题。并且在同一个目录下文件过多也会对系统改造成一定压力,不知道是否会有影响。推荐使用办法把单块体积加大,此效率也没有测试。
  还有一点说明,使用pypy做了测试,效果不如python,具体原因没有详查。

12月 04

python和C统计jpeg图片RGB值的效率

  测试硬件pcduino(arm),操作系统ubuntu 3.4.29+ armv7l GNU/Linux。测试文件,图片jpeg,大约1.3M。测试内容统计图片的RGB里的值,存在数据库里将来看看能不能做搜索用。
  先是用python,开发速度非常快,但是效率有点问题,所以有用C做了一下。以下是代码和两次的测试结果。C使用的jpeglib库8.0版本。

python代码

C代码

先是测试python部分
#time python countrgb.py

(12, 510858)
(17, 429677)
(9, 662996)

real 11m4.009s
user 10m42.200s
sys 0m1.090s

开始测试C的部分
首先优化编译一下
#gcc countrgb.c -l jpeg -O3 -o countrgb
#time ./countrgb 123.jpg
12,510858
17,429677
9,662996

real 0m0.750s
user 0m0.730s
sys 0m0.010s

  两次统计结果相同,说明统计方法没有问题。python用了11分钟,C用了0.75秒,看来真的不是一般的快了。C代码编译后的文件8K,静态编译500多K。不过我是喜欢用python,开发速度快,结构清晰。

10月 16

用Nginx为uwsgi后端图片服务器做缓存服务

  很早处理的问题,现在拿出来做个记录。
  需求:后端图片服务处理各种格式、尺寸的图片。使用python处理,系统为Django+uwsgi(其实直接用tornado更好,也更方便)。前端需要做缓存,直接使用nginx。当前问题nginx和uwsgi连接后就不能使用cache服务了,nginx的proxy cache服务是在upstream的流转发过程中实现。所以要做个内部转发。nginx部分配置如下:

日志部分,添加缓存记录方将来统计击中率,参数为upstream_cache_status。
日志的中表示说明
MISS 未命中,请求被传送到后端
HIT 缓存命中
EXPIRED 缓存已经过期请求被传送到后端
UPDATING 正在更新缓存,将使用旧的应答
STALE 后端将得到过期的应答

log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for” “$request_time” ‘
‘”$upstream_cache_status”‘;

转发的主要部分

  重启nginx服务后查看日志,日志中已经有了HIT的日志,日志显示使用处理耗时0.000ms。收工。

10月 15

无聊的内存操作

  今天一哥们说他内存曲线是均匀锯齿状。这对python太简单了,就是对内存添写和释放就行。我无聊之下写了下面的代码。

内存图形如下:
内存图形