With SMX4ER, so ER using SMX (instead of pure ASF) since
v14.10.xC6 (unless turned off or replicating with an older
version server), the ER NIF business (esp. its target component)
got split into actual network transmission (performed by
SMX/through SMX routines) and other ER NIF business, esp. in the
NIF receiver.
Expected benefits:
- the NIF sender can keep sending, won't have to wait on NIF
receiver to be ready to receive,
instead SMX will receive and buffer potentially large amounts
of data in memory, for later consumption by the NIF receiver
- network transmission and other NIF business, running in
separate threads, can run in parallel, better utilizing cpus/CPU
VPs and enhancing throughput
- in high latency networks SMX could counter latency by
utilizing multiple network connections in parallel
(SMX_NUMPIPES), so by parallelizing even more
All these benefits hinge on the ability of multiple threads to
actually run in parallel which, in Informix, requires as many
CPU VPs as there are threads having parallelizable work to do.
With only a single CPU VP instead, using SMX would become an
extra burden, with extra thread work and extra data copying, for
hardly any benefit.
A further problem apparently can arise from SMX send and receive
threads constantly running with max. priority (3) while e.g. ER
NIF threads are running with default priority (1), so it seems
possible that SMX receive threads would starve ER NIF receive
threads, a large amount of replication data gets received into
SMX buffers (smx0-smx19 pools memory growing large), and their
ER NIF receiver thread consumers wouldn't get a chance to fetch
and process the data.
With multiple ER servers configured this way, and some sizable
amount of transactions sent around, problems could easily
multiply as well, up to systems running out of memory. |
