Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
25 results found
-
Autoscaling with custom conditions to scale up( change 1 hour to adjustable time) or down(change fixed 24 hours to adjustable time)
Currently autoscaling is predefined with conditions like
scale up:
The Average CPU Utilization has exceeded 75% for the past hour.
The Memory Utilization has exceeded 75% for the past hour.
scale down:
The average CPU Utilization and Memory Utilization over the past 24 hours is below 50%.
The cluster hasn't been scaled down (manually or automatically) in the past 24 hours.Following changes will save more resources and money:
-This 24 hours time for scale down should be made flexible/adjustable to suit customers requirement.
-One hour time to scale up should be adjustable to scale up faster. This may need…180 votes -
Autoscaling improvements
Hi, we have tried BETA of Autoscaling feature and we have some thoughts how to make it better. In its current setup its not really suitable for our production workloads. Here are some thoughts how to make it better:
- Define separate scaling steps At them moment the scaling step is always 1. Going from M10 -> M20 which is not really suitable for burst loads where going one step up might not be enough. Same goes for rapid scaling down
Example:
Scale range = M10 - M50
Scale step up 4 = (M10 -> M50)
Scale step down 2 =…158 votes -
Time based auto scaling
Our production server workload is less after 5 pm till the next day morning at 6 am CST times. We are running MongoDB in full capacity even on off-peak times. It's not possible for someone to manually downscale the cluster during off-peak and I don't think the CPU utilization based auto-scaling is working for us. I would like to choose auto-scaling between CPU based or time based as set my own time window and choose the auto scale/down-sclae.
74 votes -
Allow auto-scale for IOPS.
Allow auto-scale for IOPS.
49 votes -
Add "scheduled scaling/suspend" option for certain clusters
There should be an option to schedule scale up/down or suspending/resuming at specified time & day.
For example, DEV environments could be auto-suspended at 6pm and resume at 8am on weekdays, and be suspended all weekend.
Production clusters could be scaled down e.g. from M80->M60 every evening and on weekends rather than being suspended completely.
This would help save money but would need to be coordinated with the existing auto-scaling based on load.
This would need to be at the cluster level since sometimes different clusters in a single project could have different workload patterns.
36 votes -
Autoscaling - CPU/ Memory Utilization duration monitor - Minutes
Hi, Currently there is no option to initiate auto scaling during heavy workload/ requests comes and the cpu/ memory utilization is 75% for the even within
- 5 minutes
- 15 minutes
- 30 minutes
- 45 minutesThe system has to wait for 1 hour to autoscale to next tier.This one of the concerns for the heavy workload applications.
Idea:
Add a custom duration option as
- minutes also while monitoring the cpu / memory utilization
Example : When a CPU / Memory utilization is above 75% for the past 15 minutes , move the cluster to the next tier…
34 votes -
Customize CPU threshold for Autoscaling
Currently, to autoscale a cluster to the next tier, the "Average CPU Utilization must have exceeded 75% of available resources for the past hour."
Problem:
Some workloads remain near the 75% CPU threshold, given the nature of the workload. This can cause constant scaling events to occur which creates unnecessary noise.
We don't want to turn autoscale off because this is a beneficial feature to keep enabled on the cluster.
Solution:
We want to be able to configure the CPU % threshold for cluster tier scaling. For example, rather than 75%, we'd like the option to set the threshold to…
20 votes -
Scaling cluster connections independent of cluster size/tier
Currently whenever you want to increase Atlas cluster connections, you have to scale up Cluster Tiers. When an application doesn't require additional disk storage but only additional connections the additional cost is difficult to justify.
18 votes -
Allow autoscale for connections
Allow autoscale for connections
16 votes -
Add " Auto-scaling" events of the clusters to the Activity feed
Auto scaling is a great feature and as of now if any cluster gets scaled up/down an alert email will be sent to the email list provided in the Access Manager . However , in the activity feed we are unable to see them .
Use case:
For instance if an user want to know how many times the Auto-scaling happened and at what specified time that event occurred on a particular cluster there is no definitive answer as the only way is to check the email alerts that's been received.
It would be great if there is a way…
11 votes -
Allow more aggressive downscaling of clusters
Autoscaling clusters down a tier doesn't seem to work very well. Even under rather low memory usage, it doesn't seem like the procedure really ever triggers.
10 votes -
Exclude nodes from Autoscaling
We run huge analytics, reports and queries over our analytics node. And its expected that analytics node is sometimes over immense CPU or Memory pressure.
Current behaviour: When I enable Autoscaling, all the nodes in my cluster scales up when there is heavy load.
Expected behaviour: I would like my analytics node to slow down or the query to timeout rather than scaling the entire cluster.Therefore, I should have an option to exclude the metrics of analytics node while deciding for autoscaling.
8 votes -
Profiles for Autoscale heuristics
Case #00731969
Is it possible to tweak the scale up settings so that my clusters scale up faster than they do today?
I think it is best to analyze my clusters and figure out how long they are staying above 70% and then average it out, and if equal to or greater than that average, I would like my clusters to scale up.
Once scaled up, I want it to remain scaled up for the next ~2 hours at least and only scale down if usage gets really small enough for it to justify scale down.
Right now, the auto…
8 votes -
Storage autoscaling of storage should also occur when Atlas searches are being rebuild
When the storage requirement exceeds the available storage when rebuilding Atlas searches a warning is issued and manual intervention is needed.
I would like that autoscaling of storage will occur when needed for rebuilding Atlas indexes.
This would save us time and no need to react to warnings.7 votes -
See the history of autoscaling
Most of my clusters keep autoscaling (scale up and scale down) 3 to 4 times in a week. I would like to see the history of the cluster when the cluster scaled up or scaled down along with scaling reason (e.g. high CPU in Analytics node) and the time it took to complete the scaling transition.
7 votes -
dynamic auto-downscale (configurable)
MongoDB have automatic fixed limit for auto-downscale (50%) but sometimes is neccessary downscale with other amount, ie: in our case in the night the clusters have 55%, 60%... will be productive for us that the % limit for downscale will be parametrizable.
If I configure 60% I know that all the nights the cluster auto-downscale to previus instance.5 votes -
auto scaling on IOPS like the storage autoscaling
the IOPS can be auto scale up when it reach the maximum and stay at the maximum level for more than 1 hour
5 votes -
connect with slack
Whenever the database is about to scale, give an alert via slack to the team.It will be instant and currently, alerts are over email if you could provide it over slack the tech team responsible for particular will be notified.
3 votes -
Unevenly Scale Global Shards
Globally distributed shards should be able to scale unevenly. We have uneven loads across the world and sometimes spikes can hit a single region. Autoscaling for that single region scales everything and increases costs unnecessarily
3 votes -
Auto downscale - Scaling down during peak moments
The auto downscale checks for the average of usage for the last 4h. But, sometimes we have a cluster with little usage for almost all the 4 hours, but at the last 30, 15 minutes, it starts to consume more CPU (something higher than 60% or even higher).
As the autoscale only checks at the last 4h it sometimes happen that a cluster does a auto downscale when it shouldn't. A litler time after it needs to scale back up because the usage goes higher than 90% (or at least higher than 75%)
It would be much better if the…
2 votes
- Don't see your idea?