曾经在收集数据的项目中,用过mongodb的数据存储,但是当数据很大的时候,还是比较的吃力。很可能当时的应用水平不高,也可以是当时的服务器不是很强。 所以这次能力比以前高点了,然后服务器比以前也高端了很多,好嘞 ~再测试下。
(更多的是单机测试,没有用复制分片的测试 ~)!
相比较MySQL,MongoDB数据库更适合那些读作业较重的任务模型。MongoDB能充分利用机器的内存资源。如果机器的内存资源丰富的话,MongoDB的查询效率会快很多。
这次测试的服务器是dell 的 r510!
内存还行,是48G的,本来想让同事给加满,但是最终还是没有说出口 ~
磁盘是10个2T的,但是因为格式化的时间太久了,哥们直接把其他的硬盘给拔出来了,就用了三个盘。。。data目录没有做raid,是为了让他们体现更好的硬盘速度。
既然说好了是在python下的应用测试,那就需要安装mongodb python下的模块 !
对了,不知道mongodb-server的安装要不要说下?
1
2
3
4
5
|
cat /etc/yum.repos.d/
10
.repo
[10gen]
name=10gen Repository
baseurl=http:
//downloads-distro.mongodb.org/repo/redhat/os/x86_64
gpgcheck=
0
|
Pymongo的基本用法
1
2
3
4
5
6
7
8
9
10
11
12
13
|
from pymongo
import
* # 导包
con = Connection(...) # 链接
db = con.database # 链接数据库
db.authenticate(
'username'
,
'password'
) # 登录
db.drop_collection(
'users'
) #删除表
db.logout() # 退出
db.collection_names() # 查看所有表
db.users.count() # 查询数量
db.users.find_one({
'name'
:
'xiaoming'
}) # 单个对象
db.users.find({
'age'
:
18
}) # 所有对象
db.users.find({
'id'
:
64
}, {
'age'
:
1
,
'_id'
:
0
}) # 返回一些字段 默认_id总是返回的
0
不返回
1
返回
db.users.find({}).sort({
'age'
:
1
}) # 排序
db.users.find({}).skip(
2
).limit(
5
) # 切片
|
测试的代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
#!/usr/bin/env python
from pymongo
import
Connection
import
time,datetime
import
os,sys
connection = Connection(
'127.0.0.1'
,
27017
)
db = connection[
'xiaorui'
]
def func_time(func):
def _wrapper(*args,**kwargs):
start = time.time()
func(*args,**kwargs)
print func.__name__,
'run:'
,time.time()-start
return
_wrapper
@func_time
def ainsert(num):
posts = db.userinfo
for
x
in
range(num):
post = {
"_id"
: str(x),
"author"
: str(x)+
"Mike"
,
"text"
:
"My first blog post!"
,
"tags"
: [
"xiaorui"
,
"xiaorui.cc"
,
"rfyiamcool.51cto"
],
"date"
: datetime.datetime.utcnow()}
posts.insert(post)
if
__name__ ==
"__main__"
:
num = sys.argv[
1
]
ainsert(
int
(num))
|
咱们就先来个百万的数据做做测试~
综合点的数据:
在top下看到的程序占用资源的情况 ~ 我们看到的是有两个进程的很突出,对头 ! 正是mongodb的服务和我们正在跑的python脚本 !
看下服务的io的情况 ~
脚本运行完毕,总结下运行的时间 ~
查看mongodb的状态~
他的insert也不到5k ~ 插入量也就800k左右 ~
它的输出有以下几列:
inserts/s 每秒插入次数
query/s 每秒查询次数
update/s 每秒更新次数
delete/s 每秒删除次数
getmore/s 每秒执行getmore次数
command/s 每秒的命令数,比以上插入、查找、更新、删除的综合还多,还统计了别的命令
flushs/s 每秒执行fsync将数据写入硬盘的次数。
mapped/s 所有的被mmap的数据量,单位是MB,
vsize 虚拟内存使用量,单位MB
res 物理内存使用量,单位MB
faults/s 每秒访问失败数(只有Linux有),数据被交换出物理内存,放到swap。不要超过100,否则就是机器内存太小,造成频繁swap写入。此时要升级内存或者扩展
locked % 被锁的时间百分比,尽量控制在50%以下吧
idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了
q t|r|w 当Mongodb接收到太多的命令而数据库被锁住无法执行完成,它会将命令加入队列。这一栏显示了总共、读、写3个队列的长度,都为0的话表示mongo毫无压力。高并发时,一般队列值会升高。
conn 当前连接数
time 时间戳
瞅下面的监控数据 !
然后我们在测试下在一千万的数据下的消耗时间情况 ~
共用了2294秒,每秒插入 4359个数据 ~
虚拟内存在8gb左右,真实内存在2gb左右
再换成多线程的模式跑跑 ~ 个人不太喜欢用多线程,这东西属于管你忙不忙,老大说了要公平,我就算抢到了,但是没事干,我也不让给你。。。属于那种蛮干的机制 ~
nima,要比单个跑的慢呀 ~ 线程这东西咋会这么不靠谱呀 ~
应该是没有做线程池pool,拉取队列。导致线程过多导致的。不然不可能比单进程都要慢~
还有就是像这些涉及到IO的东西,交给协程的事件框架更加合理点 !!!
1
2
3
4
5
6
7
8
9
10
11
12
|
def goodinsert(a):
posts.insert(a)
def ainsert(num):
for
x
in
range(num):
post = {
"_id"
: str(x),
"author"
: str(x)+
"Mike"
,
"text"
:
"My first blog post!"
,
"tags"
: [
"mongodb"
,
"python"
,
"pymongo"
],
"date"
: datetime.datetime.utcnow()}
# goodinsert(post)
a=threading.Thread(target=goodinsert,args=(post,))
a.start()
|
python毕竟有gil的限制,虽然multiprocess号称可以解决多进程的。但是用过的朋友知道,这个东西更不靠谱 ~ 属于坑人的东西 ~
要是有朋友怀疑是python的单进程的性能问题,那咱们就用supervisord跑了几个后台的python压力脚本 ~ supervisord的配置我就不说了,我以前的文章里面有详述的 ~
cpu方面是跑的有点均匀了,但是mongodb那边的压力总是上不去
当加大到16个后台进程做压力测试的时候 ~ 大家会发现insert很不稳定。 看来他的极限也就是2MB左右的数据 ~
当减少到8个压力进程的时候 ~ 我们发现他的insert慢慢的提供到正常了,也就是说 他真的是2MB的极限 ~
脚本里面是有做有序的id插入的,我们试试把id的插入给去掉,看看有没有提升~
结果和不插入id差不多的结果 ~
调优之后~ 再度测试
ulimit的优化
1
2
3
|
cat /etc/security/limits.conf
* soft nofile
102400
* hard nofile
102400
|
内核的tcp优化
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
cat /etc/sysctl.conf
net.ipv4.tcp_syncookies =
1
net.ipv4.tcp_tw_reuse =
1
net.ipv4.tcp_tw_recycle =
1
net.ipv4.tcp_timestsmps =
0
net.ipv4.tcp_synack_retries =
2
net.ipv4.tcp_syn_retries =
2
net.ipv4.tcp_wmem =
8192
436600
873200
net.ipv4.tcp_rmem =
32768
436600
873200
net.ipv4.tcp_mem =
94500000
91500000
92700000
net.ipv4.tcp_max_orphans =
3276800
net.ipv4.tcp_fin_timeout =
30
#直接生效
/sbin/sysctl -p
|
启动的时候,加上多核的优化参数
1
|
多核问题可以在启动时加入启动参数: numactl --interleave=all
|
insert的频率已经到了2w左右 ~ 内存占用了8G左右 ~
我想到的一个方案:
当然不用非要celery,就算咱们用socket写分发,和zeromq的pub sub也可以实现这些的。这是celery的调度更加专业点。
刚才我们测试的都是insert,现在我们再来测试下在千万级别数据量下的查询如何:
查询正则的,以2开头的字符
1
2
3
|
posts = db.userinfo
for
i
in
posts.find({
"author"
:re.compile(
'^2.Mike'
)}):
print i
|
精确的查询:
查询在5s左右 ~
总结:
典型的高读低写数据库 !
本文转自 rfyiamcool 51CTO博客,原文链接:http://blog.51cto.com/rfyiamcool/1329351,如需转载请自行联系原作者