简体   繁体   English

MySQL会话的调用图

[英]call graph for MySQL sessions

I am trying to create a valgrind (cachegrind) analysis of MySQL client connections. 我正在尝试创建MySQL客户端连接的valgrind (cachegrind)分析。
I am running valgrind with --trace-children=yes . 我正在使用--trace-children=yes运行valgrind

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 运行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. 我正在等待5分钟(用于让我希望创建的新文件具有不同的“上次修改”日期)。

After these 5 minutes I open 30 sessions, and floud the system with small transactions, and when I am done - shutdown the MySQL. 在这5分钟之后,我打开了30个会话,并通过少量事务处理了系统,完成后-关闭MySQL。

Now the questions: 现在的问题:
1. After running 30 transactions and shutting down the system, only 3 files are modified. 1.运行30个事务并关闭系统后,仅修改了3个文件。 I expected to see 30 files, cause I though MySQL spans processes. 我希望看到30个文件,这是因为尽管MySQL跨进程。 So first - can someone confirm MySQL spans threads and not processes for each session? 那么首先-有人可以确认MySQL跨越线程而不是每个会话的进程吗?

  1. I see three different database log calls: one to a DUMMY, one to binlog , and one to the innodb log. 我看到了三种不同的数据库日志调用:一种是DUMMY,一种是binlog ,一种是innodb日志。 Can someone explain why the binlog and the DUMMY are there, and what's the difference between them? 谁能解释为什么binlog和DUMMY在那里,它们之间有什么区别? (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). (我猜DUMMY是因为innodb ,但是如果我的第一个猜测是正确的,我不明白为什么binlog在那里)。

  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? 是否有类似kcachegrind的工具可以打开多个文件并显示所有文件的kcachegrind (or is it possible somehow within kcachegrind ?) (或者是否有可能在kcachegrind ?)

Thanks!! 谢谢!!

btw - for people who extend and develop MySQL - there are many interesting things there that can be improved.... 顺便说一句-对于扩展和开发MySQL的人-有很多有趣的事情可以改进。

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 : 我只能在某些问题上为您提供帮助:是的,MySQL不会创建进程,但会创建线程,请参阅命令上的手册,其中列出了服务器当前正在执行的操作

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. 当您尝试确定MySQL服务器正在做什么时,检查进程列表(这是服务器中当前正在执行的线程集)可能会有所帮助。

(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. InnoDB日志独立于二进制日志,用于确保InnoDB执行ACID一致性。 Transactions are inserted there first and this file is used if the server crashed and InnoDB starts a recovery. 事务首先插入那里,如果服务器崩溃并且InnoDB开始恢复,则使用该文件。

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 也许您想在dba.stackexchange.com提问

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM