Project

General

Profile

Actions

Bug #6256

closed

osmo-bsc running out of file descriptors in production setups

Added by laforge 6 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
11/11/2023
Due date:
% Done:

100%

Spec Reference:

Description

We have a production setup where there are >= 200 BTs with each up to 4 TRX. In that setup, the OS default number of open file descriptors (1024) is hit, resulting in call drops.

Given that there is N+1 sockets for each N-TRX BTS (e.g. 5 for a 4TRX) plus a handful for the AoIP interface, for speaking MGCP to the MGW, CTRL/VTY, etc. it is thus completely reasonable to exceed 1024.

Now the 1024 is not a limit imposed by osmo-bsc. However, we might want to either
  • add a note to the user manual informing users that they should tune their system accordingly if they expect a high number of BTSs, and/or
  • consider tuning the limit for osmo-bsc using LimitNOFILE in the systemd unit we're shipping.
We might also want to look at other osmo-* programs that might encounter similar problems. AFAICT it's probably only
  • osmo-hnbgw (only one Iuh socket for each HNB, though)
  • osmo-mgw (2 sockets per endpoint (RTP+RTCP), resulting in 4 sockets for each call, but single-threaded mgw might not handle 256 calls anyway?
  • osmo-gbproxy (number of sockets depends on number of NS-VCs configured. But at least common setups probably only have few UDP sockets. Unlike TCP/SCTP, we don't need new sockets for each peer/connection). So probably not required
  • bts, trx, msc, hlr, sgsn, ggsn all have only a low number of sockets, from what I can tell.
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)