Red Hat Linux Interview Series 15

[Chetan_Tiwary_]

 Q.) We are transmitting a large amount of data over a WAN link and wish to tune the transfer to be as fast as possible, basically looking for sysctl parameters which can be tuned to allow better performance over our network. How will you tune it ?

Q.) How will you spread the memory of the "example" process equally across NUMA nodes ?

Q.) How will you prevent your process from being killed by the OOM killer ?

Bonus Q. - What could be the consequences of the OOM immunity of a particular process/es ? Should there be immunity from OOM killer ?

I'll be posting a series of Linux-related questions covering various skill levels. Feel free to share your insights and expertise. Your contributions will benefit learners at all stages, from those in current roles to those preparing for Linux interviews.

Level - L3 and above

[Trevor]

Let me attempt to address that first question that deals with the transfer of a large
amount of data over a WAN link.

To tune a Linux kernel for large data transfers across a WAN, the primary focus
should be on adjusting TCP buffer sizes by modifying kernel parameters like
net.core.rmem_max and net.core.wmem_max  -  this essentially increases the
amount of data that can be buffered before sending an acknowledgment, thus
allowing for larger data chunks to be transferred efficiently over a potentially
high-latency network like a WAN.

net.core.rmem_max: Controls the maximum receive buffer size. 

net.core.wmem_max: Controls the maximum send buffer size.

Two things to consider when setting a value for these two kernel parameters are:
* Network conditions:

       - The optimal buffer size depends on your network latency, bandwidth, 
            and the size of the data transfers. 

* System resources:

       - Be mindful of memory usage when increasing buffer sizes, as large buffers
             can consume significant RAM

To configure these kernel parameters, from the command line, using the sysctl
command, the syntax is:

#   sysctl  -w  net.core.rmem_max = value_of_buffer_size_in_bytes

#   sysctl  -w  net.core.wmem_max = value_of_buffer_size_in_bytes

[Trevor]

That 3rd question is calling my name, and so I'm compelled to respond:
"How will you prevent your process from being killed by the OOM killer ?"

To prevent my process from being killed by the OOM killer, I'd perform the following:

1) Retrieve the PID of the process
2) Execute the following command:   # echo -17 > /proc/PID/oom_adj

That's it!  This will keep the process alive, even in an OOM state.

Notes:
*     The value -17 is associated with a constant named OOM_DISABLE
*     In Linux, the constant OOM_DISABLE is used to immunize a process from the
           Out of Memory (OOM) killer.

[Trevor]

I might as well take a swing at the Bonus Q:  Consequence(s) of process immunity?

My research turns up three:

1) linux system performance degradation
2) the problem process crashes
3) the kernel panics

[Chetan_Tiwary_]

@Trevor You are hired !!

[Ridwan_G4]

I just post a comment to stay update with this post.

Anyway.. nice answer @Trevor 

[Emanuel_Haine]

Question 1

I would like to add more approaches on this, besides what you have brought here.

We can add this TCP congestion control algorithm (RHEL 8 and above)

net.ipv4.tcp_congestion_control=bbr

If possible, we can adjust the MTU of allow jumbo frames, which can signifcantly increase the transmission ratio. However, the jumbo approach can be challenging since this doesn't work well if just one device in the network is not configured to allow it.