Log file Viewer

[08:13:15] <Jinxit> yo

[08:13:46] <Jinxit> i have a mongodb on my server for a tool i'm using, what's the easiest way to "explore" the data?

[12:57:46] <OnkelTem> Hi all

[12:58:01] <OnkelTem> I'm new to MongoDB and to document-base dbms

[12:59:44] <OnkelTem> I have a quesiton about db architecture in multi-user env. Is it ok to provide dedicated collectoins for each user? If we talk about rdbms db, I'd say that creating tables for each user is not very good idea

[12:59:52] <OnkelTem> I wonder how this is considered in MongoDB

[15:43:50] <gl278afd> OnkelTem: MongoDB stinks

[15:43:54] <gl278afd> MongoDB is a rotten database

[15:43:56] <gl278afd> don't use it

[15:44:05] <gl278afd> go with Postgres, ArangoDB and anything else

[15:44:08] <gl278afd> avoid this mongodb shit

[15:46:45] <StephenLynx> kek

[15:46:52] <StephenLynx> someone`s mad :^)

[15:47:02] <StephenLynx> gl278afd, please, do tell us how you met mongo.

[15:47:24] <StephenLynx> and what was it`s role in your daily life.

[15:48:20] <gl278afd> Are you on the MongoDB Inc payroll?

[15:48:26] <StephenLynx> nope

[15:48:36] <StephenLynx> its just one of my db options.

[15:48:37] <gl278afd> MongoDB - made by idiots, made for idiots

[15:48:45] <StephenLynx> solid argument.

[15:48:48] <gl278afd> right

[15:48:49] <StephenLynx> v:

[15:48:53] <gl278afd> now move on tard

[15:49:09] <StephenLynx> cheeser, Derick GothAlice joannac

[16:16:01] <gl278afd> OnkelTem: and don't listen to the marketing blabla of MongoDB Inc

[16:25:41] <gl278afd> MongoDB...the most horrible noSQL database ever invented on this planet

[16:25:46] <gl278afd> horrible replication model

[16:26:00] <gl278afd> stupidities that like only index usable per query

[16:26:07] <gl278afd> who invented this bullshit?

[17:17:36] <GothAlice> StephenLynx: Apologies for not being conscious earlier. :)

[17:21:31] <GothAlice> Also, amusingly, one of the provided example "rage points" (the only theory I have is that gl278afd and their many clones may have had their career impacted by not RTFM'ing) is simply wrong: https://docs.mongodb.com/manual/core/index-intersection/

[17:26:37] <StephenLynx> GothAlice, np

[17:27:13] <StephenLynx> and yeah, I only asked him because tales of stupid people screwing themselves over always amuse me.

[17:35:28] <jr3> db.tournament.aggregate([{ $group: { _id: "$tournamentSize", stdDev: { $stdDevPop: "$bracket.teams.players.rankDivisionScore" }}} ]

[17:35:40] <StephenLynx> k

[17:35:50] <jr3> It's saying $stdDevPop is an unknown group operator?

[17:35:59] <jr3> https://docs.mongodb.com/manual/reference/operator/aggregation/stdDevPop/

[17:36:08] <jr3> straight from the docs

[17:36:14] <GothAlice> jr3: Check the version of the server you are on.

[17:36:34] <GothAlice> db.version() from the shell.

[17:36:34] <StephenLynx> also, check if the operator is valid for that operation.

[17:37:09] <jr3> ok, stdDevPop is 3.2

[17:37:11] <jr3> im on 2.6

[17:37:16] <GothAlice> jr3: That would do it. :)

[17:37:17] <StephenLynx> case soled v:

[17:37:22] <StephenLynx> solved*

[17:38:17] <jr3> soooo 2.6 doesn't have a stdDev :(

[17:38:30] <GothAlice> 2.6 is quite old at this point.

[17:38:43] <GothAlice> 3.0, 3.2, 3.4 is being finalized shortly, …

[17:39:11] <GothAlice> WiredTiger storage + compression alone make 3.2 worth the update.

[17:39:22] <GothAlice> (Let alone the many new awesome operators.)

[17:39:34] <jr3> guess I'll upgrade then!

[17:41:47] <GothAlice> jr3: https://docs.mongodb.com/manual/release-notes/3.2-upgrade/ should assist with that.

[17:42:06] <jr3> thanks GothAlice

[18:34:05] <LouisT> Hello, I have mongodb set up with 2 repl nodes and 1 arbiter, I'm using the official node module. For some reason if the arbiter restarts/reconnects the node module starts attempting to connect to the arbiter even when I have connectArbiter set to false. Anyone have any ideas? My arbiter log file gets filled with these: https://thepb.in/p/98hgcO4xDYZBOcQ

[18:35:24] <LouisT> If I restart my node.js processes then the connection attempts stop.

[18:44:30] <LouisT> Ah, apparently I was told to use connectArbiter when it no longer seems to exist in the newer driver.

[19:41:49] <LouisT> Okay so the problem is different than what I was lead to believe. For some reason it keeps trying to auth against arbiters which contain no auth information. Any ideas?

[20:29:21] <OnkelTem> gl278afd: wow

[20:38:21] <OnkelTem> Folks, so how is about my morning question? :)

[20:38:29] <OnkelTem> I have a quesiton about db architecture in multi-user env. Is it ok to provide dedicated collectoins for each user? If we talk about rdbms db, I'd say that creating tables for each user is not very good idea

[20:38:55] <OnkelTem> I wonder how this is considered from the MongoDB pov?

[20:42:21] <cheeser> it probably has many of the same drawbacks.

[20:42:53] <cheeser> you'd have separate indexes/files for each user. that might or might not be ok.

[20:45:49] <m0ltar> Hey guys & gals! Have an emergency! Upgraded Mongo on Debian. Now it won't start stating that "too many open files". Cannot figure out what to do. Nothing I do seems to affect max number open files on the system (Debian). Is there anything I can do on the mongo side?

[20:46:22] <cheeser> check your ulimit

[20:46:47] <cheeser> also, run lsof and see what has files open

[20:47:19] <OnkelTem> cheeser: I know very little about mongodb, don't even know where/how it stores data

[20:48:00] <OnkelTem> cheeser: what collection limit is reasonable for a avarage server - 1000, 100k?

[20:48:11] <m0ltar> @cheeser yeah I checked ulimit and all the related stuff... It is low. I just can't seem to raise it.

[20:48:33] <OnkelTem> do I have any options for storage engine for example?

[20:49:30] <m0ltar> every man or tutorial has no effect. ulimit -n always reports the same low 64k number, no matter what i do

[20:50:07] <m0ltar> I edited "/etc/security/limits.conf", "/etc/sysctl.conf", ran "sysctl -p"..

[20:50:13] <m0ltar> The only thing I haven't tried is a reboot yet

[20:51:29] <m0ltar> "lsof | wc -l" shows 1166141

[20:54:11] <m0ltar> Also odd thing is that when I run mongo as root, it actually starts. When it runs as mongodb under systemd it dies with "too many open files". But when I check limits on root account (ulimit -n) it shows the same limits as mongodb user...

[20:54:13] <m0ltar> I know that systemd's service file also is setting some limits, but I already commented that out...

[20:55:20] <m0ltar> For mongo process running under root, it only shows 2069 open files...

[20:55:24] <m0ltar> this is so strange

[20:56:05] <m0ltar> sudo -u mongodb bash -lc 'ulimit -H -n' -- shows 65536

[20:56:52] <m0ltar> ok taking final measures - going for reboot

[21:02:35] <m0ltar> restart didnt increase the limits :( mongo still dead

[21:02:41] <m0ltar> only runs as root

[21:05:09] <m0ltar> this is basically the main error in the log: Invariant failure: ret resulted in status UnknownError: 24: Too many open files at src/mongo/db/storage/wiredtiger/wiredtiger_

[21:05:11] <m0ltar> session_cache.cpp 79

[21:05:46] <cheeser> how many collections do you have?

[21:11:37] <joannac> try running `ulimit -a`

[21:24:11] <m0ltar> cheeser: 1410 collections

[21:24:22] <m0ltar> @joannac: I ran ulimit -a, that just outputs a limit. And then what? I've been through this already :D

[21:24:36] <cheeser> that's a lot but not ridiculous as such

[21:24:46] <m0ltar> ulimit reports 65536 for -n

[21:24:54] <m0ltar> cheeser: yeah I know ... bad decisions. ]

[21:24:58] <m0ltar> can't fix it now though :/

[21:25:03] <cheeser> did you look at lsof?

[21:25:05] <m0ltar> need to delete some collections

[21:25:12] <m0ltar> cheeser: yes I looked at lsof.

[21:25:57] <m0ltar> but again, what does it give me?

[21:26:05] <m0ltar> for entire system it was over a million

[21:26:10] <cheeser> it shows you what has all those files open

[21:26:10] <m0ltar> for mongo it was ~ 2k

[21:26:27] <cheeser> it might not be mongo that's exhuasting system resources.

[21:26:28] <m0ltar> that's the weird part, mongo is not hitting the limit

[21:26:32] <m0ltar> ah ok

[21:26:37] <m0ltar> right now it shows 1204047

[21:27:06] <m0ltar> no idea what could be using it, as the only major service is mongo on this box

[21:27:16] <m0ltar> is it a normal number of a debian system?

[21:27:40] <cheeser> lsof | wc -l

[21:27:40] <cheeser> 13958

[21:27:45] <cheeser> that's my system right now

[21:28:34] <m0ltar> :|

[21:29:13] <cheeser> now, if you'll excuse me. time to go make breakfast for dinner. :D

[21:29:17] <cheeser> good luck!

[21:29:29] <m0ltar> lsof | grep mongod | wc -l --- 994911

[21:29:35] <m0ltar> so it is mongo using most open files ...