I use MongoDB to store periodically measured values. Every ~100 ms a bunch of values is inserted as document. It works fine, but I'm worried about performance issues. (I use safe inserts, it seems as if in PyMongo this is the default.)
What happens if there are more inserts per second than mongod is able to save to the hard disk? Will there be any warning or will it simply fail silently?
Is there any method to monitor write load? I've found only db.serverStatus().writeBacksQueued
which is always set to false when I call it. How could I test how much data I have to insert to fill up the write queue?
mongostat
displays locks. Is this something I should be worried about?
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn repl time
*117 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:6.5% 0 0|0 0|0 124b 6k 2 SLV 09:58:10
*111 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:0.8% 0 0|0 0|0 124b 6k 2 SLV 09:58:11
*111 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:4.2% 0 0|0 0|0 124b 6k 2 SLV 09:58:1
Do I have to worry about write locks? What happens to an insert during a write locked time period? Is it queued and stored later on?
I am thinking about a simple replication setup using one master and one slave. Does the initial sync or a resync process lock the databases?
(I'm using version 2.4.3.)
Update: I think have partly answered my own question. I managed to get up to 12.000 inserts per second using a simple while loop inserting a small test document. But qr|qw still shows that there are the read- and write queue is still empty:
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn repl time
11234 *0 2 *0 1563 1|0 1 21.9g 44.3g 1.22g 0 testdb:58.9% 0 1|0 1|1 797k 980k 6 PRI 10:26:32
12768 *0 2 *0 1284 1|0 0 21.9g 44.3g 1.22g 0 testdb:58.0% 0 0|0 0|1 881k 1m 6 PRI 10:26:33
12839 *0 2 *0 1231 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.3% 0 0|0 0|1 883k 1m 6 PRI 10:26:34
12701 *0 2 *0 910 1|0 0 21.9g 44.3g 1.22g 0 testdb:61.8% 0 0|0 0|1 858k 1m 6 PRI 10:26:35
12241 *0 2 *0 1206 1|0 0 21.9g 44.3g 1.22g 0 testdb:56.7% 0 0|0 0|0 843k 1m 6 PRI 10:26:36
11581 *0 2 *0 1406 1|0 0 21.9g 44.3g 1.22g 0 testdb:61.8% 0 0|0 0|1 811k 1m 6 PRI 10:26:37
8719 *0 2 *0 1210 1|0 0 21.9g 44.3g 1.22g 0 testdb:43.8% 0 0|0 0|1 618k 762k 6 PRI 10:26:38
11429 *0 2 *0 1469 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.6% 0 0|0 0|1 804k 993k 6 PRI 10:26:39
12779 *0 2 *0 1092 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.2% 0 1|0 0|1 872k 1m 6 PRI 10:26:40
12757 *0 2 *0 436 1|0 0 21.9g 44.3g 1.22g 0 testdb:59.7% 0 0|0 0|1 838k 432k 6 PRI 10:26:41
I suppose this means that inserts alone won't cause a lot of troubles: "Queues will tend to spike if you’re doing a lot of write operations alongside other write heavy ops, such as large ranged removes." (found here]
My open question: What happens to my data if the write queue increases on long term?