[SERVER-15561] I want to apply notablescan to per DB or per COLLECTION on production. Created: 08/Oct/14 Updated: 07/Apr/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Hiroaki | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 10 |
| Labels: | asya | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
| Comments |
| Comment by Asya Kamsky [ 19/Jul/18 ] |
|
Most related tickets talk about "typos" - generally that only happens in the shell during interactive sessions. I opened
|
| Comment by Glen Miner [ 11/Jun/15 ] |
|
As I mentioned in SERVER-1143 I think what would be best would be "notablescan by default" but you can opt out like rs.slaveOk() when you need to do something dangerous. This would prevent a large number of fat-finger fires. |
| Comment by Ramon Fernandez Marina [ 14/Oct/14 ] |
|
Understood, thanks crumbjp. We're keeping this ticket open to consider your request for a future version of MongoDB. |
| Comment by Hiroaki [ 10/Oct/14 ] |
|
I don't want to investigate the reason of the mongod killed. This issue is obviously not caused from any bugs. Not only MnogoDB, this is the theory of the all of the system that under the high-load. |
| Comment by Ramon Fernandez Marina [ 09/Oct/14 ] |
|
Hi crumbjp, without full logs my only guess is that mongod could be being killed by the OOM killer from the OS, but we'd like to make sure there are no other bugs lurking that may be causing this issue. If you could upload full logs from the mongod process from startup until one of your queries kills it that would help us investigate the issue. If it's easy for you to reproduce the scenario you describe, please increase the logLevel to 1 and upload the resulting logs from startup of the mongod process. Additionally, we'd like to consider your suggestion so we're either going to keep this ticket open, or merge it with SERVER-1143 which suggest a similar enhancement. Please let us know if you can upload the requested logs. Thanks, |
| Comment by Hiroaki [ 08/Oct/14 ] |
|
OS: Linux (Cent, Ubuntu) If I issue a fullscan query, the OP occupy large resource, and turn hot-data out and cause heavy thrashing. I know that this is the harsh environment case. The maxTimeMS is good feature. |
| Comment by Ramon Fernandez Marina [ 08/Oct/14 ] |
|
crumbjp, a tablescan should not kill mongod. If this happens to you it would be great if you could provide additional information to investigate if there's a bug somewhere. In particular:
In the meantime you may want to investigate the use of maxTimeMS and/or maxScan in your queries, that may help you work around this issue. Looking forward to hear more details so we can get to the bottom of this. Regards, |