Log file Viewer
#mongodb logs for Tuesday the 8th of December, 2015
[08:35:38] <joroci> i'm using angular-meteor and i was wondering if there is a way to listen for changes in a subscription
[10:19:29] <dylush> hello im trying to do an update on a model but its returning an error saying the immutable field id has been altered?
[14:25:23] <wawrek> i wanted to know if there are some possibilities of doing data processing within aggregations - turning some lists to objects (i.e. ['name', 'description'] -> {name: 'name', description: 'description'}). I know map reduce is meant to do that...
[14:32:32] <StephenLynx> what I do is to just check if the array is not empty and if so, get the first element and use it.
[14:32:49] <wawrek> I know, but within my documents there are nested lists - I want to process these
[14:34:21] <wawrek> lets say {_id: 123123, list: [['name', 'desc']]} should become {_id: 12313, list: {name: 'name', description: 'desc.'}}
[14:38:23] <StephenLynx> using index on arrays for meaning is one of the worst db practices you can do.
[14:39:00] <StephenLynx> you could perform the conversion on the communication with this external system
[15:29:59] <watmm> Trying to evaluate how important a fast disk is for a migration i want to do. How would i find the percentage of write operations?
[15:48:53] <livcd> so i am connected via mongo client how do i display a server / shard information about current session
[15:54:21] <Captain_Haddock> MongoDB 2.6 and PHP 5.6: MongoCursorException: "localhost:27017: could not find cursor over collection foo.bar"
[15:55:29] <Captain_Haddock> (MongoCursor::$timeout = -1;) <-- Setting this improved matters, but I'm still seeing the exception.
[16:02:49] <Captain_Haddock> cheeser: I'm not really seeing anything that stands out. [conn17] end connection 127.0.0.1:58614 (5 connections now open)
[16:03:09] <Captain_Haddock> [initandlisten] connection accepted from 127.0.0.1:59384 #18 (6 connections now open) and lots of [clientcursormon] mem (MB) res:115 virt:975
[17:23:30] <diegoaguilar> I tried with https://docs.mongodb.org/master/tutorial/install-mongodb-on-ubuntu/
[18:11:04] <diegoaguilar> tried echo "deb http://repo.mongodb.org/apt/ubuntu precise/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list
[18:11:24] <diegoaguilar> and echo "deb http://repo.mongodb.org/apt/ubuntu precise/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list
[18:11:40] <diegoaguilar> so when updating ... W: GPG error: http://repo.mongodb.org precise/mongodb-org/3.2 Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D68FA50FEA312927
[19:16:14] <Bish> hi mongofolks, how would you have a relation in mongdo ( i know mongo is slow when it comes to relations )
[19:16:28] <Bish> but what if you want to store a list of data in mongo, like a list of emails, how would you do it?
[19:17:03] <Bish> is it considered dirty to programmaticially creating a collection as kind-of grouping data? i suppose so
[19:43:27] <newbsduser> hello, is there specific disadvantage to change BSONObjMaxUserSize ? iam compiling mongodb for that
[19:47:29] <newbsduser> hello, is there specific disadvantage to change BSONObjMaxUserSize ? iam compiling mongodb for that
[21:03:41] <GothAlice> Heh. I'm most excited about the update to text indexes. It was super basic before. Still pretty basic, but at least you can control tokenization a bit, and diacritic insensitivity is somewhat critical for multilingual apps.
[21:04:44] <GothAlice> So I _might_ be able to finally get rid of the Okapi BM-25 implementation I wrote before MongoDB had any text indexes, which I've been using to this day because it gives me full control over content extraction and tokenization. :P
[21:05:59] <GothAlice> https://docs.mongodb.org/manual/tutorial/specify-language-for-text-index/ < or not. Ugh. My documents contain multiple languages of data.
[21:06:35] <GothAlice> Ah, never mind, I see what they're doing. I initially interpreted that as per-document, but that includes sub documents. Saved!
[21:10:51] <GothAlice> "Only one positional $ operator may appear in the projection document." Rats, doesn't look like one of my followed tickets was finished enough for release.
[21:20:46] <GothAlice> Doyle: Index building happens one of two ways: fast blocking, where indexing must complete before anything else can happen, or background. Background can be insanely slow, so to prevent your data from being accessed long-term without indexes (while they build), after an initsync the indexes are built with fast blocking.
[21:21:05] <GothAlice> See step three which implicitly states that by blocking the normal state until completion: https://docs.mongodb.org/manual/core/replica-set-sync/#replica-set-data-synchronization
[21:22:13] <GothAlice> https://docs.mongodb.org/manual/core/replica-set-sync/#multithreaded-replication
[21:23:36] <GothAlice> But always remember: background index builds (post-initsync) can take geometrically more time than blocking. (Not linear with the amount of data.) To the point that you may think it's stuck. ;P
[21:26:39] <GothAlice> The background version of that could take a week or more, depending on DB activity levels. XP
[21:37:08] <Doyle> Documentation confusion with "While applying a batch, MongoDB blocks all read operations. As a result, secondary read queries can never return data that reflect a state that never existed on the primary."
[21:37:24] <Doyle> Could it be updated to say "no longer exists on the primary"? I think that's what it's getting at
[21:37:51] <Boomtime> secondary reads can absolutely return data that no longer exists on the primary
[21:38:27] <Boomtime> what the secondary promises is that you will never observe the database in a state that did not once-upon-a-time exist on the primary
[21:39:16] <Boomtime> thus, if you update document A then document B, the secondary will never let you see the document B update without the document A update already applied
[21:40:35] <Boomtime> right, all operations take place (effectively) in the same order as they did on the primary
[21:43:02] <Boomtime> certainly the secondary doesn't invent anything, but if it permitted operations out of order then things would get weird really quickly
[22:47:17] <GothAlice> Doyle: The documentation is great; I can highly recommend reading it and searching it frequently. https://docs.mongodb.org/manual/reference/method/db.currentOp/#active-indexing-operations
[22:48:03] <GothAlice> Stack Overflow provides a more filled-out example: http://stackoverflow.com/a/15597312
[22:52:06] <GothAlice> The difficulty may be connecting before the node is ready to accept connections in order to query that. ;)
[23:22:18] <lkannan> Hey guys! Trying to figure out an issue where mongo spins at 100% CPU. Turned on profiling and see a specific write query that are slow. strace just spits out SELECT(). I turned off my app and still see the SELECT(). Without the app turned on, mongo is at 10% CPU. I have serverStats() info as well. mongo version 2.4.9. I don't want to bombard with info. If
[23:23:29] <GothAlice> lkannan: Do you have a support contract with 10gen? If so, that would be best serviced by a JIRA ticket. 2.4 is also… ah… beyond my own ability to assist with at this stage. :/
[23:24:06] <GothAlice> Esp. since 2.4.14 is "current" for that series, and may have fixed any underlying bugs you may be hitting.
[23:25:29] <lkannan> No support contract. Figured 2.4 is too old :). I'd appreciate any pointers as to how to chase things down. Upgrade is a plausible option. I have a strong feeling this is somehow related to a bad query rather than us hitting a serious db issue.
[23:26:30] <lkannan> Slow query and serverStats() https://gist.github.com/lakshmi-kannan/1abf658bc451874b4895. What number looks ominous here?
[23:26:43] <GothAlice> Quite likely, yes, but supporting non-current is more difficult because of the possibility. Let me dig up a link for you then I'll read through that gist.
[23:28:01] <GothAlice> To see what's been fixed in newer releases in the 2.4 series since the version you're on, use "project = SERVER AND fixVersion in (2.4.10, 2.4.11, 2.4.12, 2.4.13, 2.4.14)" as an advanced query on jira.mongodb.org
[23:29:45] <GothAlice> Hmm. Looks like the problem would have existed before the traced query; a single element $pushAll against a specific _id should be an effectively O(1) atomic operation.
[23:31:12] <GothAlice> Two concerns come to mind without knowing the surrounding context: pushing values into a record may require the record to be re-sized, and subsequently moved if there isn't enough head-room. With very large documents (talking ones approaching the maximum size) this can be expensive. Additionally, if you are missing an index on _id (it can happen), bad things will happen. ;P
[23:31:29] <lkannan> Yep, the slowness of the query is a little sketch. I am not seeing any queries to db other than that when I do mongod --profile=1 --slowms=15. Missing anything?
[23:31:43] <GothAlice> So getting a dump of the available indexes, and some collection stats on average document size, may indicate trouble spots.
[23:33:21] <GothAlice> There is an off chance that a supposedly fast query is what is setting off a chain of events resulting in slowdown.
[23:33:29] <lkannan> I did try to set profile=2 in mongodb.conf and I wasn't confident profiling was ON from the logs. Maybe because I was expecting the app to do while(1): ddos_mongo.
[23:34:22] <GothAlice> Heh. The logs, even in profile=2, only log slowms queries, I believe. The other queries are written to the profiler collection. Dex examines that collection.
[23:34:44] <GothAlice> (This is a good way, as well, to audit the full chain of queries from clean start to problem showing up.)
[23:34:57] <lkannan> So other than profiling, how can I look at what exactly mongo is doing? strace isn't helping much. Yep, read about the profiler collection. It's a little counter intuitive coming from other dbs.
[23:35:21] <GothAlice> MongoDB "eats its own dog food" a lot, in terms of using its own features to help implement other features.
[23:37:31] <GothAlice> Hmm; not actually familiar with the Linux side of debugging. However, I've pointed out several things you can get diagnostic information on, any one of which may result in apparent slowdown.
[23:38:36] <GothAlice> (Ensure _id is indexed, check your document size, esp. the size of the document being updated in the apparently "bad" query, and audit the full chain of queries from clean start to error state.)
[23:40:28] <GothAlice> In the latter case, Dex can help out by pointing out queries that aren't using an appropriate index.
[23:41:28] <lkannan> https://gist.github.com/lakshmi-kannan/31bb4e45865d5448d27b doc size. _id indexed. missing units. looking up.
[23:43:20] <GothAlice> lkannan: One thing I do notice that is interesting, is that the "supposedly bad" query is needing to update an index: trigger_instances.object_id_1
[23:44:15] <GothAlice> lkannan: Is the problem in production or development, and if in production, have you been able to reproduce on a copy of the data? If so, you might try rebuilding that index to see if updating that index during the query is the underlying problem.
[23:46:09] <lkannan> It is `production`. Trace is a nice-to-have feature. So in theory, I should be able to drop the collection to validate if that's the collection that's causing issues. That would be my last resort.
[23:48:30] <GothAlice> Well, I wouldn't recommend dropping the collection. Worst case, it can be rebuilt. (Worst-worst case is nuking the whole collection. ;) A better case is that it's just the trigger_instances.object_id_1 index that needs to be rebuilt, if that $pushAll query actually is the trigger.
[23:48:42] <Doyle> lkannan, any host level issues evident? 'iostat -xmt 1', free -m, df -h, htop, if raid - is it healthy or resilvering...
[23:50:03] <lkannan> also, checked free -m etc. everything seems reasonable. VIRT size for mongo process is 96G. Little sketchy but I guess it's because of mmaped files?
[23:50:28] <GothAlice> https://gist.github.com/amcgregor/4fb7052ce3166e2612ab#whats-the-deal-with-rss-and-vsz-memory-allocated-to-mongodb
[23:52:11] <GothAlice> Luckily, with that small number of records and overall small index size, rebuilding the suspect index should be quite quick.
[23:53:07] <lkannan> So is there a way to rebuild a specific index? We have six indexes for that collection. https://docs.mongodb.org/manual/reference/method/db.collection.reIndex/
[23:56:58] <GothAlice> cheeser: Can't wait to test out "stable" WiredTiger this week-end. I get schadenfreude from myself when getting to break things: http://s.webcore.io/3i1L2D0R3l3V
[23:58:32] <GothAlice> Not at all. (It's a subset of our click tracking data we use to benchmark and test MongoDB updates. ;)
[23:58:59] <GothAlice> It's just… very, very intensive. Talking ~5 minutes to work through that, running 4-way parallel.