Actions
Bug #928
closedBug #914: Having a high number of pickup queues (216+) makes suricata crash
Max number of threads
Affected Versions:
Effort:
Difficulty:
Label:
Description
This is Suricata version 2.0beta1 RELEASE and latest git
On a two core system:
detect-thread-ratio: 107
After start - 215 threads and 3 management threads are started and Suricata starts successfully.
If we increase the number by one more:
detect-thread-ratio: 108
We get an err:
Error: Queue "picku" doesn't have a reader
This is independently confirmed on another 4 core system:
detect-thread-ratio: 53
Suricata spawns 213 processing threads and 3 management.
If increased by one:
detect-thread-ratio: 54
we get the same err:
Error: Queue "picku" doesn't have a reader
It seems there is a hard coded limit of the number of threads spawning? (around 218).
If so the limit should be increased because there are systems with more than 256 cores available on the market.
Updated by Victor Julien about 11 years ago
- Assignee set to OISF Dev
- Target version set to 2.0beta2
Updated by Victor Julien about 11 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
Updated by Victor Julien about 11 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
- Parent task set to #914
Same issue as #914.
There is still a limit, to the built-in 256 queues. This means that as this point autofp runmodes will not scale beyond that.
Actions