Compiling & Debugging MariaDB(and MySQL) in Eclipse from scratch – Part 4: «Profiling in Eclipse – Preparation»

Posted on junio 22, 2014 by
spacer

Section 5: «Prepare Eclipse for profiling»

5.1 INTRODUCTION

In this part we will prepare Eclipse to profile our recently compiled(see Part 3) MariaDB(or MySQL). Profiling means basically measuring where the time is spent by the application. You may be interested in knowing how much time is spent in a specific function execution, or you may want to know statistics about the dustribution of function calls, that is operating a data aggregation. In our example we will apply profiling to study a real case, we want to know where most of the time is spent when a bug is causing a query to be extremely slow. To be able to profile within Eclipse you should have a plugin installed, Linux Tools (eclipse-linuxtools), Linux Tools provides integration with some of the most common linux profiling tools, including oprofile that is the one we will use in our case, if you want to know more about the Eclipse oprofile plugin (and others) you can look at: http://www.eclipse.org/linuxtools/projectPages/oprofile/

5.2 VERIFY, UPDATE OR INSTALL LINUXTOOLS IN ECLIPSE

LinuxTools should come with latest Eclipse version but you can reinstall or update it by doing this in Eclipse:

  • Click on: [Help] –> [Install New Software]
  • Click on [Add]
  • In the popup window fill in:
[Name] Linux Tools
[Url]  http://download.eclipse.org/linuxtools/update
  • Click [Ok]
  • Then in the list you should have 3 elements: 
    * Linux Tools
* Linux Tools Additional Library API Hoverhelp
* Linux Tools Sources
  • Check the first two and click below on [Next]
  • You’ll be asked to review the selected packages, click again on [Next]
  • If asked [Accept] the license agreement and click on [Finish]
  • Restart Eclipse

Note: I prefer not to use screenshots or graphics so that the instructions are portable anywhere, moreover there is ample documentation on how to work with Eclipse so that if more details are needed you can always refer to the official documentation. Now you have Linux Tools plugin installed and updated in Eclipse. NOTE: Eclipse Linux Tools provide the integration between Eclipse and the profiling tools, but you still need to have them aready installed on the machine, since in our example we will work only with oprofile make sure you have it installed with: $ sudo yum install oprofile Please refer to OProfile Website if more help is needed with OProfile installation.

5.2.1 COMPLETE OPROFILE PLUGIN INSTALLATION

In the oprofile plugin README we read that since oprofile cannot run in user space mode we need to to a final step to have it all ready. First locate the Eclipse the ‘plugins’ dir with: $ locate org.eclipse.linuxtools.oprofile.core | head -1 And by using the path found above above: $ cd /path/to/eclipse/plugins/org.eclipse.linuxtools.oprofile.core_/natives/linux/scripts $ sudo ./install.sh Now you should be set. Keep in mind that Eclipse will launch oprofile using ‘sudo’, so the developer user running Eclipse(yoda) must have the ‘sudo’ rights, you can check that by: $ sudo visudo And add your user or make sure your user is in the ‘wheel’ (default sudoer group in CentOS) group: $ id yoda Depending on your ‘sudo’ configuration Eclipse may ask you your password via a popup window when launching oprofile, moreover if the profiling lasts more than the duration of the sudo password expiration it will be requested again at the end of profiling to post-process the results.

5.3 PREPARATION

We will use one of the simplest profiling oprofile technique(opcontrol) which counts the function calls, in particular it can measure: * user application calls * shared libraries calls * kernel calls For user application calls oprofile can point you directly to the source code files and lines within Eclipse(good for debugging), for shared libraries and kernel calls it depends on the availability of the sources on the system. It should not normally be needed thou to debug(go to actual code line) the source code of shared libraries or kernel code, still it can be good to profile them(count), so that we will choose all the three above. Consider that profiling (like performance analysis & tuning) is an art and a science so that what is good to do in each case depends a lot on the engineer intuition. My suggestion is, in doubt, curiously try all combinations(in this case profile only user application calls, or all calls) and see which data makes most sense to you for your specific case. [TIP] Since the debug build has a very large amount of calls to debug functions, profiling a debug build will skew too much our results, for this reason we will build MariaDB without the debug option. So if you refer to Part 2 of this series you can disable the debug build by changing the command at 2.3: From: $ cmake -DBUILD_CONFIG=mysql_release -DCMAKE_BUILD_TYPE=debug -G"Eclipse CDT4 - Unix Makefiles"
-DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE ../mariadb-10.0.11 To: $ cmake -DBUILD_CONFIG=mysql_release -G"Eclipse CDT4 - Unix Makefiles"
-DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE ../mariadb-10.0.11 As you see we removed the -DCMAKE_BUILD_TYPE=debug option. If you took the wise decision to keep the project folder separated from the source folder you can continue with keeping different project configurations(debug, nodebug, etc) separated, so if you follow the instructions at Section 2.1 of Part 2: Replace: $ mkdir mariadb-10.0.11-eclipse $ cd mariadb-10.0.11-eclipse With: $ mkdir mariadb-10.0.11-eclipse-nodebug $ cd mariadb-10.0.11-eclipse-nodebug With the same principle, when you will generate the binary tar.gz package(make package) for the local installation, name the extracted folder coherently with the project type so that you can easily understand what build is that, in this case, following the instruction in Part 3, Section 3.2, the steps will become: (the package was already created before with make package, refer to Part 3, Section 3.1) $ cd ~/playground/mariadb-10.0.11-eclipse-nodebug $ tar -zxvf mariadb-10.0.11-linux-x86_64.tar.gz $ mv mariadb-10.0.11-linux-x86_64 ../mariadb-10.0.11-linux-x86_64-nodebug $ cd ../mariadb-10.0.11-linux-x86_64-nodebug $ scripts/mysql_install_db --basedir=`pwd` --datadir=`pwd`/data --user=yoda If you compare the above with the instructions at section 3.2 of Part 3 you will notice that we changed slightly to extract the package inside the project directory to avoid the package to interfere (merge) with any existing package already extracted in our root working directory (~/playground), because the generated .tar.gz would extract with same folder name. At this point we have a own compiled, no debug build, mysql database already installed and initialized and ready to be profiled. As said above, we want to profile a nodebug build to avoid interference of the debug functions calls with our profiling. The debug build will be useful when we want to do proper debugging since it contains more informations for this purpose, in MySQL enabling debugging also enables the DBUG package (http://dev.mysql.com/doc/refman/5.5/en/dbug-package.html). For a wider explanation on what a debug build enables you can refer to: http://dev.mysql.com/doc/refman/5.5/en/debugging-server.html Now we are ready to start profiling within Eclipse with oprofile on Part 5. You might also be interested in:

  • Part 1 «Setup the building environment»
  • Part 2 «Compile in Eclipse»
  • Part 3 «Running in Eclipse»

This is the end of Part 4.