There is a performance issue with the MaxRows filter. When simple SELECT * FROM table (where there are millions of rows) is executed to see if the filter would trigger correctly and provide a different error in the log, 1 of 4 cpu cores on the server hit 100% and stayed there. 100% on a core for a single query seems like a lot. When the same query is executed without the MaxRows filter enabled, cpu usage is negligible.

Furthermore, while the core was at 100% like this, queries hitting the backend were taking several seconds to complete, stuck in a state of 'writing to net' and the user was labeled as 'unauthenticated user'. These same queries run in microseconds any other time.

As this happened on a server with 4 cores and threads=4 in the configuration file, it is expected to have all other queries routed mostly to the 3 idle cores. Either MaxScale was not routing them to the 3 idle cores, or there is a bottleneck somewhere else.

Relevant part of configuration file is:

[maxscale]

threads=4

...

[Galera Monitor]

type=monitor

module=galeramon

servers=N1, N2, N3

...

[Splitter Service]

type=service

router=readwritesplit

servers=N1, N2, N3

...

max_slave_connections=100%

connection_timeout=5400

disable_sescmd_history=true

max_sescmd_history=5

strict_multi_stmt=false

filters=Hint | MaxRows

[Hint]

type=filter

module=hintfilter

[MaxRows]

type=filter

module=maxrows

max_resultset_rows=300000

max_resultset_size=1T

max_resultset_return=error

...

This may be related/similar to https://jira.mariadb.org/browse/MXS-1212