关于mongo的启动参数的优化, 请教

   本人是做网络游戏开发的, 因为开发人员少, 在mysql和mongo之间, 就选了mongo因为在开发过程中不用维护表的结构而徒增工作量.
网游有两种数据库, 一种是作为玩家数据的存储, 另一种是单纯的日志.
存储玩家数据的库, 第一是一定要稳定, 其次再追求读取,存储,修改的效率.
日志库, 单纯的存储日志, 只需要查询和统计的时候方便就好.

我是第一次使用mongo, 所以对于启动参数不太熟悉, 下面三个是除了指定数据地址以外我使用的启动参数.
logappend=true
directoryperdb=true
journal=true

希望大家能给予一些关于启动参数方面的优化方案, 非常感谢.

回复讨论(解决方案)

楼主你好
关于游戏后端DB 的选用（在mysql与mongodb之间），可能你需要考虑以下几个方面
1.玩家数量级，DAU，同时在线人数。
2.游戏区服情况（是否分区，是否滚服，逻辑分服还是物理分服）
3.代码与游戏性质所决定的TPS/QPS情况。
4.是否有专业dba的配合帮助。
5.开发成本的考量（传统sql与mongodb sql，业务逻辑中跨表join的需求，）。
这是mongodb 官方关于data model的文档，可以参考参考
http://docs.mongodb.org/manual/core/data-model-design/

参数优化的话，据我的了解来说，
Mongodb 本身的mongo.conf文件并无太多可以优化，你所列的三个

logappend=true  日志追加写模式
directoryperdb=true            每个db一个文件夹
journal=true              redo log

这些是需要开启的。
其他可以考虑 oplogSize的设定，如果是有要做repl set 或者sharding（根据游戏情况 业务情况 数据量变动，tps来考量，维持一个安全的大小）

其他的来说，更多是在程序访问时候的参数，包括安全写之类的。

希望有所帮助

补充：
作为游戏数据库来说，优化的话，往以下几个方面走
mysql：肯定是用innodb的（如果是游戏），读写分离，data model的设计，index，sql 优化，参数的话大致是以下这些innodb_buffer_pool_size, innodb_flush_log_at_trx_commit,innodb_file_io_threads ,innodb_flush_method,thread_concurrency,innodb_read_io_threads ,innodb_read_io_threads ,transaction-isolation

mongodb：首先是data model的设计，极大情况下决定了效率，还有就是硬件情况，物理内存的大小，disk io。热数据+index越接近物理内存越好，再就是index（会占用memory，建议不要滥建）等等。

再补充。
mongodb 目前最新的2.6版本仍然是db级的锁，而2.0之前是instance级别，so千万用新的版本。
so在data model设计的过程中，切记根据游戏逻辑以及功能情况适当分库。以免db lock成为性能瓶颈。
不过目前2.6也有个很蛋疼的小问题，当你update set空的时候，会不让你进行，报错，而2.4中是可以这样的。。

再补充。
mongodb 目前最新的2.6版本仍然是db级的锁，而2.0之前是instance级别，so千万用新的版本。
so在data model设计的过程中，切记根据游戏逻辑以及功能情况适当分库。以免db lock成为性能瓶颈。
不过目前2.6也有个很蛋疼的小问题，当你update set空的时候，会不让你进行，报错，而2.4中是可以这样的。。

选择Mongo数据库, 只有一个原因, 就是开发上不需要考虑表的问题.
我们的游戏是分区的但不滚服. 全球玩家都会不分地区的分布在各个大区中(单纯的以服务器承载和活跃度为依据, 某段时间只会往某个单一的大区导入玩家).
目前设置的是, 每个大区一个库, 这个库里面, 有玩家数据的集合和一些其他本大区相关的数据(比如公共数据, 比如服务器事件等等) 最主要的只有玩家集合, 别的都是很小量的修改.
大区库里面, 处理最多的应该是 修改玩家数据(因为是手机游戏, 所以存在大量的 在线玩家攻击离线玩家, 从而要更新离线玩家数据的情况 根据玩家账号 update set 玩家很多属性)
因为确实是第一次用这个数据库, 所以担心是难免的.. 希望能够得到大神的再次回复和指导...

再补充。
mongodb 目前最新的2.6版本仍然是db级的锁，而2.0之前是instance级别，so千万用新的版本。
so在data model设计的过程中，切记根据游戏逻辑以及功能情况适当分库。以免db lock成为性能瓶颈。
不过目前2.6也有个很蛋疼的小问题，当你update set空的时候，会不让你进行，报错，而2.4中是可以这样的。。

选择Mongo数据库, 只有一个原因, 就是开发上不需要考虑表的问题.
我们的游戏是分区的但不滚服. 全球玩家都会不分地区的分布在各个大区中(单纯的以服务器承载和活跃度为依据, 某段时间只会往某个单一的大区导入玩家).
目前设置的是, 每个大区一个库, 这个库里面, 有玩家数据的集合和一些其他本大区相关的数据(比如公共数据, 比如服务器事件等等) 最主要的只有玩家集合, 别的都是很小量的修改.
大区库里面, 处理最多的应该是 修改玩家数据(因为是手机游戏, 所以存在大量的 在线玩家攻击离线玩家, 从而要更新离线玩家数据的情况 根据玩家账号 update set 玩家很多属性)
因为确实是第一次用这个数据库, 所以担心是难免的.. 希望能够得到大神的再次回复和指导...

HI 楼主你好
大神不敢当啦。。
几个小问题需要考量。
撇开程序情况来说
1.运营与策划对整个游戏的dau情况的评估，以及对于各个区服玩家人数的估计（比如，1区多少人了，准备开下一组db），这个对于整体的数据的数量级的评估会有很好的帮助。

2.你所说的每个大区一个库，是指一个db 还是一个实例呢，如果是一个库的话， 不大建议这样做
 第二点的详细：
由于，不了解程序以及TPS QPS的数量级，考虑到性能的问题。举个栗子：背景：我手上的某个手机游戏，某组副本集中（对应游戏的某十几个区），user总数500W不到点，平时一切正常，但是当0点时，0点会刷新所有的每日任务之类的，玩家活跃度达到最高，此时，游戏机制中的成就系统（可以理解为，做大多数操作，都会更新成就），造成大量的update，本来该成就系统不应该影响其他操作，但是由于是在一个db中，且对user主表中的成就字段进行更新，这样就造成了，玩家其他操作的卡顿与延迟（需等待lock）。
分析到这样的原因后，我给开发的建议是，将成就系统改放到同instace的单独db中，如achievement_db，假设原来是都在main_db中，修改后。该问题解决。

3.贵游戏是分服的话，那如果用mongodb 可以考虑使用多组repl set 而不是sharding。即，1-N区 是在第一组replset中，N+1-N+M区是在第二组replset中，这样从成本上比sharding要省，从性能上 省去了mongos 与config server的查询过程，就不用纠结于shard key的。

4.准备使用什么样的机器，无论是mysql还是mongodb  建议都是需要适量级的内存与disk io能力。对于mongodb来说，个人觉得 热数据+index 尽量要等于 物理内存，这样可以保证性能最大化。

再补充。
mongodb 目前最新的2.6版本仍然是db级的锁，而2.0之前是instance级别，so千万用新的版本。
so在data model设计的过程中，切记根据游戏逻辑以及功能情况适当分库。以免db lock成为性能瓶颈。
不过目前2.6也有个很蛋疼的小问题，当你update set空的时候，会不让你进行，报错，而2.4中是可以这样的。。

选择Mongo数据库, 只有一个原因, 就是开发上不需要考虑表的问题.
我们的游戏是分区的但不滚服. 全球玩家都会不分地区的分布在各个大区中(单纯的以服务器承载和活跃度为依据, 某段时间只会往某个单一的大区导入玩家).
目前设置的是, 每个大区一个库, 这个库里面, 有玩家数据的集合和一些其他本大区相关的数据(比如公共数据, 比如服务器事件等等) 最主要的只有玩家集合, 别的都是很小量的修改.
大区库里面, 处理最多的应该是 修改玩家数据(因为是手机游戏, 所以存在大量的 在线玩家攻击离线玩家, 从而要更新离线玩家数据的情况 根据玩家账号 update set 玩家很多属性)
因为确实是第一次用这个数据库, 所以担心是难免的.. 希望能够得到大神的再次回复和指导...

HI 楼主你好
大神不敢当啦。。
几个小问题需要考量。
撇开程序情况来说
1.运营与策划对整个游戏的dau情况的评估，以及对于各个区服玩家人数的估计（比如，1区多少人了，准备开下一组db），这个对于整体的数据的数量级的评估会有很好的帮助。

2.你所说的每个大区一个库，是指一个db 还是一个实例呢，如果是一个库的话， 不大建议这样做
 第二点的详细：
由于，不了解程序以及TPS QPS的数量级，考虑到性能的问题。举个栗子：背景：我手上的某个手机游戏，某组副本集中（对应游戏的某十几个区），user总数500W不到点，平时一切正常，但是当0点时，0点会刷新所有的每日任务之类的，玩家活跃度达到最高，此时，游戏机制中的成就系统（可以理解为，做大多数操作，都会更新成就），造成大量的update，本来该成就系统不应该影响其他操作，但是由于是在一个db中，且对user主表中的成就字段进行更新，这样就造成了，玩家其他操作的卡顿与延迟（需等待lock）。
分析到这样的原因后，我给开发的建议是，将成就系统改放到同instace的单独db中，如achievement_db，假设原来是都在main_db中，修改后。该问题解决。

3.贵游戏是分服的话，那如果用mongodb 可以考虑使用多组repl set 而不是sharding。即，1-N区 是在第一组replset中，N+1-N+M区是在第二组replset中，这样从成本上比sharding要省，从性能上 省去了mongos 与config server的查询过程，就不用纠结于shard key的。

4.准备使用什么样的机器，无论是mysql还是mongodb  建议都是需要适量级的内存与disk io能力。对于mongodb来说，个人觉得 热数据+index 尽量要等于 物理内存，这样可以保证性能最大化。