PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Sunday the 3rd of April, 2016

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[16:23:03] <Forbidd3n> Hello everyone. In shell, I use admin, createUser and I can still write to the database even without the required login credentials - What would I be missing?
[16:32:02] <Forbidd3n> MongoDB won't start on Centos using security: authorization: enabled in /etc/mongod.conf
[16:40:13] <Forbidd3n> Anyone?
[17:47:37] <Sagar> hello
[17:47:44] <Sagar> my mongodb is not starting nor it's showing any errors
[17:47:49] <Sagar> can anyone please help?
[18:18:52] <macwinne_> i have a specific index that I want to see if it's in use.. is there a way to monitor it over a period of time? assuming i don't have access to the application code.. just being the mongodb admin
[18:27:38] <kurushiyama> macwinne_ You'd usually use ".explain()" on your query.
[18:46:25] <macwinne_> right.. so i guess there is no counter on the indexes to see how many times they were used
[18:53:49] <kurushiyama> macwinne_ Not as far as I know, and I fail to see the use. You want to optimize at query level, anyway, don't you?
[18:54:47] <macwinne_> kurushiyama: many times you set indexes up over time.. but then later they are no longer used as you change your code
[18:55:18] <macwinne_> or as you redesign.. so you can build indexes that use precious ram but not exactly sure if they are still in use in your code
[18:55:38] <kurushiyama> macwinne_ I agree. But that is evidential from the code, and should be documented.
[18:56:28] <kurushiyama> macwinne_ Even better, it should be added to the DB change management system of choice.
[18:56:29] <macwinne_> yeah.. but when you are separated teams and dont have acecss to the code, it's good for the DBA to have visibility into this without needed developer support
[18:57:12] <kurushiyama> macwinne_ I disagree. Even strongly so. Different teams do not prohibit communication.
[18:58:30] <kurushiyama> macwinne_ If deleopment and DBAs do not communicate about changes, the problem does not seem to be a technical one to me.
[19:01:18] <macwinne_> ok.. you're entitled to you opinion.. imo having counters on index hits are a good thing.. it's like having cache counters
[19:01:34] <macwinne_> particularly when indexes use a litmited resource like ram
[19:02:57] <macwinne_> my philosphy is to have monitors on everything that impact server resource usage.. that way if a dev changes their query in their code, they don't need to tell me about it.. i will see over time that the index usage is no longer there
[19:04:18] <kurushiyama> macwinne_ Think it through. It would need write operations to make said statistics meaningful and durable, making an upsert for example twice as expensice in terms of write IO.
[19:04:40] <kurushiyama> s/expensice/expensive/
[19:05:52] <dddh__> rdbms like oracle/postgres usually have such counters
[19:11:38] <kurushiyama> dddh__ Well, Porsches have a turbocharger. Does that make each car to have a turbocharger?
[19:15:48] <macwinne_> kurushiyama: it just needs an inmemory incrementor.. does not need to be persisted
[19:16:22] <kurushiyama> macwinne_ I think you will be happily welcomed with a pull request.
[19:16:23] <macwinne_> should have neglible impact on queries if any compared to io times
[19:17:24] <kurushiyama> macwinne_ Since it would have to be a syncronised counter, I am not to convinced. You'd have to have a global mutex
[19:19:11] <kurushiyama> macwinne_ Even spanning a replica set, in case of a readPreference that allows reads from a secondary.
[19:24:39] <kurushiyama> macwinne_ However, I see a diffrent possibility to achieve what you want.
[19:32:17] <macwinne_> what's that?
[19:33:08] <kurushiyama> macwinne_ You could activate profiling from time to time and keep only necessary indices. After you deleted the supposedly unneeded ones, you'd monitor only slow queries.
[19:33:44] <macwinne_> thanks.. ill take a look at that
[22:11:53] <dddh__> cannot find luamongo package ;(
[22:13:38] <kurushiyama> There are several.
[22:14:17] <kurushiyama> dddh__ Mongorover seems to be promising in the long run
[22:15:25] <kurushiyama> dddh__ https://github.com/moai/luamongo
[22:16:33] <dddh__> kurushiyama: I know about moai/luamongo, do you reommend mongorover?
[22:16:51] <dddh__> last version was 221 days ago
[22:17:16] <kurushiyama> dddh__ Since it was started from an internship, I expect it to have _potential_, as written.
[22:17:43] <kurushiyama> dddh__ And according to github, the last commit was a couple of days ago
[22:20:39] <kurushiyama> dddh__ Basically, it is the community which decides, anyway. But since the last update on luamongo is way older, I suspect several changes as of 3.2 not included.
[22:26:58] <dddh__> mongorover was started from an internship?
[22:27:13] <dddh__> https://luarocks.org/modules/christopherjwang/mongorover
[22:27:21] <dddh__> ^^ 221 days ago
[22:33:28] <dddh__> seems like i need latest mongo-c-driver git ;(