Hacker News new | ask | show | jobs
by forkqueue 5756 days ago
Anyone got any ideas why the strangely specific size of 613MB RAM?
1 comments

Sure. They probably followed a similar reasoning (example with fictional numbers, but probably close to reality):

* They have 64GB RAM hosts.

* They want to dedicate only up to 85% of the RAM to the Xen instances (keep 15% for the host OS, buffercache, etc).

* The Operations/Management team decides to target an overall rate of $1.82/hr per host to achieve desirable profits.

* The AWS marketing department has a requirement that instances be priced $.xx/hr (no fractional cents) to evoke "simplicity".

* At a first pricing attempt, they see they have the choice of charging $.02/hr and assigning 65536 * .85 / (1.82 / .02) = 612MB per instance

* ...or charging $.03/hr and assigning 65536 * 0.85 / (1.82 / .03) = 918MB per instance

* They select the first option (612MB/instance) because it is deemed sufficiently smaller than the existing "small" 1.7GB instance offering, whereas 918MB was not small enough.

I believe they're using chunks of RAM on each physical server to hold S3 objects. This might help explain where the "buffer/cache" is going to.
That makes almost no sense. S3 is a purely network based file delivery service over HTTP, and pre-dates EC2 by a significant amount of time.

A Xen supervisor needs a fair amount of memory for its own operations, plus it can buffer the physical disks in the machine as well as any network attached storage. If these servers were also hosting S3 in their "spare time" it would degrade performance, and expose the system to potential vulnerabilities.