Why should we use t2.small rather than t2.micro?


#1

I’ve built redash by AMI and t2.micro instance. It’s working for now, but every query took a few seconds to response results, and running manage.py causes Redis MISCONF error.
The document says we should use t2.small or larger instance. Maybe I should replace the instance, but I don’t fully understand why t2.micro is not recommended and if my symptoms are related to instance type. What does redash use much amount of CPU and memory for?


#2

Hey Udomomo,

not a direct answer to your question rather than a recommendation. You can run a t2.micro pretty well considering two system config modifications:

  • change the default vm.swappiness sysctl parameter to e.g. 10 to let the system use the existing 1GB RAM more aggressively and defer swapping (which leads to the next point as the AMI does not have a swapfile or partition)
  • create a swapfile and persist it in /etc/fstab

I actually ran into various errors due to lack of memory rather quickly; that’s avoidable with the above tips, however swapping might slow down performance, of course. My instance is functioning well by now.

Both options are not recommendable for production use. postgres loves lots of shared buffers/file cache for good performance, depending on the data volume of your databases/clusters - if you have a few gigs of data or so. Having to resort to swapping on production machines is never good practice.

Regards,
FvM


#3

Thanks. I’ve upgraded to ts.small, and now manage.py command gives me a response only in a few seconds.