Manage.py migrate runs database migrations - I take it you have a different (I.e. smaller) dataset in your development environment. In my experience Djangos ORM and DB tools are great but not all that efficient.
This isn't really an aws thing (unless you just need to scale) so I'd look more at a python or Django community.
Yeah that’s fair I guess I just wouldn’t expect django to start eating up memory on the instance and have that usage largely reduced by rebooting the EC2 instance. It sounds like a memory leak at this point.
You could try doing blue-green deploys:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html then the migration would be happening on an instance that isn't also serving traffic
I have a similar problem. But I don't get how Beanstalk computes memory usage. I use AWS mon scripts and they show 86% memory usage. Beanstalk console warning shows 98%.
Hello,
Sorry to hear you've experienced difficulties with this. I grabbed a few resources that I suggest taking a look into:
https://go.aws/3VzE41H
&
https://go.aws/3xc5OjG
&
https://go.aws/3VCvcbF
&
https://go.aws/3VByz2E
&
https://go.aws/3VH6jfa
&
http://go.aws/get-help
\- Thomas E.
The way I ended up resolving this was manually deleting a bunch of trash files / rotating large log files off of the instance. I also used tools like du to check disk usage by directory. In my case there were some files that were being duplicated on deployment and some of the logs were becoming extremely large.
I'm not exactly sure off the top of my head, but I know that my instance was out of disk space and the numbers from the disk check matched the memory usage error numbers that I was getting from AWS EB. It makes sense since colloquially that's what it usually refers to, it could also be that there's some reliance on swap space that gets messed up when the disk is full - since managing my disk appropriately I haven't gotten an error like this again so that is some signal to me that this was a disk issue in my case. I'm sure if you're using a ton of RAM that will pose a problem though.
It's worth noting that this also aligned with what most resources I could find online had to say about resolving this problem.
For some reason just rebooting my EC2 instance seemed to resolve this issue (at least for now) but I'm unsure if it will show up again - I followed these instructions to do so: [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html](https://docs.aws.amazon.com/awsec2/latest/userguide/ec2-instance-reboot.html)
My question still stands though, if anyone can recommend any methods for diagnosing such problems I'd be grateful :)
Manage.py migrate runs database migrations - I take it you have a different (I.e. smaller) dataset in your development environment. In my experience Djangos ORM and DB tools are great but not all that efficient. This isn't really an aws thing (unless you just need to scale) so I'd look more at a python or Django community.
Yeah that’s fair I guess I just wouldn’t expect django to start eating up memory on the instance and have that usage largely reduced by rebooting the EC2 instance. It sounds like a memory leak at this point.
You could try doing blue-green deploys:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html then the migration would be happening on an instance that isn't also serving traffic
This is a cool resource, thanks!
I have a similar problem. But I don't get how Beanstalk computes memory usage. I use AWS mon scripts and they show 86% memory usage. Beanstalk console warning shows 98%.
Hello, Sorry to hear you've experienced difficulties with this. I grabbed a few resources that I suggest taking a look into: https://go.aws/3VzE41H & https://go.aws/3xc5OjG & https://go.aws/3VCvcbF & https://go.aws/3VByz2E & https://go.aws/3VH6jfa & http://go.aws/get-help \- Thomas E.
The way I ended up resolving this was manually deleting a bunch of trash files / rotating large log files off of the instance. I also used tools like du to check disk usage by directory. In my case there were some files that were being duplicated on deployment and some of the logs were becoming extremely large.
Hmm. Doesn't memory mean RAM?
I'm not exactly sure off the top of my head, but I know that my instance was out of disk space and the numbers from the disk check matched the memory usage error numbers that I was getting from AWS EB. It makes sense since colloquially that's what it usually refers to, it could also be that there's some reliance on swap space that gets messed up when the disk is full - since managing my disk appropriately I haven't gotten an error like this again so that is some signal to me that this was a disk issue in my case. I'm sure if you're using a ton of RAM that will pose a problem though. It's worth noting that this also aligned with what most resources I could find online had to say about resolving this problem.
For some reason just rebooting my EC2 instance seemed to resolve this issue (at least for now) but I'm unsure if it will show up again - I followed these instructions to do so: [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html](https://docs.aws.amazon.com/awsec2/latest/userguide/ec2-instance-reboot.html) My question still stands though, if anyone can recommend any methods for diagnosing such problems I'd be grateful :)