# PBS cgroups and Numa Nodes issue

**URL:** <https://community.openpbs.org/t/pbs-cgroups-and-numa-nodes-issue/3101>\
**Category:** Users/Site Administrators\
**Created:** [May 24, 2022, 1:05pm UTC](https://community.openpbs.org/t/pbs-cgroups-and-numa-nodes-issue/3101 "2022-05-24T13:05:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rchaudhary](https://avatars.discourse-cdn.com/v4/letter/r/edb3f5/32.png) [@rchaudhary](https://community.openpbs.org/u/rchaudhary)\
**Post date:** [May 24, 2022, 1:05pm UTC](https://community.openpbs.org/t/pbs-cgroups-and-numa-nodes-issue/3101/1 "2022-05-24T13:05:37Z")

</div>

Hi

I would like to request advice on below issue please:

The scenario we have is a job submitted with an allocated amount of memory (e.g. 50gb)  
What then happens is the job is submitted to a cpuset (numa node) that has less than 50gb available for that cpuset. The overall available memory on the server is more the 50gb for info.

The job is then killed by OOM killer with the constraint `CONSTRAINT_CPUSET` .

My question is does PBS check if the cpuset that a job is assigned to has enough available memory? If not what can we do to correct the logic?

We are using pbs\_version = 19.1.3

Note -  
FYI,

- I checked our configuration & compare it with below doc and it is same  
[PP-325: Support Cgroups - Project Documentation - Confluence (atlassian.net)](https://openpbs.atlassian.net/wiki/spaces/PD/pages/11599882/PP-325+Support+Cgroups)
- Jobs killing reason - CONSTRAINT\_CPUSET

¬Regards,  
Ritika.

---

<div class="post-metadata">

**Author:** ![alexis.cousein](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/alexis.cousein/32/265_2.png) [@alexis.cousein](https://community.openpbs.org/u/alexis.cousein)\
**Post date:** [May 31, 2022, 6:34am UTC](https://community.openpbs.org/t/pbs-cgroups-and-numa-nodes-issue/3101/2 "2022-05-31T06:34:03Z")

</div>

Dosable mem\_fences in the cgroup hook Config file. Even with vnode\_per\_numa\_node turned on unless you control your workload to avoid sharing vnodes for jobs straddling vnodes when the scheduler allocates e.g. 20gb on one socket and 30gb on another there’s no mechanism for the kernel to honour it, which might make jobs fences into a single node fail if the actual usage is different.