We are deploying a simple REST grails (2.3.7) app to heroku. The application is doing little less than "Hello World", yet we exceed the 1x dyno limit of 512MB (usually going between 600-700MB).
What is the expectation of memory usage of such an application?
Also, is there an official minimum requirements concerning memory?
Currently the minimum for a basic application is around or just above the 512mb amount depending on what the app does. We are aware of the problems this creates for Heroku and currently you need double dynos to run Grails applications on Heroku.
We are working to improve Grails support for micro services and a smaller memory footprint in Grails 3.0.
See this question stackoverflow :
memory usage of grails application
and what i can say is based on
If memory is not a problem on your server then allocate a large amount of memory, such as 512M or more. Also use the server VM option. EG: (-server -Xms512M -Xmx512M). Usually it is better to set both min and max heap size to the same in server applications.
However, if you running on a virtual host with limited memory, Grails 1.0 RC1 has been tested on tomcat 6 with both -Xmx96M and -Xmx128M, it performed well with both settings. I've heard reports of it running on lesser configurations"
And , REST application memory requirement can be high according to the request and how complex query and results involved, And also how you managed to do the coding that you properly cleared out every session , object after use ? But , i guess for REST application one > 512 <= 1GB of memory is good to start. And , use so tweaks for memory as well. it should be fine!
Related
Looks like the most powerful instance type you can have in Google App Engine is one with 2G memory. One of our Rails application reaches the memory limit quickly on higher load. Autoscaling helps but wondering if there is a way to add more power instances in GAE?
If not, how have you solved this problem?
yes, in App Engine Standard the higher tier is F4_HIGHMEM with 2048 MB of memory. You have 3 ways to scale up with standard:
Automatic: based on request rate, response latencies, and other application metrics.
Basic: creates dynamic instances when your application receives requests.
Manual: uses resident instances that continuously run the specified number of instances regardless of the load level.
Therefore, the question here would be how are you reaching this limit? How are you managing your memory? Take a look into your console metrics: memoryusage. A ladder graphs shown a bad usage of the memory. When deploying apps in the Cloud, you must have in mind that the usage of the resources bust be more accurate.
You can analyze and check if choosing an automatic scale based on Max concurrent Requests would be a good option for you to mitigate your issue with the memory.
This is for Standard, Flexible is managed different. You can specify from 0.9 to 6.5 GB per CPU core.
I use rails for small applications, but I'm not at all an expert. I'm hosting them on a Digital Ocean server with 512MB ram, which seems to be insufficient.
I was wondering what are Ruby on Rails server requirements (in terms of RAM) for a single app.
Besides I can I measure if my server is able to support the number of application on my server?
Many thanks
It depends on how much traffic you think you need to handle. We have two machines (a 32GB RAM, usage see below) with 32 unicorn workers two serve one app with loads of traffic and we have one machine with loads of 2 worker apps that have very few traffic.
We also have to consider the database (which needs the most RAM by far in our case due to big caches we granted it). And on top of that all we have *nix which caches the filesystem in unused RAM.
Conclusion: It is very hard to tell without you telling us what sort of traffic you expect.
Our memory usage on one of the two servers for the big app: https://gist.github.com/2called-chaos/bc2710744374f6e4a8e9b2d8c45b91cf
The output is from a little ruby script I made called unistat: https://gist.github.com/2called-chaos/50fc5412b34aea335fe9
I never found an official documentation about it and I generally install WildFly 8.x on servers with, at least, 4GB.
How much memory should my server have in order to run a WildFly instance?
Is there a minimum recommended?
The minimum value of Xmx is the one that let you start an empty instance of WildFly. On my try, it is 24 MB. There is no other valid value for a minimal Xmx. 4g is a totally arbitrary value. It's absolutely depending on your application, on the number of user,...
You have to run a stress test on your application and measure the memory. It is the only way to know the minimum for your application.
That depends on your application requirement.
In general I would recommend 4GB as a minimum. Note that you should have enough memory for the OS and it's caches.
Some small applications run perfect with <1GB for WildFly some need >32GB as they have lots of data.
So it's on you and you should test and measure it.
Along with the other answers I'd like to add a few points.
This would also depend upon :
Are you running the server in domain mode or standalone mode ?
Do you want all the components of the profile you are running the server with? If not you can create custom profile by removing unwanted components.
How many apps do you plan to deploy on the server ?
What is your performance/availability requirements ?
You need not always need 4GB ram, we run wildfly on our production servers with min memory set to 512MB and max as 1GB, till date no memory issues :)
I have a C# MVC App that also uses EF.
It's working well but on my local dev machine IIS Express uses in the order of 100Mb of memory, but when its in the production environment it uses 600mb of memory and seems to be challenging the specs of our VPS.
The 600mb is taken from PerfMons private bytes counter on the app pool process. RedGates performance monitor however seems to say the private bytes is more in the order of 150mb - I'm not sure what the difference between the two measures is.
What is a reasonable guide to private bytes usage that should I expect PerfMon to report for a production site?
I read somewhere that private bytes may be reporting memory that is available to the application not necessarily memory that is currently allocated by the application. I still find it alarming that it has reached 500-600mb - presumably the OS must think the applications memory demand may peak there?
Should I be alarmed and any advice on how to figure out what is going on?
UPDATE
If I run it on Win7 with IIS it only consumes around 100mb. Similar to result from IIS Express - so does this mean its something more to do with the IIS configuration on my production machine?
I am trying to find a definitive answer as to what the best setting is for the JVM Heap Size in Domino 8.5.3 FP4 - 64 Bit for Windows.
I know that by default it's set to 1024M. Some web sites have suggested that it's recommended to be 1G / 1024M - but that's the default setting so it that as good as it gets?
Other sites have said 25% of available RAM.
My Domino server has 12GB RAM available. It's currently got HTTPJVMMaxHeapSize = 1024M and Task Manager tells me that around 7GB of RAM is in use and nhttp.exe is using around 1.1GB. I want to increase this Heap to 2GB or 3GB if possible - will there be any issues doing to?
I'm running Windows Server 2008 R2 Standard Edition.
Speaking from an XPages perspective:
1 - Understand the dynamics of the working set and hardware
That is, understand what the application code, server runtime, and hardware profile is doing when processing a given working set (ie: the XPages application(s) within the server). Is the application coded in a non-optimal manner in terms of lifecycle execution and memory usage? Is the application making use of memory or disk persistence for component tree serialization? Is the server assigned an adequate amount of JVM memory? Is the hardware providing enough CPU and memory?
2 - Profile and monitor the working set with upper limit loads
To fully answer some of the questions in #1, detailed performance and scalability profiling must be carried out using tools like the XPages Toolbox and Eclipse Memory Analyzer. Furthermore, test the working set using Rational Performance Tester (or some other performance testing tool) to mimic real life concurrent workloads in a test environment. This allows you to set up a test environment where you can hit your application with (n) number of concurrent users using automation and collect that all invaluable data on health etc.
3 - Analyse the profile information to identify bottlenecks within the working set
Remember your working set can be one or more applications. Each doing something different, and having different load requirements. Be specific about the task at hand - do you want to tune the system more generally for all applications (for an average scale) or do you want the server to be fully optimized for a specific application (for a targeted scale)?
4 - Optimize the working set where applicable
Get in and make changes to the XSP / Java / ServerSide JavaScript code where applicable - use your knowledge of the XPages Request Processing Lifecycle and also look out for those hungry JVM memory consumers under high end load scenarios. Always favor disk persistence (disk storage is cheaper than RAM!) and code your custom Java objects and Managed Beans accordingly to cope with serialization and restoration. And make the trade-offs between function and speed in these scenario's where high scalability ends up burning CPU... a smarter UX with targetted functions / actions etc.
5 - Scale the hardware where applicable
Be prepared to increase cores, clock speeds, RAM, disk storage based on the needs of the working set - a cyclic approach to profiling, monitoring, and optimizing the working set will shed more and more light on the suitability of the hardware as this process evolves.
5 - Repeat from #2 until the working set and hardware performs and scales to the expected requirements / load expectancy of the system
I would recommend to set server's notes.ini param JavaVerboseGC=1 with console output into console.log in IBM_TECHNICAL_SUPPORT directory. After some time, take that log file and use IBM Support Assistant with tool IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV).
This could help how to interpret collected data: http://www-01.ibm.com/support/docview.wss?uid=swg27013824&aid=1.
You definitely should do that if you get OutOfMemoryException.
Heap size set too high can lead to fewer GC runs but taking longer time - server will periodically "hang" for very short time. So too high setting is not recommended.