ProxySQL is a multi-threaded daemon, with one or more threads per module, as already pointed out in ProxySQL Threads.
The most critical threads are the the MySQL Threads.
Although the number of critical sections is limited, a few bugs in the past have caused unexpected locking issues and stalls.
For this reason, ProxySQL 1.4.4 introduces a watchdog that monitors MySQL Threads and MySQL Auxiliary Threads(if enabled).
If one or more worker threads start missing heartbeats for any reason at all, it means they are not serving traffic. The reason for this could be anything, including a bug.
If the watchdog detects that any of these threads are missing heartbeats for an extended period of time for any reason, it assumes they are blocked and it automatically asserts, resulting in a core dump and an automatic restart from the parent process in order to bring everything back to normal.
Watchdog is enabled by default.
Because each thread should never be blocked for longer than mysql-poll_timeout milliseconds (2000 by default), watchdog checks heartbeats every mysql-poll_timeout+1000 milliseconds (3 seconds by default, 2000ms + 1000ms): if restart_on_missing_heartbeats heartbeats are missing, watchdog triggers an assert.
restart_on_missing_heartbeats can only be configured in the global section of the configuration file, and its default value is 10.
If restart_on_missing_heartbeats is set to 0, watchdogs will still perform checks and generate entries in the error log, but it will not assert and it will not restart proxysql.
See Configuration file for details.
Note on ProxySQL and gdb
The watchdog module is extremely simple and lock free, therefore it should never block. Nonetheless, the watchdog module has its own heartbeat, therefore it is able to detect if ProxySQL was intentionally blocked, for example with a SIGSTOP signal or SIGINT signal in gdb: if this happens, it will not assert.