Constraints

Before the system enters the hibernation mode, ensure that the running processes such as the AI inference and media data processing exit first. After the system is wakened up successfully, continue to process the services.
Do not use the fork function to create multiple pyacl API caller processes, as this may lead to errors or cause processes to stop responding at runtime.
Do not use fork or fork-encapsulated functions (such as system and posix_spawnp) for asynchronous memory manipulations (by using calls to APIs such as acl.rt.memcpy_async and acl.rt.memset_async). Doing so will result in unexpected errors at runtime and may possibly cause the process to stop responding.
For allocation APIs (such as acl.rt.create_stream, acl.rt.create_event, and acl.create_data_buffer), the corresponding destruction APIs (such as acl.rt.destroy_stream, acl.rt.destroy_event, and Function: destroy_data_buffer) must be called to destroy the allocations in a timely manner. Otherwise, the app may not function properly.
For destruction APIs (such as acl.rt.destroy_stream, acl.rt.destroy_event, acl.rt.free, and acl.destroy_data_buffer), the released or destroyed resources are no longer available after these APIs are called. You are advised to set the released or destroyed resources to invalid values (for example, None) after calling these APIs.
Atlas Training Series Product: For physical machines, a device supports a maximum of 64 user processes, and a host supports a maximum of 64 processes multiplied by the number of devices. For virtual machines, a device supports a maximum of 32 user processes, and a host supports a maximum of 32 processes multiplied by the number of devices.
Atlas inference products: For physical machines, a device supports a maximum of 64 user processes, and a host supports a maximum of 64 processes multiplied by the number of devices. For virtual machines, a device supports a maximum of 32 user processes, and a host supports a maximum of 32 processes multiplied by the number of devices.
Atlas 200I/500 A2 inference products : A device supports a maximum of 64 user processes, and a host supports a maximum of 64 processes multiplied by the number of devices.
Atlas A2 training products / Atlas A2 inference products : A device supports a maximum of 63 user processes, and a host supports a maximum of 63 processes multiplied by the number of devices.
Atlas A3 training products / Atlas A3 inference products : A device supports a maximum of 63 user processes, and a host supports a maximum of 63 processes multiplied by the number of devices.
Ascend 950PR / Ascend 950DT : A device supports a maximum of 64 user processes, and a host supports a maximum of 64 processes multiplied by the number of devices.
After memory is allocated using a memory allocation API (such as acl.rt.malloc and acl.media.dvpp_malloc), you are advised to call the acl.rt.memset or acl.rt.memset_async API to clear the memory (for example, acl.rt.memset(dev_buffer_ptr, dev_buffer_size, 0, dev_buffer_size)) before using the memory to ensure that no dirty data exists in the memory.
In Ascend RC form, if the memory allocation APIs such as acl.rt.malloc, acl.media.dvpp_malloc and hi_mpi_dvpp_malloc are called in the app logic, and the app runs on the device, the app will be suspended in the event of insufficient memory until such time that memory becomes available. You can activate certain OS configurations (for example, enable_oom_killer) to force the app to automatically exit when memory becomes insufficient.
To activate enable_oom_killer, log in to the device, go to the /proc/sys/vm directory, and set enable_oom_killer as the root user. The following is a command example, where, 1 indicates activated, and 0 indicates deactivated.
```
echo 1 > enable_oom_killer
```

Parent topic: Appendixes