100分问个性能瓶颈的问题，求大神帮助

Question

本帖最后由 qq467339640 于 2014-09-24 15:03:45 编辑

Answer 1

不知道A表和B表有什么业务关系，如果将A和B分开到两个独立的库里，性能会提高。原因是：2.2之前，写锁是服务全局锁，所以分不分开没有意义，但2.2之后，写锁粒度降到库级，因此，当A表在更新时，B的更新就必须等待，分开库则可以避免。
我的回答不一定对，楼主可以试验下。另外，MongoDB不擅长写，最好加个类似Redis的中间服务来做。

Answer 2

A表和B表不是在同一个库中，现在正在考虑是否用redis来存用户信息，不过这个数据比较大，一个用户的信息大概占0.4k，业务要求要达到1500W条数据，内存耗费太大

Answer 3

1. A表是否经常有Insert操作导致的锁表？有没有将锁模式改为行锁？
2. B表是不是数据量很大？只有查询操作？有没有按主键或者索引查询？是否可以考虑分表？
3. A、B系统间网络如何？

Answer 4

MongoDB目前版本还没有行锁技术出现(文档锁)。第2条所说的索引特别重要。硬件允许的情况，分片是最好的选择。这是几个可以考虑的点或优化建议

Answer 5

谢谢版主的回答
A表insert比较少，update很多，经常都是上千条通过mongostat看的，锁模式不知道怎么查看
B表数据量不大，只有40W条数据，既有查询，也有更新，没有索引查询，分表占时不考虑
A，B系统都是走的内网，这个不是问题

Answer 6

谢谢版主的回答
A表insert比较少，update很多，经常都是上千条通过mongostat看的，锁模式不知道怎么查看
B表数据量不大，只有40W条数据，既有查询，也有更新，没有索引查询，分表占时不考虑
A，B系统都是走的内网，这个不是问题

update比Insert还要消耗性能，而且按照zhangjihao兄说的，你们用的这种数据库还不支持行锁，这个好难啊！能否考虑换个数据库？
B表的查询条件列增加索引吧，哪怕非唯一索引也好。

Answer 7

update比Insert还要消耗性能? 
对mongoDB不是很熟悉，是不是你的表引擎选择不对啊，类似MYSQL的mysam和innodb的表类型选择不合适啊~

Answer 8

谢谢版主的回答
A表insert比较少，update很多，经常都是上千条通过mongostat看的，锁模式不知道怎么查看
B表数据量不大，只有40W条数据，既有查询，也有更新，没有索引查询，分表占时不考虑
A，B系统都是走的内网，这个不是问题

update比Insert还要消耗性能，而且按照zhangjihao兄说的，你们用的这种数据库还不支持行锁，这个好难啊！能否考虑换个数据库？
B表的查询条件列增加索引吧，哪怕非唯一索引也好。
换数据库的话只有redis了，准备加个唯一索引

Answer 9

redis缓存查询效率很好，但是还是无法解决频繁插入更新的问题，另外，如果redis挂了，数据全没了。
还是得有个数据库载体，来承载数据的。

Answer 10

看起来像是硬盘IO瓶颈的问题，至于是业务量本身的问题，还是程序的问题那就要自己去查清楚了。
在没查清楚前，可以试试换一个SSD。

Answer 11

redis挂掉了，数据可以恢复一部分（aof），丢失数据有一定的概率，我这里的数据要求没那么高，允许丢失

Answer 12

os是什么？
linux?
网络环境？

Answer 13

现在还不清楚是mongo问题，还是程序问题，主要问题是mongo一个库的collection锁表率很高（经常达到90%以上），导致另外一个库的collection处理很慢估计是mongo单机处理有点弱，官方推荐的是做mongo集群

Answer 14

os  Linux version 3.10.40-50.136.amzn1.x86_64 (mockbuild@gobi-build-60001) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) )
网络环境都是走的内网，主要问题是mongo一个库的collection锁表率很高（经常达到90%以上），导致另外一个库的collection处理很慢，导致connection数量居高不下，处理很慢，阻塞了B系统

Answer 15

简单的A表锁不应该影响的B表操作，除非是共享资源相关锁，而一般情况下共享资源应该仅仅是硬盘，否则就是mongo设计有问题。

Answer 16

os  Linux version 3.10.40-50.136.amzn1.x86_64 (mockbuild@gobi-build-60001) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) )

Answer 17

1、你每次都重新建立连接，系统里没有连接池？
2、一个mongo数据库，连接池就那么大，A锁表，A就处理慢了，剩下的继续创建连接，直接把连接池给占的差不多了，B哪来的连接可用？

Answer 18

1.肯定使用了连接池的。系统链接池很大，完全够用
我查看了mongo的可用链接数的，在高峰期的时候也就才2000不到的链接，mongo完全够用，问题是A表所用的链接不是很多，A表锁表率很大导致B表操作很慢，结果就是我问题描述那个样子，你可以看看我java对mongo配置那块

Answer 19

居然用mongodb，话说我最近刚安装好这个，还不会用呢。顶个！

Answer 20

1.肯定使用了连接池的。系统链接池很大，完全够用
我查看了mongo的可用链接数的，在高峰期的时候也就才2000不到的链接，mongo完全够用，问题是A表所用的链接不是很多，A表锁表率很大导致B表操作很慢，结果就是我问题描述那个样子，你可以看看我java对mongo配置那块
1、你的mongo什么版本？配置的最大连接够吗？有的mongo版本默认的连接池很小的。
2、高峰期的可用连接数够吗？不是连接数。

Answer 21

hao 感觉不错呢挺好的挺不错

Answer 22

在 WINDOW 下， 性能分析用 ETW， Java 没有？ 

Answer 23

不可能吧，以前我用mongodb100w的数据批量添加查询都完全没问题，必须根据查询简历索引，而且使用其自带的查询分析explain优化一下，另外，mongodb的写在每秒1w左右，才100w的数据，你做个复制集，将读写分离就行了啊。

Answer 24

看看你的连接数是多少？
mongo是长连接的，不自动释放。
池子泄漏了没？

Answer 25

阻塞了时候连接数一直很高在1800-2000左右，平时只有几百，连接池使用的是mongo官方提供的，你可以看看我的代码，池子应该没泄露

Answer 26

原因现在都不清楚，解决方案是吧A表的操作放在另外一个mongo服务器上了