SELinux denials which contain { sys_resource } usually appear on machines which have not enough memory or which are heavily CPU utilized. Is this true in the customer environment?

Seen multiple times in our test tiers today:
----
type=PROCTITLE msg=audit(03/11/2020 19:45:37.619:24109) : proctitle=nginx: master process /usr/sbin/nginx 
type=SYSCALL msg=audit(03/11/2020 19:45:37.619:24109) : arch=aarch64 syscall=sendmsg success=no exit=ETOOMANYREFS(Too many references: cannot splice) a0=0x3b a1=0xffffd078ca18 a2=0x0 a3=0xffff9e514000 items=0 ppid=1 pid=151751 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=nginx exe=/usr/sbin/nginx subj=system_u:system_r:httpd_t:s0 key=(null) 
type=AVC msg=audit(03/11/2020 19:45:37.619:24109) : avc:  denied  { sys_admin } for  pid=151751 comm=nginx capability=sys_admin  scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability permissive=0 
type=AVC msg=audit(03/11/2020 19:45:37.619:24109) : avc:  denied  { sys_resource } for  pid=151751 comm=nginx capability=sys_resource  scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability permissive=0 
----

aarch64 machines seem to be slow in comparison to other architectures.

       ETOOMANYREFS
              This error can occur for sendmsg(2) when sending a file
              descriptor as ancillary data over a UNIX domain socket (see
              the description of SCM_RIGHTS, above).  It occurs if the
              number of "in-flight" file descriptors exceeds the
              RLIMIT_NOFILE resource limit and the caller does not have the
              CAP_SYS_RESOURCE capability.  An in-flight file descriptor is
              one that has been sent using sendmsg(2) but has not yet been
              accepted in the recipient process using recvmsg(2).

              This error is diagnosed since mainline Linux 4.5 (and in some
              earlier kernel versions where the fix has been backported).
              In earlier kernel versions, it was possible to place an
              unlimited number of file descriptors in flight, by sending
              each file descriptor with sendmsg(2) and then closing the file
              descriptor so that it was not accounted against the
              RLIMIT_NOFILE resource limit.

Does setting a higher limit of open files in customer environment help?

Thanks Milos,

Will check customer's environment but I doubt it's similar for reasons below:
- it affects pipe() and pipe() doesn't fail here
- it's 100% reproducible with man-db-cache-update.service
- there is no load at all on the system

https://patchwork.kernel.org/patch/11433589/

Please ignore previous comment. Entered by mistake.

Closing this BZ as NOTABUG: system is actually running out of resources as indicated.

See the attached knowledgebase article for more information.