0

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....

Prophet
  • 32,350
  • 22
  • 54
  • 79
evenro
  • 2,626
  • 20
  • 35

1 Answers1

1

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

Ulrich Thomas Gabor
  • 6,584
  • 4
  • 27
  • 41
  • Why is the binlog being used if I did not configure replication? is it an in-memory log that I can ignore? – evenro Apr 03 '14 at 14:51
  • You can activate the binary log without setting up an actual replication. Maybe you did this? ([These binlog options exist, maybe you set them?](https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html)) – Ulrich Thomas Gabor Apr 03 '14 at 15:01
  • I am using intentionally the default MySQL settings, so I didn't change any configuration but the socket... and I don't have any of these configuration in the my.cnf. and I also not seem to find a binlog file, so I guess it's an in-memory, or a dummy call... – evenro Apr 03 '14 at 15:12
  • I don't know. Why don't you just take a look at [the source code](https://launchpad.net/mysql-server), if you are that interested in the very internals of MySQL? – Ulrich Thomas Gabor Apr 03 '14 at 17:49