There are a lot of variables (like the size of your Graph.obj, the number of requests, the OS you're using, your expectations on number of users and uptime, etc...); if OTP is just for you to do local testing, I would say that 4G of RAM is probably fine. But if you're looking to host OTP for others to use, then your probably on the bottom end of a workable OTP stack. (Note that I'm specifically speaking about the routing api -- no experience running the analytics app).
On my macbook air (which has 4GB of ram, to which I give tomcat / winstone 2GB of heap), OTP runs fine for just myself, and I don't see 4GB of physical memory as limiting at all. But in production on a server intended for multiple users, I have found that giving the OTP api 4GB (e.g., -Xmx4096m) of memory on it's own dedicated tomcat instance works best . I've see the production api instance reach 2.9GB after running for a month or so with a load of say 100 trip plans per day ... I've gotten that number to rise to ~3.7GB when I stress-tested the api under a constant load for over 24 hours (100 different trip plan urls). The memory usage of OTP appears to stabilize at these numbers, and I've got confidence that the memory usage is fairly predictable. (I'll know more next month when I send a lot more real users, ala ~2000 per day, to OTP). And note that I have another 8GB of memory on that server for other tasks, like the OS, the map webapp, etc... I've not seen the server dip into virtual memory with this configuration, load, etc...
On Wed, Jul 4, 2012 at 2:10 PM, Frank Purcell <fxpurc...@gmail.com> wrote:
> There are a lot of variables (like the size of your Graph.obj, the number
> of requests, the OS you're using, your expectations on number of users and
> uptime, etc...); if OTP is just for you to do local testing, I would say
> that 4G of RAM is probably fine. But if you're looking to host OTP for
> others to use, then your probably on the bottom end of a workable OTP
> stack. (Note that I'm specifically speaking about the routing api -- no
> experience running the analytics app).
> On my macbook air (which has 4GB of ram, to which I give tomcat / winstone
> 2GB of heap), OTP runs fine for just myself, and I don't see 4GB of
> physical memory as limiting at all. But in production on a server intended
> for multiple users, I have found that giving the OTP api 4GB (e.g.,
> -Xmx4096m) of memory on it's own dedicated tomcat instance works best .
> I've see the production api instance reach 2.9GB after running for a month
> or so with a load of say 100 trip plans per day ... I've gotten that number
> to rise to ~3.7GB when I stress-tested the api under a constant load for
> over 24 hours (100 different trip plan urls). The memory usage of OTP
> appears to stabilize at these numbers, and I've got confidence that the
> memory usage is fairly predictable. (I'll know more next month when I send
> a lot more real users, ala ~2000 per day, to OTP). And note that I have
> another 8GB of memory on that server for other tasks, like the OS, the map
> webapp, etc... I've not seen the server dip into virtual memory with this
> configuration, load, etc...
> On Jul 3, 2012, at 7:29 PM, Sarah Matthews wrote:
> > Hi
> > Just wondering is any RAM usage for the otp, please? My hosting
> currently has 4GB RAM and looks still not enough, is anyone had some issue,
> please?
It definitely depends on your graph.obj - I've run OTP for a small university on a machine with 512MB, and I did analysis on a Sacramento graph 3.2GB (1.7GB for OTP), but I've never used OTP in a production setting. Generally 2GB seems sufficient for graphs I've built.
Also, I was wondering if you are by chance the same Sarah Matthews that presented at the California Geographical Society this year?
> Thanks Frank, I may need find a way to increase our RAM.
> XXXX
> On Wed, Jul 4, 2012 at 2:10 PM, Frank Purcell <fxpurc...@gmail.com > <mailto:fxpurc...@gmail.com>> wrote:
> There are a lot of variables (like the size of your Graph.obj, the
> number of requests, the OS you're using, your expectations on
> number of users and uptime, etc...); if OTP is just for you to do
> local testing, I would say that 4G of RAM is probably fine. But
> if you're looking to host OTP for others to use, then your
> probably on the bottom end of a workable OTP stack. (Note that
> I'm specifically speaking about the routing api -- no experience
> running the analytics app).
> On my macbook air (which has 4GB of ram, to which I give tomcat /
> winstone 2GB of heap), OTP runs fine for just myself, and I don't
> see 4GB of physical memory as limiting at all. But in production
> on a server intended for multiple users, I have found that giving
> the OTP api 4GB (e.g., -Xmx4096m) of memory on it's own dedicated
> tomcat instance works best . I've see the production api instance
> reach 2.9GB after running for a month or so with a load of say 100
> trip plans per day ... I've gotten that number to rise to ~3.7GB
> when I stress-tested the api under a constant load for over 24
> hours (100 different trip plan urls). The memory usage of OTP
> appears to stabilize at these numbers, and I've got confidence
> that the memory usage is fairly predictable. (I'll know more next
> month when I send a lot more real users, ala ~2000 per day, to
> OTP). And note that I have another 8GB of memory on that server
> for other tasks, like the OS, the map webapp, etc... I've not
> seen the server dip into virtual memory with this configuration,
> load, etc...
> On Jul 3, 2012, at 7:29 PM, Sarah Matthews wrote:
> > Hi
> > Just wondering is any RAM usage for the otp, please? My hosting
> currently has 4GB RAM and looks still not enough, is anyone had
> some issue, please?
You can't really generalise with ram usage, some graphs in my OTP cluster will only use a couple hundred megs of ram while others will use over 12GB. It all depends on how large the region is (osm tiles) and how busy the locations transport network is.
Sydney and London are the largest consumers of ram I've come across but New York uses far less even though its larger. I guess it comes down to New York having a denser population (meaning less osm tiles) with more of a reliance on the subway so the variety of trips is significantly less given most trips are along the same section of track rather than various roads. Sydney and London make lots of use of other forms of transport such as buses with many different route variations.
