CODEWITHSUNDEEP
mysqlvalgrindcall-graphkcachegrindcachegrind
evenro
evenro

Reputation: 2646

call graph for MySQL sessions

I am trying to create a valgrind (cachegrind) analysis of MySQL client connections.
I am running valgrind with --trace-children=yes.

What I want to find is one of the internal method calls, to see the call graph when it is being used...

After running valgrind --trace-children=yes ./bin/mysqld_safe
I get many dump files that were written that moment.
I am waiting 5 minutes (for letting the new files that I expect to be created to have a different "last modified" date.

After these 5 minutes I open 30 sessions, and floud the system with small transactions, and when I am done - shutdown the MySQL.

Now the questions:
1. After running 30 transactions and shutting down the system, only 3 files are modified. I expected to see 30 files, cause I though MySQL spans processes. So first - can someone confirm MySQL spans threads and not processes for each session?

  1. I see three different database log calls: one to a DUMMY, one to binlog, and one to the innodb log. Can someone explain why the binlog and the DUMMY are there, and what's the difference between them? (I guess the DUMMY is because of the innodb, but I don't understand why the binlog is there if my first guess is true).

  2. Is there a better way to do this analysis?
    Is there a tool like kcachegrind that can open multiple files and show the summery from all of them? (or is it possible somehow within kcachegrind?)

Thanks!!

btw - for people who extend and develop MySQL - there are many interesting things there that can be improved....

Upvotes: 0

Views: 181

Answers (1)

Ulrich Thomas Gabor
Ulrich Thomas Gabor

Reputation: 6654

I can only help you on some issues: Yes, MySQL does not create processes, but threads, see the manual on the command which lists what is currently done by the server:

When you are attempting to ascertain what your MySQL server is doing, it can be helpful to examine the process list, which is the set of threads currently executing within the server.

(Highlighting by me.)

Concerning the logs: Binary log is the log used for replication. This contains all executed statements (or changed rows) and will be propagated to slaves.

The InnoDB log is independent from the binary log and is used to assure that InnoDB performs ACID conform. Transactions are inserted there first and this file is used if the server crashed and InnoDB starts a recovery.

It is kind of normal that both logs are filled on a normal server.

I cannot help you with your other questions though. Maybe you want to ask your question on dba.stackexchange.com

Upvotes: 1

Related Questions