I am using a free M0 cluster on
cloud.mongodb.com with a meteor-app and got recently notified about a performance-issue concerning a regex-query on oplog taking a minute or longer. As a result the database got throttled and is not reachable anymore until the issue is resolved.
The thing is, the app (using meteor 1.5.1) does not use any regex-queries nor does it use the
facts package explicitly.
I got informed that: “Changes streams and triggers both reference oplog in the backend which can be a contributing factor.”
So I was wondering if meteor uses either
Change streams or
triggers internally and if this could lead to such long queries?
Did anybody experience this or similar issues?
How could I solve this?
Any pointers would be helpful as the app is offline until mongodb enables the database again.
to my knowledge, regex query isn’t fully supported by indexes, which means in many cases it will need to scan all your database records, it will take time.
I prefer using
$text search over regex if possible.
Meteor’s Oplog tailing does that. While regex queries are not supported by indexes in general, left-anchored ones are, and that’s exactly what Meteor does.
However, it should not be problem for your app at all. If it is, I bet your database is shared with other, write-heavy services. If so, look up “oplog flood” on this forum.
Long story short, the only option would be to either stop using oplog or by using
cultofcoders:redis-oplog (I’m not sure what Meteor versions are supported, though). And if you do the latter, I highly recommend using
changestreamtoredis to ease the process.
Thanks for your answer!
The app does write to the database once in a while, but my I’m not sure it would flood oplog.
But anyways great hint, I will try with setting
METEOR_OPLOG_TOO_FAR_BEHIND to a lower value.
MongoDB did not accept setting
METEOR_OPLOG_TOO_FAR_BEHIND to a lower level on the shared database (as it would still use regex-queries). So I turned oplog-tailing off by not providing a