Game server database step over the pit

in the page tour server this piece has not been seriously considered before, most of it was built before, I just need to follow his original design to continue code code just fine.

However, the process of server reconfiguration, still encountered a lot of unexpected problems. Then follow the step of the pit, to talk about analysis and analysis.

1: The original MySQL scheme

The original design is this, with a roleplayer to do the player data cache, all player data update to Roleplayer, timed 10 seconds to update to the database. Roleplayer is probably such a design

Class RolePlayer

{

public int Roleid;

Public String Packinfo;

Public String Equipinfo;

Public String TaskInfo;

.....

}

Every 10 seconds a batch update is made for all online roleplayer, with JDBC, as well as for the player's running water, but more of a patchwork string, such as insert into Onlineserials (Roleid,rolename, Oltime) VALUES (1212929, "Wanjia1", 12222), (1212929, "Wanjia1", 12222), (1212929, "Wanjia1", 12222) (1212929, "Wanjia1", 12222), (1212929, "Wanjia1", 12222). For the processing of water is relatively cautious, when the flow of items to 5k after the insertion.  I think this is probably a page tour server to the general purpose of MySQL design, but unfortunately there is always a memory leak, with the tool to see, basically, a string of char accounted for 40% of the memory, no matter what I use the recycling method is invalid. Of course, I still think this is a good design, but I am in the use of the poor level.

　　2:mongo's Database Schema

Later adjust the database for MONGO, we do not be surprised, I use the JSON format stored in the database, so compatible with MySQL and MONGO, so it is easier to adjust. MONGO is easier to use, and for this NoSQL memory database, it's a lot easier to use, whether it's updating or querying. The basic design is when the player's data changes, the update to the database, of course, through a message asynchronous to the database thread to do the update, the record of the water is the same reason. Just MONGO is a memory monster, for the memory of greed, presumably used by people are clear, for MONGO for memory management You can Baidu, there are many such articles, here is not explained in detail. I was helpless at first, even reading foreign language. Find our previous operations, they also said that MONGO do not do too many settings, just a memory 25g+raid10 hard disk to deploy MONGO database specifically, SSD is too expensive to use. On the Internet Weibo collected some information also share to everyone, although not completely control, but also is a good way.

　　3: Control MONGO's memory

1: Adjust the memory management mode of Linux kernel: shell> sysctl-w Vm.drop_caches=1

2: Use the way MONGO provides to reclaim the memory: the use of the MONGO will affect the efficiency of

Mongo>use MMO;

Mongo>db.repairdatabase ();

3: Active cleanup of Linux cache memory: echo 3 >/proc/sys/vm/drop_caches

Note that it is best to sync before releasing to prevent data loss.

You can run the above command to release MONGO memory with a timer.

　　4 : Ultimate solution for controlling MONGO memory

I found the usage of capped collection when I looked through the book "Mongo Combat". Capped collections has the following advantages:

1: Fixed size collection, which prevents unlimited expansion of memory.

2: Age-out (Aging removal) processing in LRU (Least recently used) rules and insertion order, automatically maintaining the order of insertions in the collection.

At first glance will think the fixed size is a big limit, but in fact for also has to say enough, now the page swims to import the user basically at million level. Aging removal to prevent the memory of the infinite manager, for the water, most of us just want the recent water to find the problem, for one months ago the water, I think no one will care.

In addition, adjusting ulimit does not control the use of MONGO for memory.

If wrong, hope to criticize!