PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Thursday the 18th of June, 2015

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[01:16:54] <jfhbrook> I have a mongodb that stops responding after a few hours of sustained writes. Where do I start in terms of diagnosis?
[01:17:07] <jfhbrook> Just like, in general, what are the first things you look at?
[01:18:54] <GothAlice> jfhbrook: WiredTiger? :3
[01:19:07] <jfhbrook> nope
[01:19:10] <jfhbrook> mongo 2.6
[01:20:09] <GothAlice> Hmm. Server load average is an indicator of a few things, and one place to start. If high, check the io stats and kernel log to see if your storage layer is failing.
[01:21:56] <GothAlice> (There's a higher-than-normal probability of storage issues on Amazon EC2 using EBS volumes, for one troublesome setup.)
[01:36:28] <jfhbrook> GothAlice: How high is high? How do you check io stats? I think I can google kernel log or at least get help with that
[01:36:41] <GothAlice> iotop is an easy way.
[01:37:03] <GothAlice> High is anything within 10% of the number of cores in the machine, or exceeding the number of cores in the machine.
[01:37:35] <jfhbrook> okay hold on
[01:37:44] <jfhbrook> what if the machine doesn't have iotop?
[01:38:47] <jfhbrook> yeah, I'm on the primary, no iotop
[01:39:22] <jfhbrook> It's not under the full load I'd expect right now but like worst case I know how to check for things when I *do* put it under load right?
[01:39:36] <jfhbrook> this might in fact be using EBS
[01:40:44] <GothAlice> jfhbrook: "uptime" gets you the current load average, amongst a few other stats.
[01:41:05] <jfhbrook> load average: 0.02, 0.04, 0.05
[01:41:06] <jfhbrook> hmm
[01:41:08] <jfhbrook> not very high
[01:41:42] <jfhbrook> and it's a little late to be running experiments
[01:43:18] <jfhbrook> oh yeah, the db I'm loading right now (different one, seeing if I get repro on it) is like load average: 0.00, 0.01, 0.05
[01:43:27] <jfhbrook> so that doesn't sound like it
[01:43:34] <jfhbrook> what else is a good idea to check?
[01:43:48] <jfhbrook> I already checked to make sure I wasn't chewing through ports somehow, that looks fine
[01:44:38] <jfhbrook> I can be more specific if you want, I know more things but I'm trying to figure out how to think like somebody that has to fix mongo
[01:45:11] <jfhbrook> I'll follow up on that EBS idea tomorrow though
[01:45:15] <jfhbrook> just to be sure
[01:46:50] <Boomtime> @jfhbrook: when you say "stops responding", do you mean it stops accepting writes, or just can't be logged in to at all (even with the mongo shell)?
[01:47:31] <jfhbrook> Boomtime: reads and writes from my api server either take very long or stop responding outright
[01:47:49] <jfhbrook> Boomtime: seeing if a parallel client also has problems around the same time is a good idea though
[01:47:54] <Boomtime> ok, which might just mean "got slow"
[01:48:03] <jfhbrook> order of minutes per query slow
[01:48:07] <Boomtime> have you checked the mongod.log file for around that time?
[01:48:09] <jfhbrook> yes
[01:48:16] <jfhbrook> so what happens is
[01:48:20] <jfhbrook> my API times out
[01:48:36] <jfhbrook> the mongo logs suddenly show nothing but secondaries disconnecting and reconnecting to the secondary
[01:48:40] <jfhbrook> for like 5 minutes
[01:49:08] <Boomtime> the interesting things probably occur before that
[01:49:09] <jfhbrook> then my API services disconnecting and reconnecting around the time my API service logs say "can't connect to stg-db01.mycompany.com"
[01:49:36] <jfhbrook> what kind of things are interesting?
[01:51:02] <jfhbrook> I saw what looked like mongodb queries and writes and not much else, but I also don't know what to look for
[01:52:42] <Boomtime> well, if your queries/writes just naturally take a little time, and your application just keeps sending more, and the queue backlog slowly grows, then eventually you'll get timeouts
[01:53:10] <jfhbrook> I'd see that in MMS somehow though, right?
[01:53:13] <Boomtime> thus, the "interesting" thing to look for will be similar looking queries/writes that are slowly taking longer each time they turn up
[01:53:22] <Boomtime> queues
[01:53:24] <Boomtime> in mms
[01:53:50] <jfhbrook> what if I don't think I'm running that many queries?
[01:53:54] <Boomtime> well, probably, the queues graph is most likely - cursors and connections will probably reveal something too
[01:53:57] <jfhbrook> like if I suspect that the machine's scaling fine in that regard
[01:54:12] <jfhbrook> connections are at a steady 700 (it's one cluster used for a bunch of services)
[01:54:28] <Boomtime> what's the group name?
[01:54:36] <jfhbrook> group name?
[01:54:42] <Boomtime> im me if you don't want to share it
[01:54:50] <Boomtime> mms group name
[01:55:00] <jfhbrook> umm
[01:55:03] <jfhbrook> what are you gonna do with it
[01:55:22] <jfhbrook> in case you haven't guessed, this is something I'm running into at work
[01:55:51] <Boomtime> i was going to look at it, but if you don't want me to that's fine
[10:09:21] <Garito> hi!
[10:09:38] <Garito> could someone help me with mongo-connector or tell me where to ask for this library on IRC?
[10:09:40] <Garito> thanks!
[10:26:10] <KekSi> hi there -- does anyone have a clue whether its possible to have multiple ssl certificates in a single PEMKeyFile (.pem) for mongod? so ip validation doesn't fail when i connect to my cluster on the local machine using 127.0.0.1 instead of the external IP?
[10:27:53] <KekSi> you generate the .pem file by concating cert and key into it so from that side it should be fine -- but does mongodb read beyond the first cert and key?
[10:38:31] <Garito> seems everyone is sleepy today
[11:54:07] <einyx> the init script for mongodb is badly broken
[11:54:21] <einyx> do you know if there is a fix on the way or something?
[11:58:30] <Garito> @einyx if you are using ubuntu they have change the boot process to systemd or something
[11:58:37] <Garito> perhaps you need to change too
[11:58:42] <einyx> not on 14.04
[11:58:49] <einyx> is still upstart
[11:59:35] <einyx> native deb package works beautifully - mongodb package doesn't
[11:59:57] <einyx> i'm on 3.0.4
[12:03:28] <Garito> this is correct
[12:03:35] <Garito> sorry I can't help here then
[13:07:13] <jacksnipe> So I have users who have friends. What's the best way to store this? I'm concerned about putting the "friendship" in both user documents because I can't update both atomically...
[13:12:39] <StephenLynx> IMO, that asks for a relational db. how central is this feature?
[13:12:54] <jacksnipe> Yeah that's what I was thinking too
[13:13:15] <StephenLynx> if you really need what mongo does, you could use two databases in your system.
[13:13:26] <jacksnipe> yeah I've been considering that
[13:13:38] <jacksnipe> This particular feature isn't central, it's just a mirror of our users's facebook friends graph so we don't have to make a million api calls per session
[13:13:46] <StephenLynx> ah
[13:13:59] <StephenLynx> in that case, I would have an array of friends in the user document.
[13:14:20] <StephenLynx> since you can always fetch them from facebook, its ok if they desync sometimes.
[13:14:21] <jacksnipe> yeah I guess inconsistency isn't a huge deal when we can check against fb to reconstruct the graph whenever
[13:14:22] <deathanchor> StephenLynx, but jacksnipe doesn't want to update two docs
[13:14:42] <deathanchor> I would use another collection for managing friendships
[13:14:44] <jacksnipe> well the reason I don't want to update 2 docs is to avoid data inconsistency when my system inevitably gets fucked up in the middle of an operation
[13:14:57] <StephenLynx> which as we concluded, can be easily recovered.
[13:15:08] <jacksnipe> right so it should be pretty safe
[13:15:40] <jacksnipe> I considered the "linkage table", deathanchor, I just don't know how efficient it would be (read: that's what I'd be using pgsql for, not mongo)
[13:16:49] <jacksnipe> hmm
[13:17:19] <deathanchor> identity collection, friendship collection, activity collection... noooo in my world they are lumped into one giant doc..
[13:17:33] <jacksnipe> well yeah because atomicity is important
[13:17:35] <StephenLynx> your case is different.
[13:17:53] <StephenLynx> in your case, these features are native.
[13:18:08] <StephenLynx> in jack's, they are just a pre-aggregation
[13:18:08] <deathanchor> atomicity is only important for each specific data set.
[13:18:11] <deathanchor> in my case
[13:18:18] <jacksnipe> Ah I see
[13:19:15] <jacksnipe> I'm willing to play catch up on maintaining consistency if it means that my queries are much, much faster (and that consistency CAN be rebuilt in big failure cases)
[13:19:40] <deathanchor> basically it becomes a big headache for me when activity writes are blocking me from creating/changing identity or from querying reads for it.
[13:20:06] <StephenLynx> but yeah, you did put too much stuff in a single document.
[13:20:13] <deathanchor> not I... devs..
[13:20:17] <StephenLynx> welp
[13:20:36] <deathanchor> I blame lack of crystal ball for seeing the future issues :D
[13:20:55] <StephenLynx> foresight is not magical.
[13:21:06] <StephenLynx> it comes with experience and dedication to software design.
[13:21:22] <StephenLynx> but when the guy don't give a hoot about the system, he will just #YOLO it.
[13:21:38] <deathanchor> hehe... well if I had foresight I would have contacted the original designers before I started working here to make my future job easier :D
[13:22:14] <deathanchor> nah if I could see the future I would have invested in some stocks or lottery tickets :D
[13:22:58] <deathanchor> jacksnipe: Just forewarning that you should account for how often the pieces of data are written to in your docs and how often you read from it.
[13:23:27] <deathanchor> does the later mongo version still have reads blocked while doing writes and vise versa?
[13:24:28] <jacksnipe> thanks for the advice guys
[13:25:09] <deathanchor> in mongo 2.2, a long read query blocks my writes per collection.
[13:25:22] <deathanchor> in tokumx I don't have this issue
[13:26:57] <deathanchor> tokumx does per doc locks for DML and the only thing you need to worry about is DDL ops.
[13:28:21] <deathanchor> IMO, tokumx = good for transient data, mongodb = good for established data
[13:29:31] <StephenLynx> "mongo 2.2" welp
[13:30:13] <jacksnipe> IIRC mongo has changed a lot since 2.2
[13:30:22] <jacksnipe> including document-level write-locking now
[13:30:26] <jacksnipe> tho that may be WT only
[13:51:41] <jacksnipe> BSON records can only be 16 MB right?
[13:53:05] <StephenLynx> yes
[14:02:42] <bjorn248> hello there, I understand a little bit about mongo storage (mainly the power of 2 allocation) but can someone explain this cyclical allocation and clearing of storage? https://www.dropbox.com/s/3rw13ck77vhs065/Screenshot%202015-06-18%2009.51.44.png?dl=0. You can see a 2GB allocation happen on 05/10 and 06/07, just am curious why it's cycling like that in between
[14:08:43] <bjorn248> is it the journal?
[14:13:31] <jacksnipe> is there a minimum size AWS instance type I should be using to host a mongod instance?
[14:17:36] <jacksnipe> should I go with memory optimized over general compute?
[14:17:53] <deathanchor> yes
[14:18:01] <deathanchor> memory is what prevents pagefaults
[14:18:18] <deathanchor> is there a sort option for mongoexport?
[14:19:30] <deathanchor> eh, I'll sort post op.
[14:58:26] <bjorn248> my guess is the journal or local db...since this cyclical data usage is not reported in MMS
[15:01:54] <Doyle> join #docker
[15:02:06] <Doyle> join #docker
[15:02:20] <GothAlice> Doyle: You'll need a bit of a / in front of that, if you want it to work. ;P
[15:17:01] <deathanchor> sure it was advertising? :D
[16:11:22] <pylua> can I use mongo client to execute js script?
[16:13:34] <KekSi> online webinar is up and running and i don't hear all that much of the voice :S
[16:14:04] <StephenLynx> webinar?
[16:14:21] <KekSi> mongodb & hadoop
[16:14:48] <KekSi> https://cc.readytalk.com/partlogin/ohxwardzseas
[16:14:57] <KekSi> its fixed now
[16:15:09] <StephenLynx> hm
[17:35:34] <r0j4z0> hi there! :D
[18:54:32] <saml> using j=true and fast writes and queries still fail
[18:54:49] <saml> Requiring journaled write concern in a replica set only requires a journal commit of the write operation to the primary of the set regardless of the level of replica acknowledged write concern.
[18:55:03] <saml> meh i guess there's no way to test integration
[18:57:08] <cheeser> ?
[19:47:40] <vruz> hello all, any idea when are the announced 3.2 improvements going to be available for the general public? I'm mostly interested in document integrity, and curious about "dynamic lookups", whatever those are.
[19:50:16] <brotatochip> hey guys, can anybody tell me if there is a built in role that grants access to the db.getReplicationInfo() method or, if not, help me to write a custom one for this?
[19:55:37] <brotatochip> This is what I've tried: db.createRole( { role: "testtRole", privileges: [ { resource:{ db: "admin", collection: "" }, actions: [ "getReplicationInfo" ] } ], roles: [] } )
[19:55:55] <brotatochip> It throws this error: Error: Unrecognized action privilege string: getReplicationInfo at src/mongo/shell/db.js:1347
[19:57:44] <cheeser> brotatochip: http://docs.mongodb.org/manual/reference/privilege-actions/#authr.replSetGetStatus
[20:32:55] <brotatochip> cheeser: my user already has access to that via the "clusterMonitor" role
[20:33:54] <brotatochip> I can rs.status() but I can't run db.getReplicationInfo() on the admin db, and I'd like to be able to grab the timeDiff
[20:49:08] <greyTEO> In the new mongo driver (3.0.2 java), has the bulk operations been replaced?
[20:49:52] <greyTEO> I no longer see initializeUnorderedBulkOperation, but there is an insertmany function.
[20:51:23] <cheeser> collection.bulkWrite()
[20:52:46] <cheeser> https://github.com/mongodb/mongo-java-driver/blob/conventions/driver/src/main/com/mongodb/client/MongoCollection.java#L270-270
[20:54:39] <greyTEO> cheeser, thanks
[20:56:03] <cheeser> np
[20:57:12] <greyTEO> cheeser, did they move it to a nw async driver?
[20:57:24] <greyTEO> or are the docs just making it look like that.
[21:00:06] <tty1> Can someone give me some help with this, I posted it to the mailing list but no one respondeD: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mongodb-user/Cy8o4iHG6CU/IMhLDAT-pE8J
[21:00:13] <tty1> By the way, i recently posted this project. Its for running a MongoDB instance inside maven as a plugin (requires no setup or even installation of MongoDB before hand).. mostly to setup integration tests: https://github.com/Syncleus/maven-mongodb-plugin
[21:00:20] <tty1> also, hello :)
[21:03:48] <cheeser> tty1: 1. 'sup? 2. i laughed when i saw your posting. here's my project: https://github.com/evanchooly/bottlerocket
[21:04:12] <cheeser> intended for using with junit/testng for spinning up clusters before test runs
[21:04:22] <cheeser> but suitable for any JVM app scenario, really.
[21:04:41] <tty1> cheeser: i wouldnt be against teaming up if you feel our projects might do better together?
[21:05:41] <tty1> cheeser: i mostly just wanted an easy way to get a mongodb instance running for testing.. but ti isnt really oriented towards clusters.. it does support ReplSetInitiate and --replSet but thats about it
[21:06:42] <tty1> cheeser: Also, if you deal with graph databases at all you might want to check out this other project of mine, it can use mongodb as a backend too. It is basically an ORM/OGM oriented towards graph databases and other backends: https://github.com/Syncleus/Ferma
[21:23:24] <whaley> tty1: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo ?
[21:24:12] <whaley> I, at one point when I was still working on a mongo project, had that hooked in to my test harness for integration tests. I went the maven route, but that mostly sucked for ad-hoc running of tests inside of IDEs.
[21:25:02] <tty1> whaley: that is indeed the dependency that makes my plugin work
[21:25:20] <tty1> whaley: pretty much just configures and runs flapdoodle from a maven plugin, and shuts it down when the lifecycle is done
[21:25:22] <whaley> that is to say, I started with it running in maven via pre/post-integration
[21:25:47] <tty1> whaley: much easier to use since you dont have to actually code against the library directly.. though has its down sides too.. my plugin is probably more useful for integration tests than unit tests
[21:26:09] <tty1> whaley: yea my plugin by default keys in to pre/post-integration lifecycles
[21:27:01] <whaley> didn't foursquare have some mockdb that was mongo java driver compatible at some point?
[21:27:30] <tty1> whaley: there is a mock interface specific for mongodb actually
[21:27:36] <whaley> fongo. I can't remember, but there was a reason I didn't touch that - probalby not a good one :)
[21:27:39] <tty1> whaley: havent used it but if you need to mock up mongodb id look there
[21:28:12] <tty1> whaley: https://github.com/thiloplanz/jmockmongo
[21:28:46] <whaley> "jmockmongo is a terribly incomplete tool to help with unit testing Java-based MongoDB applications. It works (to the degree that it works)" <--- +1 for self-deprecating honesty, at least
[21:29:06] <tty1> whaley: hahaha yea that is golden :)
[21:40:53] <sjmikem> Trying to use the built-in HTTP REST interface. When I visit http://mysite:20817/mydb/mycollection/ I get an HTTP authentication dialog as expected. However, the username and password I normally use to access mycollection is not working
[21:40:59] <sjmikem> any suggestions?
[21:59:11] <greyTEO> sjmikem, is that correct auth database?
[22:00:21] <sjmikem> greyTEO: from CLI, I can do: mongo -u user -p pass mydb ... does that help?
[22:01:23] <greyTEO> the auth credential might be in a different database then the one yuo are trying to access
[22:01:26] <sjmikem> I haven't fully grokked how auth works in mongo land
[22:02:16] <sjmikem> in our scripts that access the DB, they only use dbname, user, and pass... there's no separate auth db mentioned
[22:05:45] <greyTEO> correct me if Im wrong, but the username/pass can be in a different db than you are trying to access.
[22:06:47] <greyTEO> for instance if I want to access foo, but my user is in bar db, I need to tell mongo to look there for the crednetials
[22:08:24] <sjmikem> by default they are in the "admin" db, right?
[22:08:45] <greyTEO> I believe so
[23:03:57] <akoustik> i'm updating a subset of a collection, and i want to run a callback for each updated element. i'm not quite able to find the right magic google phrase for whatever reason.
[23:04:45] <akoustik> is there a "best" way to do this?
[23:09:10] <akoustik> i think i'm looking for a "findAndModify" that works on multiple documents.
[23:21:14] <akoustik> and i guess there have been a lot of people looking for something like that... non-existent, huh? oh well.
[23:21:51] <cheeser> there are no multiple document transactions, no.
[23:25:46] <akoustik> ok, thanks.
[23:34:21] <kaliya> hi, I have a --dbpath /var/lib/mongodb and this partition is full. I don't care of data, I can just trash them. Is it `stopping mongo; rm /var/lib/mongodb/db.0 db.1 db.2...etc ; start mongo` ok?
[23:34:41] <joannac> plus db.ns
[23:35:23] <kaliya> thanks joannac
[23:35:23] <joannac> which will remove all record of the database named "db"
[23:35:47] <joannac> assuming it's not a replica set or a sharded cluster
[23:38:14] <kaliya> mh it is a replicaset
[23:39:56] <joannac> then that's not valid
[23:42:35] <joannac> shut down all members and drop it from all of them, i guess?
[23:44:16] <kaliya> thanks joannac I will try that