Debugging a Running Server (on Linux)
Even if you don't have a server that is compiled for debugging, there is still ways to get more information out from it if things goes wrong.
It's always better to have a version of mysqld demon that is not stripped.
shell> file /usr/sbin/mysqld
If this doesn't say 'stripped' them you are fine. If not, you should either download a binary with debugging information or compile it, without stripping the binary.
Debugging memory consumption with tcmalloc.
If you have a problem with that the mysqld process keeps on growing, you can use tcmalloc to find out what is allocating memory:
Depending on the system you have to install the tcmalloc
(OpenSuse) or the google-perftools-lib
(RedHat, Centos) package.
The following set of command starts mysqld with memory profiling and if you kill it with SIGABRT, you will get a core dump that you can examine:
ulimit -c unlimted LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 HEAPPROFILE=/tmp/mysqld.prof /usr/sbin/mysqld --core-file
You can of course add other mysqld options to the end of the above line.
Now start your client/applications that uses MariaDB. You can find where memory is allocated in the /tmp/mysqld.prof
file. If you find any memory issues, please report this in the MariaDB bug tracker!
Debugging a server that hangs
If your mysqld server hangs, you may want to debug it to know what happened.
Preferably the server should be compiled for debugging, but it's not strictly necessary:
cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_VALGRIND=ON . make -j4
To know what the server is doing:
- Find out the process number of mysqld
ps -edalf | grep mysqld
- Attach to the process and get a back trace:
gdb -p 'pid of mysqld' path-to-mysqld set height 0 set logging file /tmp/mysqld.log set logging on thread apply all backtrace full
After the above you have a full backtrace, including all local variables, in the mysqld.log file. Note that you will only get all variables if the server is not stripped.