Hi, Herman. 4GB RAM is bare minimum for Gluu to function in a test environment. For a production you should go with at least 6GB, better 8. If you know the PID of the process in question, you could try to find out which exactly Gluu's service it belongs to. Try to run this in the container: `# ps -aux | grep -i java`. Find out line corresponding to your PID, you should see some clues in there. Reasons for what you see may be many. For one, if you employ federation TR of a big federation, like Incommon, and supply its metadata by url, it may refresh it, from time to time, and this process is extremely memory-hungry.

All right. Well, we don't employ any federation, we just use Gluu server for authentication and managing users. Now, when I run setup.py, it says a number for the RAM that is goint to be always the same [3072]? Or it analyzes the machine and comes up with a number adjusted to it? If I installed it with 4096, more than the machine physical memory, I can expect this process killing behaviour? Another question: is it more expensive, memory-wise, to create and update an user or to authenticate it and return a token? What we have is a simple installation of Gluu 3.0.2, one client with scopes and grant types, and a java app using it. Without any use from the app, the server is growing its memory usage, so eventually, the OOM killer is goint to end the process. I believe that if we use a machine with more RAM, it will simply consume its memory until the end, which is alarming. UPDATE: it appears that it has stabilized memory usage after installing it with (seems obvious) only 3GB. Of course the console shows only 15% of free memory. Now, is it possible to initialize Gluu with just the necessary processes to authenticate and manage users, and no other service whatsoever, so it consumes less memory?

Hi, Herman. >Now, when I run setup.py, it says a number for the RAM that is goint to be always the same [3072]? Or it analyzes the machine and comes up with a number adjusted to it? No, default of 3GB is chosen so that a new users aiming to evaluate Gluu in some test environment wouldn't be met with excessively demanding requirements. We provide our recommendations for production setups [here](https://gluu.org/docs/ce/3.1.0/installation-guide/). It doesn't try to assume how much memory it may take for yourself, but it tries to divide the amount you specified between all its subcomponents, using some hardcoded ratios. Note, that you can adjust memory settings for each service after installation by editing corresponding file here (within container): `/etc/default/` (so, for oxAuth, edit `/etc/default/oxauth`) >If I installed it with 4096, more than the machine physical memory, I can expect this process killing behaviour? Yes, nothing good can come out of this. JVMs will be set with overall limits exceeding maximum size of RAM, that at best will lead to a lot of swapping, most likely to constant OOMs >Another question: is it more expensive, memory-wise, to create and update an user or to authenticate it and return a token? Can't say I understand the question completely, but in any case a user entry for each user Gluu handles is always created in its LDAP directory, regardless of what entity actually handles authentication - that's how it's designed. >I believe that if we use a machine with more RAM, it will simply consume its memory until the end, which is alarming. That shouldn't be the case. You always have an option to set upper limits for each JVM's heap using defaults files mentioned above, if they are not set already. >Now, is it possible to initialize Gluu with just the necessary processes to authenticate and manage users, and no other service whatsoever, so it consumes less memory? That's hard to answer a question like this, as it will heavily depend on your environment and loads. But, as mentioned, you have an option to tweak each JVM's memory allocations in whatever way it allows to do so. Profiling Gluu in such way is not covered by free community support, and is not different from a general task of profiling a JVM to accommodate a web app. If you may be interested in hiring a help from a 3rd party, we have some partners dealing with system integrations we could recommend.

``` Is it possible to initialize Gluu with just the necessary processes to authenticate and manage users, and no other service whatsoever, so it consumes less memory? ``` We already have stopped any non-essential container services. The most important thing is that you don't install any extra components in setup.py (e.g. don't install the Asimba SAML proxy, which will instantiate it's own jetty JVM). - Mike

Michael is correct. You also shouldn't install Shibboleth IdP as well, if you don't need to serve SAML requests (Shibboleth's additional memory consumption was what I meant when I was talking about huge federations' metadata before, I should have been more clear on that). Though please also note that adding components later on (after initial installation is completed) is not supported at the moment, so you may need to think through your requirements properly in advance. Generally, 4GB RAM should be enough for a test/small production setup, especially if you indeed don't need to use anything except OIDC/UMA/SCIM, which all are provided by oxAuth service. Just note that those 4GB must be allocated to Gluu exclusively, it's not the total memory of the host machine.

Everybody, thanks for your prompt answers. The memory consumption reached a steady level that has not been surpassed by now, but of course, I will take all those considerations to the letter. Thank you again.

I think this can be closed.