processor_ids

Setting this parameter causes the EMS Server to start as many network I/O threads as there are processor IDs specified in the list. Each network I/O thread is bound to the given processor ID, which means that the thread can execute only on that processor. 

processor_ids = processor-id1,processor-id2,...
Note: Do not use this parameter if the default behavior provides sufficient throughput.

Specify the processor-id as an integer. Ask your system administrator for the valid processor IDs on the EMS Server host. Note that the IDs can be listed in any order. List IDs in a comma-separated list, with no spaces separating list items. For example: 

processor_ids = 0,1,3,6

On startup, the parameter is parsed and the server refuses to start (regardless of the presence of the startup_abort_list parameter) if:

  • The list is malformed. That is, if it contains invalid values such as non-numeric elements.
  • The server is unable to bind a network I/O thread to a given processor ID. This can happen when the processor ID has been disabled, or the tibemsd process has been restricted by the system administrator to a set of processors that does not contain this processor ID. Additionally, the server cannot correctly bind the network I/O thread to the process ID if spaces are included in the parameter definition.
Note: Do not use hyper threading.

For instance, consider a machine with 24 processors, with 2 dies and processor IDs ranging from 0 to 5 and 12 to 17 on the first die, and 6 to 11 and 18 to 23 on the second die. In this example, you should specify processor IDs in either the 0 to 5 range, or the 6 to 11 range.

Specifying processor IDs 0 and 12 in the list would cause thrashing because two network I/O threads would be bound to the same processor (or core). Also, for optimal performance, processor IDs should be from the same die.

This parameter can be used in conjunction with the stores.conf parameter processor_id. For more information, see Performance Tuning.