PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Monday the 11th of August, 2014

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[01:56:58] <BigOrangeSU> Does anyone know how to start the MMS monitoring agent on a debian machine. It appears the command " start mongodb-mms-monitoring-agent" yields "start command not found"
[02:12:26] <joannac> BigOrangeSU: how did you install it?
[02:13:03] <BigOrangeSU> joannac: I think i figured it out, http://mms.mongodb.com/help/tutorial/install-monitoring-agent-with-deb-package/ states to do "start mongodb-..." but the correct command is "mongodb... start"
[02:13:10] <BigOrangeSU> however i am still getting host unreachable
[02:13:37] <BigOrangeSU> joannac: I followed the instructions, curled the debain package
[02:13:52] <BigOrangeSU> and ran the command, then I started the agent using nohup, not sure if there is a startup-script out there
[02:15:03] <joannac> weird... that sounds like a problem in the docs :(
[02:15:28] <joannac> does 'service mongodb-... start' work?
[02:17:56] <BigOrangeSU> jonnanc: let me check
[02:17:57] <joannac> BigOrangeSU: if you let me know your OS and version, I'll file a docs ticket for you
[02:18:14] <BigOrangeSU> its the debian instructions, http://mms.mongodb.com/help/tutorial/install-monitoring-agent-with-deb-package/
[02:18:25] <BigOrangeSU> joannac: no way should it be "start ...", start is not a valid command
[02:19:00] <BigOrangeSU> joannac: if i have the server setup with a replica set (However it is a single server) when configuring the host in mms should i use replicaset or singel server?
[02:19:18] <joannac> BigOrangeSU: I believe 'start ...' is a thing added by Ubuntu
[02:19:27] <joannac> BigOrangeSU: add it as a replicaset
[02:19:50] <BigOrangeSU> joannac: ok, mongodb-mms-monitoring-agent: unrecognized service
[02:20:13] <joannac> BigOrangeSU: OS and version?
[02:21:17] <BigOrangeSU> http://justpaste.it/gky0
[02:21:28] <BigOrangeSU> 2.6.32-5-xen-amd64
[02:21:31] <BigOrangeSU> debian
[02:22:52] <BigOrangeSU> joannac: any ideas for troubleshooting connectivity on MMS, not sure what the log messages mean
[02:23:18] <BigOrangeSU> joannac: I think I figured out the issue
[02:23:32] <BigOrangeSU> MMS must be using AWS, I didn't register my dns name inside aws
[02:28:35] <BigOrangeSU> joannac: I am now using the internal ip and still no luck :(
[02:29:53] <joannac> BigOrangeSU: open an MMSSUPPORT ticket at jira.mongodb.org
[02:29:54] <BigOrangeSU> joannac: i see the monitoring aggent is connected, but not able to get the host to connect
[02:31:34] <BigOrangeSU> joannac: for the documentation issue?
[02:33:56] <joannac> well, I'm writing a DOCS ticket for you
[02:34:02] <joannac> but for the connection issue
[02:36:52] <BigOrangeSU> joannac: sweet news, its up
[02:37:24] <BigOrangeSU> joannac: no data yet, but its green
[02:37:31] <joannac> cool
[04:57:16] <BigOrangeSU> Hmm I am having problems with MMS, for some reason my host keeps loosing connections. Not sure what is going on. The only weird thing I see is that under the monitoring agent log, i see a failure to dial host but that originates not from the host that is down.
[05:29:00] <joannac> BigOrangeSU: opened a ticket?
[05:29:16] <BigOrangeSU> joannac: yep but i feel like i need to dig into it a bit more
[05:30:13] <BigOrangeSU> joannac: i think it has something to do with the fact that there is another set of servers that have monitoring agents, but those monitoring agents might not have access to that specifci server
[05:30:23] <joannac> erm okay
[05:30:31] <joannac> MMS groups are one agent per group
[05:30:57] <joannac> if you have 2 sets of hosts (e.g. prod, dev) and they're network partitioned, you need 2 groups
[05:31:29] <BigOrangeSU> how do you create a new group?
[05:31:37] <joannac> If you've opened a new ticket in the last 15 minutes, I think I see it :)
[05:31:46] <BigOrangeSU> yea i did
[05:31:49] <joannac> Users -> Add new group
[05:32:04] <BigOrangeSU> ahhhhhh
[05:32:05] <BigOrangeSU> grousp
[05:32:13] <joannac> (yes that's not intuitive. I've opened a ticket)
[05:33:13] <joannac> so to be clear, in a group, a single agent must be able to connect to all hosts in that group
[05:33:32] <BigOrangeSU> joannac: didn't realize you were 10gen
[05:37:53] <BigOrangeSU> omg that group thing
[05:38:32] <BigOrangeSU> joannac: how do I drop an agent form a group?
[05:40:21] <joannac> BigOrangeSU: can you post these in your MMSSUPPORT ticket?
[05:40:25] <joannac> these questions*
[05:40:40] <BigOrangeSU> joannac: sure are you 10gen?
[05:41:30] <Boomtime> even if she is, i'm prettu sure she isn't the only one
[05:52:12] <BigOrangeSU> problem solved
[05:52:21] <BigOrangeSU> i had to add the name of the server to the host file
[05:52:55] <joannac> Awesome. So the ticket can be closed?
[05:58:22] <BigOrangeSU> joannac: yea, you can close the ticket
[05:58:24] <BigOrangeSU> :)
[05:58:37] <BigOrangeSU> joannac: you guys need some WAY better documentation on groups DAM
[05:58:57] <BigOrangeSU> joannac: also the fact that the monitoring agent is irrelevant of the deployment
[05:59:44] <joannac> BigOrangeSU: could you elaborate on the ticket what you want better documentation around?
[06:00:01] <joannac> for example, I don't understand what you mean by "the monitoring agent is irrelevant of the deployment"
[06:18:11] <BigOrangeSU> joannac: it means that the monitoring agent isnt tied to the servers which have mongo running, infact the monitoring agent could be on a completely different instance then the mongo servers
[06:23:05] <Boomtime> BigOrangeSU: https://mms.mongodb.com/help/faq/monitoring/#where-should-i-run-the-monitoring-agent
[06:24:20] <BigOrangeSU> BoomTime: that is a great FAQ, which I had read it earlier
[06:24:27] <Boomtime> :D
[08:28:50] <_boot> are there any changes in 2.4->2.6 which would cause the same data to use significantly more space? gone from like 94GiB to 134GiB
[08:35:46] <rspijker> powersOf2 has become standard iirc
[09:06:09] <fatih> hi
[09:06:21] <fatih> does brew install mongodb only install the client or also mongodb itself ?
[09:06:35] <fatih> because I'm already using mongodb in docker and don't want to pollute my system with another mongodb
[09:06:43] <fatih> I only need the client
[09:07:31] <rspijker> just look at the formula?
[09:52:32] <BaNzounet> Hey guys, I've to update my schemas, so I've to update each document one by one outside of mongodb right?
[10:34:16] <obiwahn> ?
[10:34:38] <Derick> !
[10:41:52] <obiwahn> .oO(he uses dump and then changes the entries with notepad:)
[10:42:39] <Derick> BaNzounet: what did you mean there?
[12:35:16] <dmitchell> btw: I found out that pymongo 2.4 against Mongo 2.2.0 w/ an index on multiple fields including a collection field incorrectly reports cursor.count()
[12:35:45] <dmitchell> I'll look for an existing bug report in jira and I ack that we should upgrade both pymongo and mongo, but I can only advocate the upgrade
[14:23:51] <oleg0081> Hi everybody
[14:23:57] <Derick> hi
[14:24:17] <oleg0081> Hi Derick, I need a second to explain my question
[14:25:11] <oleg008> I am using latest mongodb
[14:25:23] <oleg008> and I have this query db.articles.find({ '$or': [ { tags: { '$all': [ 'javascript objects', 'object', 'rcss' ] } }, { tags: { '$all': [ 'aws', 'software engineer', 'software foundation' ] } }, .....
[14:25:51] <oleg008> the length of $or array can get up to hundrends of items
[14:26:13] <oleg008> right now I have 3.5gb database of articles, and it looks like it becomes slower and slower
[14:27:09] <oleg008> index seems to be used correctly
[14:27:11] <oleg008> > db.articles.find({ '$or': [ { tags: { '$all': [ 'javascript objects', 'object', 'rcss' ] } }, { tags: { '$all': [ 'aws', 'software engineer', 'software foundation' ] } }]}).explain()
[14:27:11] <oleg008> {
[14:27:11] <oleg008> "cursor" : "Complex Plan",
[14:27:11] <oleg008> "n" : 0,
[14:27:11] <oleg008> "nscannedObjects" : 0,
[14:27:12] <oleg008> "nscanned" : 4,
[14:27:12] <oleg008> "nscannedObjectsAllPlans" : 0,
[14:27:13] <oleg008> "nscannedAllPlans" : 4,
[14:27:13] <oleg008> "nYields" : 0,
[14:27:14] <oleg008> "nChunkSkips" : 0,
[14:27:14] <oleg008> "millis" : 11,
[14:27:15] <oleg008> "server" : "olegs-air:27019",
[14:27:15] <oleg008> "filterSet" : false
[14:27:16] <oleg008> }
[14:27:19] <rspijker> dude
[14:27:21] <rspijker> pastebin
[14:27:56] <rspijker> I don’t think 11ms is that slow, btw
[14:28:06] <oleg008> Derick should I pastebin or you got already what I mean?
[14:28:34] <oleg008> 11ms is totally fine, but its $or with 2 items, I have similar query with 100 items and it takes 200seconds
[14:28:44] <Derick> oleg008: never paste in here, always use a pastebin
[14:28:53] <oleg008> ok just a second
[14:29:14] <rspijker> you don’t need to pastebin the same thing now… just for future reference
[14:29:54] <Derick> it says "Complex Plan"... now that is a new one for me
[14:30:09] <oleg008> anyways pasted http://pastebin.com/xxhBnrgL
[14:30:19] <oleg008> you mean you don't know this plan?
[14:31:05] <Derick> correct
[14:31:15] <Derick> i need to shutdown some connections, massive thunderstorm here
[14:31:24] <oleg008> its a new feature introduced in 2.6
[14:31:41] <oleg008> I can give you jira reference if you want
[14:32:12] <oleg008> basically its exactly for my use case
[14:32:43] <oleg008> I was in contact with some employers 10gen some time ago as this feature has been implemented
[14:32:52] <oleg008> it seem to work also
[14:33:07] <oleg008> but i never tried to run it with that length of $or
[14:33:09] <rspijker> it’s just index intersectin, right?
[14:33:14] <rspijker> intersection*
[14:33:35] <oleg008> I don't know a lot about implementation details
[14:33:44] <oleg008> looking for jira issue
[14:36:42] <oleg008> https://jira.mongodb.org/browse/SERVER-1205
[14:37:59] <oleg008> so my quesion is actually: why its so slow when lots of $or statements
[14:38:09] <rspijker> so… is the query you showed above a good representation? Or do you also use other features like limit and sort?
[14:38:38] <oleg008> I do
[14:38:42] <oleg008> wait
[14:40:32] <oleg008> this is more accurate version of my query
[14:40:32] <oleg008> http://pastebin.com/RQJc5jbw
[14:41:37] <oleg008> and here is query AND my indexes
[14:41:38] <oleg008> http://pastebin.com/K2xEBsbM
[14:42:31] <ernetas_> Hey guys.
[14:42:51] <ernetas_> We upgraded from 2.4 to 2.6... And the connection count increases very fast. What could be the issue?
[14:43:11] <rspijker> oleg008: so why on earth would that use a complex plan? Looks like you have a fine index for it...
[14:43:21] <rspijker> unless it;s due to the $or and that’s some kind of special case...
[14:43:27] <Derick> rspijker: "or" means two "threads"
[14:43:41] <oleg008> rspijker because of $or
[14:43:44] <rspijker> two? or “n: Derick ?
[14:44:00] <rspijker> as in, 1 thread per clause, or always 2?
[14:44:40] <ernetas_> After it reaches a couple of thousand, CPU load becomes 100% on all cores... :/
[14:45:08] <Derick> rspijker: "n"
[14:45:38] <rspijker> ok
[14:46:18] <rspijker> which version are you on oleg008 ?
[14:46:45] <oleg008> 2.6.2
[14:47:32] <oleg008> can quickly upgrade to 2.6.3 if you think this might help
[14:48:15] <rspijker> not sure, I did find an issue that was solved in 2.6.2, but that shouldn;t affect you anymore than
[14:49:09] <rspijker> ernetas_: all drivers updated as well?
[14:49:14] <oleg008> I mean even if it spends 20ms on every $or item, it should be 2s on 100 items
[14:50:00] <rspijker> assuming it’s linear and sorting is free, sure...
[14:50:07] <rspijker> can you show us an explain of your actual query?
[14:50:30] <oleg008> you mean with 100 items?
[14:51:03] <ernetas_> rspijker: yeah
[14:51:27] <rspijker> oleg008: yes
[14:51:44] <oleg008> also what I see from currentOp() is numYields 30206 and threadId is always the same
[14:52:02] <rspijker> ernetas_: any other clients running (I had connection issues with rockmongo in the past)
[14:54:44] <oleg008> @rspijker just a second, also if you want I can give you direct access to the db
[14:55:10] <rspijker> that’s ok, let’s have a look at the explain first
[14:56:22] <ernetas_> rspijker: nope.
[14:56:37] <ernetas_> Just PHP mongodriver.
[14:57:35] <remonvv> \o
[14:57:38] <rspijker> o/
[14:57:40] <remonvv> mongodb.org down?
[14:57:50] <Derick> hmm, seems so
[14:57:52] <rspijker> ernetas_: checked the logs? Anything in there that might explain it?
[14:57:53] <remonvv> I realize I might be the 15th person pointing this out
[14:58:10] <remonvv> A lot of instance shit is failing on us atm.
[14:58:14] <tscanausa> Looks like it from here
[14:58:22] <rspijker> you are the first, actually
[14:58:24] <oleg008> and here is the explain with the query together http://pastebin.com/kRY8Af0a
[14:58:25] <remonvv> Derick, who do we fire on your end?
[14:58:26] <rspijker> at least, in here
[14:58:32] <remonvv> Oh.
[14:58:37] <Derick> remonvv: "ops is working on it, so I hear"
[14:58:37] <remonvv> Well, I like to be original.
[14:59:00] <remonvv> "ops broke it in the first place <sadface>"
[14:59:04] <remonvv> Derick: Ok ;)
[15:00:38] <oleg008> streange thing is that it runs now in ~8 seconds, probably database is now wormed up
[15:00:43] <rspijker> oleg008: hmmm, no info on the sort? :/
[15:01:16] <oleg008> yeah strange, no?
[15:01:33] <rspijker> yes…
[15:01:34] <remonvv> Database worms fix everything
[15:02:13] <oleg008> I mean warmed up, typo
[15:03:35] <remonvv> I know ;) I was being funny.
[15:03:40] <remonvv> And failed miserably :s
[15:04:02] <tscanausa> remonvv: seems to be back upish now
[15:04:23] <rspijker> still fairly downish here
[15:04:26] <remonvv> tscanausa: Not for me. Not yet anyway.
[15:04:45] <tscanausa> yay godaddy!
[15:05:44] <rspijker> good thing they’re at least loading jquery to get me that error page… :/
[15:07:00] <oleg008> rspijker I just run the same query again, it delivered results in 1 sec with 3 yields
[15:07:15] <tscanausa> looks like they switched to aws so dns probably needs to propagate out.
[15:08:57] <rspijker> oleg008: weird…
[15:09:20] <oleg008> I don't get it too
[15:09:41] <rspijker> well, if it was initially all paged out then it could be significantly faster now
[15:09:52] <rspijker> still… this seems like an awful big difference
[15:10:03] <oleg008> even if it has everything in memory, can this be that huge difference
[15:10:07] <oleg008> yeah
[15:10:36] <oleg008> the worst thing I don't know if I need to redesign the database or not
[15:10:48] <oleg008> because 1-2 sec is ok, I don't need to design additional caching
[15:11:03] <oleg008> but if it takes 3 minutes …
[15:20:23] <amcgregor> I take it I'm not the only one seeing a GoDaddy hosting message when accessing mongodb.org?
[15:20:33] <rspijker> you are not
[15:20:40] <Derick> nope, there are some DNS issues right now. It's being worked on.
[15:26:24] <amcgregor> Woot, content seems back up. Looks like I'm just waiting for propagatation of media.mongodb.org now. Great turnaround on that.
[15:33:14] <ernetas_> rspijker: nothing. Just that many queries are slowing down.
[15:33:46] <bwellsnc> Hey guys, what happened mongodb.org?
[15:33:56] <amcgregor> DNS is freaking out a bit.
[15:34:00] <bwellsnc> Ah ok
[15:34:09] <amcgregor> It's already better than it was. ^_^
[15:34:22] <rspijker> ernetas_: ok, no clue then…. :/ No apparent reason with the 2.4 -> 2.6 switch afaik
[15:34:33] <bwellsnc> It's back now, thanks guys
[15:34:41] <rspijker> Derick: knows a bit more about the PHP driver, and mongodb in general, so he might have some insight :)
[15:39:56] <ernetas_> Derick: any ideas? :/
[15:41:05] <Derick> ernetas_: sorry, missed the question
[15:52:34] <ernetas_> Derick: after MongoDB upgrade from 2.4.10 to 2.6.4, there is extremely high CPU load, probably caused by a slowly and steadily incresing connection count (which doesn't happen straight after mongodb restart, by the way). The only client is PHP Mongo driver.
[15:54:01] <cheeser> are you properly closing your connections in your php code?
[15:54:47] <amcgregor> ernetas_: I've had problems with old pymongo clients in multi-threaded environments not releasing connections properly in an automatic way. An explicit disconnect at the end of processing might be useful. (How is your PHP running? php-fpm?)
[15:55:26] <ernetas_> We're running php-fpm. I'm not sure about closing connections in PHP code, but rolling back to mongodb 2.4 helped for now.
[16:12:19] <sfix> can I group by month using the aggregation framework?
[16:13:26] <amcgregor> $group: {_id: {month: {$month: '$somedatefield'}}}
[16:13:39] <amcgregor> sfix: ^ might do it for you
[16:14:26] <amcgregor> I think you need a pretty recent MongoDB service, though.
[16:14:58] <sfix> amcgregor, yeah I'm running 2.6.3, that looks pretty much like what I have
[16:15:04] <sfix> ah I need to have the month inside _id {}
[16:15:23] <amcgregor> Yup; in a $group operation the _id is the combining factor.
[16:15:38] <amcgregor> Other attributes let you perform aggregate math operations, outside the _id.
[16:15:47] <amcgregor> ($sum, $avg, etc.)
[16:16:10] <sfix> right, gotcha. thanks amcgregor :)
[16:16:38] <amcgregor> It never hurts to help.
[16:44:07] <remonvv> Not true. If you help someone to pick up fire ants it will hurt.
[23:42:28] <Pish> In an Ubuntu 12.04, I'm following the "Install MongoDB on Ubuntu" instructions, but when issuing sudo apt-get update I get several errors like: W: Failed to fetch http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/Packages Got a single header line over 360 chars. Is there something wrong with the repositories?
[23:43:17] <Pish> If I try again I get this error: E: GPG error: http://downloads-distro.mongodb.org dist Release: The following signatures were invalid: NODATA 1 NODATA 2