Linux-UNIX: Multi-threading S-TAP to increase S-TAP throughput

S-TAP multi-threading can be used in certain workloads to prevent overrunning K-TAP buffers, and increasing the throughput of data in the S-TAP and its associated K-TAP. It works by preserving multiple threads from the point of traffic interception through to the point at which traffic is sent to the collector. You can combine multi-threading with pooled connections.

If the K-TAP is dropping a lot of traffic, or if there is evidence that intercepting the traffic is impacting the database performance, then you might consider enabling multiple K-TAP buffer support. An increased number of S-TAP threads and K-TAP buffers may mean that there is reduced lock contention in K-TAP, and the S-TAP has an improved ability to relay traffic to the collectors. But it also means that S-TAP might use more CPU and more memory, and more memory is pinned by K-TAP.

With multi-threading, the S-TAP creates extra threads, and the K-TAP creates additional buffers to store collected data. The K-TAP balances the traffic between the buffers, placing entire packets for a single session in one buffer. Each S-TAP thread reads from a different K-TAP buffer, and sends traffic data to a single Guardium® system. The higher the number of Guardiumconnections, the higher the throughput. This increases the CPU usage, but it should not be significant.

Pooled connections are clustered onto a main connection and are primarily intended for helping absorb the time cost of encryption by expending more CPU cycles. With pooled connections, a separate thread (the aux thread) pulls traffic from the main connection buffer queue and sends it to the collector to which the main connection thread is connected. Pooled connections are useful even when participate_in_load_balancing=0, whereas extra [SQLGuard_n] sections (or num_main_thread values > 1) at that setting are for failover only.

There are no definitive rules, you first modify the configuration, then fine-tune the results. Each database has a maximum of 50 connections to its collectors. The maximum per collector is 10, which can be 10 pooled connections, or 10 main threads, or a combination.

Multi-threading does not rectify a slow or busy network.

When one or more Guardium systems can not be reached, a failover machanism redirects the traffic from one Guardium system to another.

Multi-threading is also supported on AIX WPARs and Solaris zones.

Look at the K-TAP buffer statistics, if you see drops, you can increase the size of the buffer or you can increase the number of buffers. If throughput is your problem, you need to increase the number of buffers. If you are concerned about a measured DB impact, increase the number of buffers. If everything looks like it's usually fine but periodically you incur drops due to specific tasks, then just increase the buffer size.

Limitations

  • Encrypted and unencrypted A-TAP traffic cannot be sent to the same Guardium system, for all databases, since not all database encrypted K-TAP traffic and unencrypted A-TAP traffic can share the same session.
  • Policies have to be the same on all Guardium system because the policies dictate what happens to a system's traffic. If the policies are different, there's no guarantee which policy is in effect on a given session.
  • participate_in_load_balancing values 1 and 4 are similar but they use different mechanisms to split the the traffic, so the traffic from one session might get sent to multiple collectors. If you are using 1 and switch to 4, any sessions that are currently open might move to different Guardium systems, and you could lose the session information. Sessions closed before or opened after the transition are not affected.

Configuration Guidelines

The parameter num_main_thread in each [SQLGuard_n] section of the guard_tap.ini file determines the number of main connections to each collector. The maximum value of num_main_thread is 10 for all of the defined Guardium hosts (all of the [SQLGuard_n] sections of the guard_tap.ini file ). The actual number of K-TAP buffers is determined automatically, depending on the total of the num_main_thread for all collectors of the S-TAP. The maximum number of K-TAP buffers is five. They are automatically allocated across the read threads.:
  • 1-5: one S-TAP read thread for each K-TAP buffer, and one main connection to the collector.
  • 6-10: one or two S-TAP read threads for each K-TAP buffer, and one or two main connections to the collector.
The maximum value of num_main_thread is 10 for all of the defined Guardium hosts.

Adding collectors to implement multi-threading

In the guard_tap.ini file:
  • Set participate_in_load_balancing=4
  • Add an [SQLGuard_n] section for each added collector
  • Set num_main_thread in all [SQLGuard_n] sections, up to a total of 10 for all collectors

Adding read threads to an under-utilized collector to implement multi-threading

If you have a relatively strong and lighty loaded collector, set or increase the num_main_thread parameter in the corresponding [SQLGuard_n] section.

Example: One collector, five threads

[TAP]
...
participate_in_load_balancing=4
[SQLGuard_0]
num_main_thread=5
primary=1

Example: Two collectors, five threads

[TAP]
...
participate_in_load_balancing=4
[SQLGuard_0]
num_main_thread=3
primary=1
[SQLGuard_1]
num_main_thread=2
primary=2

Example: Two collectors, 10 threads

[TAP]
...
participate_in_load_balancing=4
[SQLGuard_0]
num_main_thread=5
primary=1
[SQLGuard_1]
num_main_thread=5
primary=2

Example: Five collectors, 10 threads, two main connections/collector, 5 pooled threads/main connection

[TAP]
...
participate_in_load_balancing=4
[SQLGuard_0]
connection_pool_size=10
num_main_thread=2
primary=1
[SQLGuard_1]
connection_pool_size=10
num_main_thread=2
primary=2
...

[SQLGuard_4]
connection_pool_size=10
num_main_thread=2
primary=5