Memory strain

[BrianHGrant]

Due to the complexity of the incident model, the local hosted api is having difficulties accessing and serving the incidents data. I believe this might be do to the data allocation to postgresql itself as I experimented in boosting the vagrant box from 2gb RAM to 4gb RAM and did not notice a difference.

Symptoms: When attempting to access incidents endpoint through browser, will freeze and eventually runserver process will be killed. I am able to access the endpoint through postman however takes over a minute for data to load and will sometimes crash as well.

[znmeb]

Is this your own Vagrant box or the one I built? What's your host machine? You can hit me up in Slack or if you want we can meet somewhere - I used to do this performance stuff for a living.

[BrianHGrant]

Thank you,

I will message you on slack but here is the box we are working with:

https://github.com/russellgould/emergency-response/tree/vagrant_testbox. @russellgould and our database team can speak more to the specific build, but I believe is based on information provided in the Hack U. database course.

[znmeb]

Ah ... OK. I'm looking at it now. Two notes so far:

1. You're building on "trusty64". That's Ubuntu 14.04 - the data architecture class worked with Ubuntu 16.04 (Xenial Xerus) and unless it breaks something in your applications I'd recommend moving to "xenial64".

2. We built a Vagrant box with everything we believed was necessary for the applications - PostgreSQL, PostGIS, Django (including the API framework) and a complete Anaconda-based Python data science stack. It's up on a Google Drive - I can send you the link in Slack. See the repo https://github.com/hackoregon/getting-started for the details on using it.

I'm going to try to run your test case on my workstation (Fedora Linux, 8 cores, 32 GB) and see what I can find.

[sky-t]

The vagrant box we built as part of our database engineering class last Fall was based on trusty64, so we initially went with what we had experience with. We need to update the db repo anyway to update the box to incorporate the the new full dataset we got from PF&R. We can use Xenial in the next update (tonight).

[znmeb]

OK ... I'm looking at the provisioning now and it looks like you could build on top of our Vagrant box - you'd just need to add a script for the things we don't have yet to https://github.com/hackoregon/getting-started/tree/master/datascience/linux-laptop-setup and run the build process.

If you want to use our build, open an issue with the things you need added and I'll add them.

[russellgould]

First off thanks for looking at this stuff @znmeb! But yeah as Scott (@sky-t) mentioned I simply used what we had been using in the database course as a base. I didn't realize there was a more central vagrant box to be used. The data set we just received is about five times the size of what we had previously, so if there's a performance difference in the vagrant boxes it would be helpful to sort it out. I'm also a complete noob with this VM/vagrant stuff so having someone behind the box that knows what they're doing would be hugely beneficial as well haha.

We'll be discussing the new data in more depth tonight, so we can take a look at switching which box we use as well since we might need to change some things up.

[BrianHGrant]

@russellgould we wouldn't be this far without all your work, so thank you so much. I'm a noob as well so its a good learning experience for me as well.

[znmeb]

As I noted in a Slack direct message, a 6 GB allocation does work. However, the time for a response to the browser on first connect is on the order of minutes. It looks like the Python code is generating a page and is using 100 percent of a processor thread during that time.

Please let me know either here on this issue or on Slack if you have a revised Vagrant box you want me to test. I'll start making some scripts to capture log data unless the API coders have some idea what's happening.

[BrianHGrant]

So my pagination was not working correctly, when accessing the browsable api page @ http://localhost:4546/incidents in the browser it was attempting to generate a page listing all the incidents. This is the page that @znmeb mentioned was using the processor.

I've corrected pagination, currently set to 10 on this view and can now load the browsable page.

I'm closing this issue, as initial concern resolved. Thanks @znmeb, @russellgould, and @sky-t .

[znmeb]

Awesome! When will the repo be updated?

[BrianHGrant]

My development branch on fork is updated here: https://github.com/BrianHGrant/emergency-response/tree/incident_api

[znmeb]

OK ... I can do a git pull ;-)

[znmeb]

Works like a champ! It looks like you can run in 3 GB now: