RSA Security Analytics 10G DAC performance throughput information

[#1]

Article Number

000032278

Applies To

RSA Product Set: Security Analytics
RSA Product/Service Type: Decoder
RSA Version/Condition: 10.5.x
Platform: CentOS
O/S Version: EL6

Resolution

• To achieve 10G line rate, the storage system to which write operations for packet and meta use must maintain write throughput of 1400 MBytes/s. The more DACs on the system, the better the read performance (and retention), as writes can then balance across each DAC.
• The minimum DAC config that is capable of achieving 1400 mBytes/s performance at 10G is of 2 DAC units across two connectors (such as connecting 1 DAC to one port on SAS card, then connecting the second DAC to the other port on the SAS card).
• Additional factors: In addition, parsing raw packets at high speeds presents unique challenges.Given the high session and packet rates, parsing efficiency is also paramount, as it too directly affects throughput.  A single parser that is inefficient (spends too long examining packets) can further bog down throughput rates to the point where packets may dropped while buffering waits on i/o.

Notes

Testing rules of thumb:

1. Begin testing with only native parsers, and exclude SMB/WebMail.   
2. Do not download any Live content until testing baselines are established and optimim performance throughput is seen.
3. Live content should be added in very slowly - especially parsers. Parsers can have a dramatic effect on performance.  
4. When the DACs do not have enough throughput to sustain the capture speed, this log message will be seen on the 10G Decoder in /var/log/messages:
      

[Warning] Write thread blocked waiting for previous file flush to finish: packet-XXXXXXX.nwpdb

     
5. Add only one or two parsers in at a time
6. Measure the performance impact of those new parsers during peak capture times, keep deltas.
7. If drops start occurring when they didn't happen before, disable any recently added parsers/rules/feeds to the last stable delta.
8. Avoid inefficient parsers as a rule.
9. Feeds by rule cause fewer performance impacts. However best practice dictates to minimize the number of feeds (especially large feeds) added at any given time to measure performance impacts
10. Rules also tend to have lower observable performance impact, though again, it is ill advised to add a large number of rules at once without measuring the performance impact