>Now, when I run setup.py, it says a number for the RAM that is goint to be always the same ? 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.