> The discussion so far has discussed how to handle a failure to allocate more > memory from the system allocator (your native C library malloc, or some > replacement library). However my opinion is that if such a system allocation > fails, it's already too late for any meaningful reaction. You've exhausted all > available system memory. Depending on your system (operating system and > memory > configuration) you're likely having a completely unusable system now and > any kind of NFS transaction might already take a longer than acceptable time > (due to swapping). > > System administrators often configure swap space, sometimes with the old > formula (from the 1980's and 1990's) to configure twice the amount of swap > space as the system has RAM memory. With current servers having multiple > GB of RAM, this often ends up with vast amounts of (hard disk) swap space. > If a good portion of this swap is used, your system is unusable.
Agreed. > In another situation the Linux the OOM killer might have already killed > important other processes trying to free memory for the NFS server. You > wouldn't want to recover the NFS process here, since you don't know if that > system as a whole is in a useable space any more. You really want to reboot > the entire server. Yea, if we don't constrain the maximum process memory, then rebooting the entire server may be best. Ideally we don't want OOM killer to raise it's head (and probably on an enterprise server, instead of OOM Killer, we just want the system to reboot). > What a system administrator wants, is a NFS-Ganesha configuration option to > limit the amount of memory (RAM) that the process (including all threads) > can use at maximum. This is easy to do with ulimit -d, and I definitely agree we need to set such a hard limit. Jemalloc may also have a mechanism that might be worth using also. > The process itself should ensure to not allocate more > than this configured amount, possibly aborting if a requested memory > allocation would exceed the limit. This way the system administrator can > make a decision how the total amount of RAM should be used. He would be > responsible to make a balance between RAM available to the NFS process, > other processes and the operating system caches. > > If all allocations in NFS-Ganesha are made through gsh_* function we can > easily track the current amount of allocated RAM. If the system allocator > offers a function to return the amount of memory allocated currently we can > also use that one (but I think POSIX doesn't specify such a function). The gsh_alloc function certainly could track memory usage. I'm not sure that is worthwhile. For one thing, it would need to use an atomic variable to track memory utilization. > As far as playing nice with the system RAM, we could have a threshold below > such a configured maximum amount of RAM, something like 95% of that > amount. If the NFS-Ganesha process exceeds that threshold it can attempt > to free memory itself, for example purging caches. I wonder how well attempting to purge caches actually works. I did offer that as an idea in some other discussion on memory management, Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
