I am using Meteor JS in production and it first looked like we suffered from a memory leak in our application, but now it seems like MongoDB is the culprit or perhaps Meteor?
We're heavy users of Meteor methods and don't manage connection to Mongo ourselves, since Meteor does that for us. However, in production it seems like mongo processes just hangs around forever and consumes more and more memory until the application becomes unresponsive.
As you clearly can see, there are a lot of mongo processes here, some that has been living for hours. Yesterday, after a reboot of the server the memory consumption was about 900MB, now it's closing onto 4GB.
Since rebooting every once in a while in unacceptable, what can we do to fix this? I don't really know where to start since Meteor manages connections to Mongo and I am a bit uncertain what's causing this issue.
Any tips or direction is helpful, even if it's just a tip on how to debug our application.
MeteorJS version: 1.10
Mongo version: 4.2.1
Related
I'm running MongoDB 2.4.5 and recently I've started digging into Replica Set to get some kind of redundancy.
I started same mongo instance with --replSet parameter and also added an Arbiter to running Replica Set. What happened was writing to mongo slowed down significantly (from 15ms to 30-60ms, sometimes even around 300ms). As soon as I restarted it in not-replicaset-mode performance went back to normal.
I also set up the newest 3.0 version of MongoDB with no data and run same tester as before and the result was quite similar - writes were at least 50% slower while running the ReplicaSet mode.
I could not find many examples of such behaviour online so I guess something is wrong with my mongo configuration or OS configuration.
Any ideas? Thanks for help.
It sounds like you're using "replica acknowledged" write concern, which means that the operation will not return until the data has been written to both the primary and replica. The write concern can be set when doing any write operation (from 2.6 onwards - it looks from the 2.4 documentation that calling getLastError causes a write concern of replica acknowledged in 2.4, are you doing that in your test code?).
Read this section (v3)) or this section (v2.4) of the MongoDB documentation to understand the implications of different write concerns and try explicitly setting it to Acknowledged.
Okay so the problem was C# library. I used a native C# driver (works fine even with 2.4.5 MongoDB) and there seems to be no difference in performance. Thanks for help.
How can i run mongo 2.6 and mongo 3.0 at the same time on my linux system ?
I need this because i have 2 projects one is working on mongo 2.6 and one is working on mongo 3.0
Any help is appreciated !!
If you really wan to do this, and I recommend you DO NOT, then the best way is to use a container tech, docker can work quite well or LXC or one of the others.
However, do note that there is a high chance that if your sever is in the "cloud" it is already vitualised as it is as such you will constantly be losing power and resources due to sub virtualising everything over and over.
DO NOT put them on the same host without some kind of separation there will be a high chance of resource contention and conflict that tools like ulimit just cannot solve (well, technically it could but it will be a hairball).
I am trying to perform performance testing for one of my application using MongoDB. I am using 2.5.5 development version. Sharding works fine when I try to read and write data using mongos.
To perform performance testing I need to start 600-700 mongoconnection threads to the mongos. Each thread queries around 2000 documents which is distributed on two shards. This test runs fine for few minutes but after sometime it stops working with the error "Connection refused by one of the shard". Looking closely at it I found that server runs out of ports when these many threads request data.
Could anyone please have a look and let me know if it is a MongoDB bug in the dev version or is it something which I am doing wrong while connecting to database.
your help will be much appreciated.
Thanks,
Vibhu
I have an account with MongoLab for MongoDB and the constant calls to this remote server from my app slow it down quite a lot. When I run the app locally on my computer with a local version of Mongod and MongoDB it's far, far faster, as would be expected.
When I deploy my app (running on Node/Express) it will be run from a VPS on CentOS. I have plenty of storage space available on my VPS, are there any major downsides to running MongoDB locally rather than remotely on Mongolab?
Specs of the VPS:
1024MB RAM
1024MB VSwap
4 CPU Cores # 3.3GHz+
60GB SSD space
1Gbps Port
3000GB Bandwidth
Nothing apart from the obvious:
You will have to worry about storage yourself. MongoDB does tend to take a lot of disk space. upgrading storage will probably be harder to manage than letting Mongolab take care of it.
You will have to worry about making sure the Mongo server doesn't crash and it's running fine.
You will have scaling issues in the future once the load on your application and your database increases.
Using a "database-as-a-service" like Mongolab frees you from worrying about a lot of hardware/OS/system level requirements and configuration. Memory optimization? Which file system? Connection limits? Visualization and IO ops issues? (thanks to Nikolay for pointing that one out)
If your VPS provider doesn't account for local traffic in your bandwidth, then you can set up another VPS for MongoDB. That way, the server will be closer so the requests will be faster, and also, it will have the benefits of being an independent server. It still won't be fully managed like MongoLab though.
[ Edit: As Chris pointed out, MongoLab also helps you with your database schema design and bundles MongoDB support with their plans, so that's also nice. ]
Also, this is a good question, but probably not appropriate for StackOverflow. dba.stackexchange.com and serverfault.com are good places for this question.
I have recently started having my mongodb instance crash on an ubuntu machine at random times, it usually stays up for a day or so. The mongo log has no trace of the crash, just the last operation and when I restarted the server. I need some guidance in finding out the problem and the log doesn't have any information. Is there another log I should be looking at?
The setup is fairly straightforward, single instance (no sharding), of mongodb 2.2 running on an ubuntu box, with pretty much default install.
The only change I have done recently which seems to coincide with this in timing is I have replaced some simple map reduce execution with the aggregate framework.
Thanks.
MongoDB unofficially have Mtools try download and run with your logs in this tool. it can give you why it went down, how many time it restarted and many more details.
you can get this in github
Through Logs you can view the actual cause of crash
/var/log/mongodb/mongod.log ####Common path of logs
or use this command
db.adminCommand( { getLog : "global" } )