DimitriK's (dim) Weblog

MySQL Performance: Collecting stats from your workload

Pretty often I was asked by many people about solutions I'm using while analyzing MySQL performance issues and generating various graphs presented in my reports and blog posts.. - Well, I've always used and continue to use dim_STAT - the tool I'm developing myself since 15 years now, and which is freely available on this site :-) The tool is mainly collecting any kind of stats from the system and applications, and then giving you a way to analyze them live or later via web interface - nothing new now days, but well, I have my habits, like to play with collected data and want to know exactly what I'm analyzing ;-)) (while many of you are using other tools, including a really excellent MySQL Enterprise Monitor, and it's all ok for me too - as in my mind changes are coming only since people become unhappy with what they have, or hitting some limitations, etc.) -- personally, I'm pretty happy, and wish you the same ;-))

But I have a small problem -- I'm very curious by problematic workloads (and already started a call for workload scenarios this year, and many thanks to all who answered) -- but now I'm also very interested by workload stats, specially if you're trying MySQL 5.6 and hitting some unexpected performance issues on your system ;-)

• provide a connect info for your MySQL instance (user/password/host:port)
• check some system libs are not missed on your system to run my binaries (and install few missed if any)
• collect stats with 10sec interval during your workload
• send me the result

# cd /etc

• be sure your database is running ;-)
• be sure MySQL access via IP is not protected by your firewall
• be sure MySQL is listening on the IP port you've configured
• be sure user/password pair is correct..
• goto 1. and debug ;-)

• innodb_monitor_enable = '%'

• performance_schema=ON
• performance_schema_instrument='%=on'
  
  
• and once MySQL is started, execute the following SQL statements to enable mutexes and I/O instrumentation only (if you don't need any other):
  • use performance_schema;
  • update setup_consumers set enabled = 'no';
  • update setup_consumers set enabled = 'yes' where name like '%instr%';
  • update setup_instruments set enabled = 'no', timed = 'no';
  • update setup_instruments set enabled = 'yes', timed = 'yes' where name like '%wait/synch%';
  • update setup_instruments set enabled = 'yes', timed = 'yes' where name like '%wait/io/file%';

dim_STAT v.9.0 is here!

The main "global" change in dim_STAT v.9.0 is a move to the latest MySQL 5.5 GA version. This move was driven by willing to use a true transactional storage engine within MySQL (which is InnoDB) to avoid any database files repairing in case of systems hang or unexpected power-off.. - Now you're free to choose which storage engine you prefer to use for your data and select MyISAM or InnoDB on your database creation. As well at any moment you're able to convert any database to InnoDB or MyISAM according your needs. As such a process may be quite long enough with big databases, there is a command line tool dim_STAT-Admin coming since v.9.0 - you're able now from a command line involve DBA actions:

• Create a new Database
  
  
• Convert existing Database to another Storage Engine
  
  
• Backup a whole Database
  
  
• Export STAT Collect(s)
  
  
• Import STAT Collect(s)
  
  
• Recycle STAT Collect(s)
  
  

dim_STAT v.9.0 is shipped with a "remastered" MySQL v.5.5.15 Community Edition (GPL) - it's different from the "official" MySQL 5.5 by being more compacted (all debug and test stuff is removed) and compiled in way to have less dependencies to work just out-of-the-box if possible (for ex: on Linux you'll not need AIO library, etc.). The configuration parameters are mostly present within "my.conf" file, all settings are just minimal to not use too much RAM or disk space. On the firs start InnoDB data and log files will be created, but you may adjust the settings later.. Well, my goal was to ship a compact and just working MySQL with dim_STAT, but feel free to replace it by any other MySQL version! ;-)

Another new stuff coming with v.9.0 is an experimental dim_STAT for MacOSX ! :-)) I've preferred to share it rather just enjoy to use it alone on my Mac ;-)) However, I did not yet fully tested it as I don't have (yet) another Mac ;-)) and don't want to spend any time to install MacOSX in VM.. - if somebody will want to use it on Mac I'll have first news very quickly ;-)) if no - another reason to not spend too much time on MacOSX distro ;-))

Then there is a huge list of "internal" improvements which will say you nothing, but will greatly improve your usual work with dim_STAT ;-)

But main "visible" new features are:

• simplified INSTALL process (and I hope you'll feel it since the first installation ;-))
  
  
• MySQL regular expressions can be used now within Multi-Line stats to enforce name criteria..
  
  
• name filter is added into all Multi-Line pages to be able to reduce the list of names when it's too long and simplify selection on ly of the names you need..
  
  
• value distribution graph is now working not only with Java Applet, but with PNG too..
  
  
• for any stats while drawing some data you may also (or instead) draw a sum of all selected values (ex: Usr% and Sys% CPU Usage as CPU Busy%)..
  
  
• absolutely amazing Multi-Host Bookmarks ! - gives you a way to analyze several hosts in parallel in more advanced way: you're analyzing stats within a Single-Host mode first, applying all criteria you need (ex. seeking only for "oracle" and "sqlplus" processes CPU Usage, and then saving the obtained graph as Multi-Host Bookmark, and after with a one click analyzing the same graph but with many hosts within Multi-Host mode ;-)) (NOTE: don't forget that only one stat value is allowed to be presented on the Multi-Host graphs, if you're drawing more than one value on your graph - the Multi-Host Bookmark option will not be presented..)
  
  
• dim_STAT-CLI is now able also to draw Multi-Host graphs if several Collect IDs are given in argument (-ID id1,id2,id3,..)
  
  
• Export is now have a time interval option in case you need to export a particular part of your Collect rather the whole collected data..
  
  
• STAT-service is now also reporting when the connection was lost with a server or a stat command closed it's pipe (possible abnormal finish), as well such messages are appearing in errors on the Web interface..
  
  
• by default any non-system stats are disabled (commented) now within STAT-service - I was surprised how many users are mostly clicking on all available stats and making troubles on their systems (for ex. involving DTrace for non-existing stuff, etc.) - since v.9.0 you have to enable it manually by editing /etc/STATsrv/access file (which is supposing that user is aware of the changes ;-))
  
  
• HAR2 for Solaris 10 was updated to version 2.1 (thanks to ISV team! ;-))
  
  
• LioSTAT_v10 (iostat v.10) was introduced to Linux stats (seems to work better with recent Linux distros)..
  
  
• mysqlSTAT was updated/improved
  
  
• innodbMETRICS was introduced (still experimental) - allows to monitor InnoDB METRICS table within MySQL 5.6
  
  
• oraASMIO was introduced to monitor I/O activity via ASM on Oracle RDBMS (including Exadata ;-))
  
  
• Add-On management was yet more simplified and improved, and since now you're also able to re-edit any of your Add-On descriptions directly via Web interface!! ;-))
  
  
• etc..

NOTE: the STAT-service packages are no more shipped within dim_STAT distribution to avoid file duplication within each tarball, however they are always freely available for download from the site (or directly from the STAT-service space). I've also removed .pkg files for Solaris as creating them all the time is quite painful process, while .tgz remains the same for all platforms and protect me from forgetting some of files within a .pkg list ;-))

Well, there are many other still visible, but minor features (some details I've also explained in the previous post about a Core Upgrade.), but I'll avoid to list them here and leave you to discover them yourself ;-)) There are also many other features I've planned to ship with v.9.0, but it was urgent for me to ship the new version as soon as possible, so my main priority was focuses on the most "critical" features related to MySQL 5.5 adoption and general usability (like Multi-Host Bookmarks and dim_STAT-Admin). My goal is matched now, event it took me a major time of my week-ends and vacations during last 6 months ;-)) but there was an urgency because since next week I'll become a "true" Oracle employee, and I prefer to suspend any new dim_STAT development since now to avoid any potential conflicts regarding software proprietary (or until any changes will come in situation).. - shipping v.9.0 today on the remaining conditions gives me a satisfaction point for over 14 years of development ;-)) and it was hard as well to suspend my developments without shipping v.9.0 before.. ;-))

So far, there is still missing Solaris 10 x64 version (did not have an access to a needed server on time, so sol10-x86 version will come later ;-)) and Solaris 8 /SPARC is missed too as I don't have an old enough server available around me, so cannot guarantee the dim_STAT v.9.0 will come later for it and don't know if there is any need.. - a simple PC is now faster than a very old SPARC, so using a simple Linux box makes more sense now days ;-))

However, I hope to still be able to continue support of dim_STAT (and fix bugs if any), just only new features will be suspended until a new order ;-))

dim_STAT: Experimental Core Upgrade v9-dev1

As there were several users expressed to see dim_STAT v.9.0 improvements before than the "official" release will be available, I've decided to ship a "Core Upgrade" - a current scripts version corresponding to the "v9-dev1" level. This upgrade is experimental, and even if I'm applying all these changes on our LAB servers on regular basis it still doesn't mean it'll work as well for everybody :-))

So, before to involve any deployment of Core Upgrade, please do a backup of your currently installed scripts.

NOTE:

• the upgrade is only applicable if you're running the latest "official" dim_STAT version! (currently v.8.5)
• the upgrade is platform independent as it'll change scripts only, so doesn't matter if you're running dim_STAT on Linux or Solaris :-)
• as well I'm always taking care about a backward compatibility, so no one from new features requiring any new tables in database, etc. (and even when it's really required, all missed stuff will be created automatically on demand by the tool itself)..

So far, following are the instructions about upgrade installation (default directory names are used below):

• First of all, stop your dim_STAT server:
  # /apps/ADMIN/dim_STAT-Server stop
  
  
• Backup your current core scripts:
  # cd /opt/WebX
  # tar czf /MyBackup/WebX_apps-backup.tgz apps
  
  
• Deploy downloaded Core Upgrade v9-dev1:
  # cd /opt/WebX
  # tar xzf /PathTo/WebX_apps-v9-dev1.tgz
  
  
• Start dim_STAT server:
  # /apps/ADMIN/dim_STAT-Server start
  
  
• Enjoy! ;-))

Well, I very hope there will be no issues and you'll really enjoy new features rather restore old scripts from your backup :-)) but in case you have some problems - follow the same steps, but don't do the backup again and just restore your backup instead of Core Upgrade deployment..

However, let's hope it'll be OK and you're ready now to discover new features ;-))

Of course, there are many features that you'll be not able to see because they are related to the internals and general code improvements.. - probably you'll feel that the same tasks will run faster, don't know, as the true changes will come with a final v.9.0 running on MySQL 5.5 :-)

But here is the list of the new features or fixes that you'll see for sure:

• fixed: Extended Multi-Host analyzing is now working to draw graphs even if no Mutli-Host stats were selected!
  
  
• fixed: Date tags on graphs are no more mixed if the time interval is too wide (several weeks or more)!
  
  
• Error messages are now logged in case when the communication was lost with a STAT-service from an active collect!
  
  
• Regular expressions are used now for name selection criteria in multi-line stats!
  
  
• List of names within multi-line stats have now a Filter option (to reduce the list size and simplify per name selection)!
  
  
• On Multi-Host Analyze is possible to show a SUM/AVG values for all hosts together via Group by Name option and use 0 in the Name length!
  
  
• Data Distribution graph is now working not only with Java Applet option, but with PNG drawing too!
  
  
• For any values you want to present on the graph you may now choose also to present the SUM of all these values (or just the SUM instead) - it helps in many cases when you need to analyze the totals! (for ex. for CPU% usage to see the Sys%, Usr% and Sys% + Usr% on the same time; or I/O Read/sec, Write/sec, and Read+Write/sec; etc.)
  
  
• And then the most exciting feature - Multi-Host Bookmarks!! ;-)
  

Why Multi-Host Bookmarks? - it was quite painful to not have the same flexibility on the Multi-Host Analyzing as on the Single-Host. Specially when you're interesting, for example, not just on a global CPU usage on several hosts, but on CPU usage of some particular processes (ex. oracle). In this case you may make a specific Bookmark by selecting only Oracle processes names (as filter) and CPU% Usage within ProcLOAD (for ex.) and then apply it on the Multi-Host Analyze! :-)) Same if you're looking on particular list of storage devices (ex. only those on c0 and c4 controllers) and want to graph their activity from several hosts and on the same graph (rather the SUM of all devices) - now it'll be possible! :-)

How can you create a Multi-Host Bookmark? - just keep in mind that you can bring only one single value to show it on the Multi-Host activity graph! - in case of single-line stats (ex. vmstat) it may be any value (ex. free memory), in case of multi-line (ex. iostat) it can be only an aggregate (SUM/AVG/etc.) as it should result in a single value at the end. And then this value is presented on the same graph for every host name. So, just keep it in mind when you're doing a Single-Host Analyze, and once your graph is ready, as usual you'll see a field on the bottom of the page to Save Graph as Bookmark, except that now there will be an option to save it as Single-Host or Multi-Host Bookmark :-) The option for a Multi-Host Bookmark is appearing only if you're drawing only a single value on your Graph and not using Host-related criteria (top-10 disks, etc.), as only "generic" criteria will be allowed (name mask, value conditions, etc.).. Well, it's longer to tell rather to try :-))

Where Multi-Host Bookmarks can be used? - everywhere ;-)) Well, currently they are mixed with "classic" Multi-Host stats, but with a time I'm expecting to transform all Multi-Host stats into Multi-Host Bookmarks (and let me know what do you think about) - Bookmark naming is way more flexible comparing to auto-generated ones for SUM/AVG/etc :-) And since upgrade you'll be able to use Multi-Host Bookmarks in:

• Multi-Host Analyze (as expected ;-))
• Report Tool
• dim_STAT-CLI - yes!! ;-)) - you can now give a list of IDs like "-ID 2,3,4,5" and in this case Multi-Host Bookmarks will be used instead ;-) and as well you may use by Host Name Grouping via "-Group Aggr:Len" where Aggr is the Aggregation operation (SUM/AVG/MAX/MIN) and Len is the length of the first N characters in the Host name by which you have to group your data. For ex. "-Group SUM:4" will group data by the first 4 letters in the name of your Hosts and draw the SUM of them (very useful if you have so many hosts that a single host activity is not really important, and you have rather to analyze groups of hosts (and as you may rename hosts as you want via Preferences, it's easy to choose naming which will well match your future grouping ;-))

Well, enough said, it's time to try it now! :-))
The link is here: Core Upgrade-v9-dev1 .

If this experiment will be successful, I'll continue to ship similar Core Upgrades in the future to avoid a long wait for the next final versions and have more reactive bug fixing (if any) and new feature availability as well ;-))

Any comments are welcome!

Rgds,
-Dimitri

MySQL Performance: Improving Stability

Huge performance improvement was came with MySQL 5.5.4, and looking on the following picture it's very easy to see why:

It's a one hour Read+Write dbSTRESS workload with 32 sessions running non-stop on 16 cores server. The left part of the picture corresponds to MySQL 5.1 activity, and the right one to MySQL 5.5.4. The first graph represents TPS levels, and the second one - the mutex waits observed during each test.

Even without going in details you may see how dramatically were reduced mutex waits! And I would say one of the greatest InnoDB features was a compact presentation of the "show innodb mutex" output which gave the way to monitor InnoDB more in depth and understand its contentions on each workload! - it's still not perfect, but anyway a big step ahead :-) and helped a lot to improve 5.5.4.

From the mutex waits graph you may see that the most hot "visible" contention now is on the index mutex (well, the output "file:line" is probably better for debugging rather a normal use - it's one of the things to improve here, just to be more human friendly and show a mutex name instead, as well the code is already there and require a small format changes)..

From the other side, purge lagging is another problem - you may see the same (apples to apples) workload on MySQL 5.1, MySQL 5.5.4 and XtraDB 9.1:

The first graph is still representing the TPS level, and it's interesting to see the potential performance gap between 5.5.4 and XtraDB during the first 10-15 min of test (and if we stop the test here we'll simply miss the next problem and will not see decreasing performance with a time on both engines due purge lagging..). The second graph represents the InnoDB history length, and as you may see it's growing now even faster than before! :-) And the problem is supposed to be fixed with a purge thread.. But let's get a look on one problem at a time :-)

Index Mutex Contention

It'll be great just to get it fixed ;-) But as you know, an simple way to reduce contention on a single mutex is to split this mutex into several ones (so you'll split your contention too, and instead of having say a one single session working at a time - you'll have several sessions working, etc.). And currently MySQL has a nice feature - PARTITIONS! :-) By using partitions on a table having index mutex contentions will simply split this contention by number of partitions! (for example using 3 partitions will physically split your table into 3 tables (even you'll still see it as a single one), and instead of one index mutex you'll have 3 mutexes as well dividing your contention by 3 probably too :-))

However on the next picture you may see the performance impact on 5.5.4 by using 3 partitions on the hottest table during the same Read+Write workload as before:

As you may see, curiously TPS level did not change... And we may suppose that partitions would not help here if we did not have improved mutex status within InnoDB and did not see there is another mutex waits jumped to the top and become more hot once we used 3 partitions! (while index mutex was really readuced! - that's why monitoring is so important :-))

What about this new mutex waits? - this is a dictionary lock on stats update. The fix was already proposed by Percona, and is not yet present in the current 5.5.4 tree - but as it's just a one line changes I've tried to see what if it'll be done on 5.5.4:

As you can see, the TPS level is improved! (over 20% gain!), and the main "visible" mutex waits are now on the redo logs - which may probably be considered as expected contention for a database in general :-)

But where we're with a history length now?..

Purge Lagging

Now let's get a look on the same workload but from the stability perspective.. Having constantly growing history length is not normal and quite dangerous! As well having periodic performance drops is not better too :-) And the Purge Thread feature is the answer here. But let's look in details how it'll help - the following picture represents the same workload tested on:

• MySQL 5.5.4
• MySQL 5.5.4 +purge thread
• MySQL 5.5.4 +3 partitions
• MySQL 5.5.4 +3 partitions +purge thread

The first graph is TPS, the second one is History length:

As you may see, Purge Thread brings an important stability to the workload. However a single purge thread is no more enough to follow a purge demand here!..

Currently 5.5.4 implementation allows only one purge thread for the moment. But to analyze a performance impact we may try XtraDB which already allows several purge threads. The following picture represents the same Read+Write workload running on XtraDB 9.1 using 3 partitions and tested:

• without purge thread
• with 1 purge thread
• with 2 purge threads

The first graph represents TPS level, and the second one History length:

As you may see having 2 purge threads are completely removing purge lagging here! However it's also significantly reducing performance..

Can do we better here?.. - let's try ;-)

For a long time InnoDB has a purge lag configuration option - you can limit purge lagging with innodb_max_purge_lag by setting it to some acceptable level of History length, then once this limit will be reached InnoDB will slightly slow down all arriving DML queries by doing a short sleep (few ms) before processing a query statement. The feature itself is not bad, and many file systems are having a similar solution to throttle a high demand write requests. The only problem with InnoDB purge lag feature that it's broken seems to me, and I've explained why and how to fix it . Now if I apply the fix to XtraDB and see the result ;-)

What I'm interesting here is to compare:

• single purge thread + fixed purge lag
• two purge threads

Of course fixed purge lag without purge thread cannot give us a stable result due all missed maintenance work missed by Master thread (as explained in the previous post ). However, having one purge thread and throttling writes via max purge lag setting may still give a better result than having 2 purge threads..

On the following picture you may see the same Read+Write workload running on XtraDB 9.1 and now comparing:

• XtraDB without purge thread
• XtraDB with a single purge thread
• XtraDB with 2 purge threads
• XtraDB with a single purge thread + fixed max purge lag

The innodb_max_purge_lag was set to 400K here:

As you see, the tandem of single purge thread + fixed purge lag gives a better result here than 2 purge threads - TPS level is higher while History length is constantly kept under 400K! :-)

Why on my point of view such a solution will be more optimal?

• in many cases one purge thread will be probably just enough
• however when it'll be not enough - your server will still be protected by the max purge lag setting!

As always, many things depends on workload, and your experience may be different of mine.. - but tests and observations will be done, better MySQL performance will be with a time :-)

Any comments are welcome! ;-)

New features in dim_STAT v.8.5 for InnoDB Monitoring

Last week the new version 8.5 of dim_STAT was shipped. Along with other new features, there is a new Add-On was introduced since this version: innodbMUTEX. The data collecting by this Add-On are based on the "show engine innodb mutex" output. And it's not only able to scan the "standard" output, but also the "extended" output as well (by extended I mean if with debug options or with a little bit of hacking you'll force InnoDB to print other mutex wait values - they are already present within a code, but by default enabled only for debugging currently). For example in my case I wanted to analyze if in every case a mutex having the highest number of waits/sec will be also having the highest waited time.. - And it was not always true :-) But at least it's true for the rollback segment mutex:

Other previously introduced Add-Ons were also updated (mysqlSTAT, mysqlLOAD, innodbSTAT), and you may get more details about them from here .

As well I'm presenting dim_STAT during MySQL User Conference next Wednesday at 4:25PM - so if you have any questions/ need more information - don't miss a live story :-) Of course I'll also speak about dbSTRESS (as it's fully integrated into dim_STAT from a long time) and hope to play a live demo with live data from several recent tests - so it should be fun :-)

To download the Linux or Solaris version of dim_STAT: http://dimitrik.free.fr 

dim_STAT v.8.5 is here! :-)

Hope it's the last 8.x version release and the next one will be really the v.9.0 :-)

Curiously there were still many things to finish before to say yes, we may start a new version tree :-))
First of all I was surprised to discover some minor bugs and prefer to fix them still within v8 rather to bring them to the v9 again :-)) Then there are some new and very powerful improvements which cannot wait so long :-)) And finally I've also wanted to bring some order into distribution/packages version-ing and resolve historical ambiguity of names :-)

So far, this release is jumped to the v.8.5 not because you're missed v.8.4, but just because within a STAT-service packages I've started to tag new updates with "ready for 8.4+" which bring ambiguity when you're still using the v.8.3 :-)) So, since this release you may find a VERSION file included withing every STAT-service package, dim_STAT distribution, or already installed dim_STAT server. This file contains the version number of dim_STAT as well the OS/platform information. Hope it'll simplify many things from now :-))

As well, the list of all main changes coming with release:

Fixes :

• Database Password fixed (curiously nobody reported it until now - it's fine to know that most of users are not paranoid :-))
• CPU Count was not exact in some conditions within Multi-Host graphs
• Empty graphs are skipped within Report generations
• Updated documentation :-)

Improvements :

• New Analyze option: Extended Multi-Host Analyze - it combines now the classic multi-host interface + all single-host bookmarks! - you're able now to mix on a single page your multi-host graphs and per host graphs coming from bookmarks! :-)
  
  
• Bookmarks links now also available for the Multi-Host too - at any time get a more detailed view per each host available via Bookmark graphs! :-)
  
  
• Surprisingly there was still a room for performance improvement on WebX - new code is running even faster than before and particularly when generating a long list of graphs! (which is also dramatically reducing a generation time of Reports :-))
  
  
• STAT-service is now accepting the syntax with command_name[:port] - it gives a possibility to run several STAT-service daemons in parallel on different ports, and according the port number assign a different final command for the same "stat name" (for ex. see how to collect data in parallel from 3 different Oracle instances running on the same server: name[:port] feature )
  
  
• Graphs accidentally involved with a too large list of items now will be auto-reduced to the lower number of items and include a short error label within a legend
  
  

EasySTAT additional options :

• Additional LOG option may be used in cases the EasySTAT output should be redirected to a file rather to be printed to the standard output (when it should to be not mixed with output from other programs/daemons running in parallel)

New Add-Ons :

• UDPstat (Solaris: UDP traffic stats)
• innodbMUTEX (MySQL: detailed InnoDB MUTEX monitoring (available since InnoDB plugin 1.0.4))

As usually, you may download all distributions from the main site: http://dimitrik.free.fr as well I'm looking for solutions to mirror at least distribution packages as the download is not always as fast as expected from "free.fr"...

Any comments are welcome! :-)

Performance Trainings & Conferences in Kiev

Last week I've participated in several Performance Conferences and Trainings in Kiev. Events mainly were dedicated to the latest improvements within MySQL performance, as well Solaris and Oracle tuning / performance analyzing and best practices. The week was very hot :-) but I've enjoyed every day discussing with creative and smart people! People hungry on knowledge and ready to stay 2 hours more overnight outpassing all allowed timing - it was a real pleasure to share all I know! :-))

So, I'd like to thank all participants! As well Sun@Kiev and i-Klass teams who organized and prepared all these events! I may only wish to see such events more and more often, and don't forget to invite me again! :-))

NOTE : similar conference about MySQL performance improvement will be organized soon in Paris - so if you're interesting in (and speaking French :-)) - please, contact me ahead, we'll need to know the size of the auditorium to be able to have seats for everybody :-))

After all that said, here are few images from the "road notes" and my slides or other materials used by me during presentations (as promised)...

Kiev Polytechnic Institute

25 years ago I came here expecting to be accepted as a new student.. And spent 6 years of my life to study maths, computers, programming, as well many other topics (even if some of them were here only to develop your brain and did not have any real usage :-)) I was invited to discuss about of databases scalability and the latest improvement made in MySQL performance. The conference was prepared to celebrate the Software Freedom Day in KPI ...

After so many years, entering the Main campus building was so impressive.. The Main Auditorium in this building should still remember so many famous names ... Did I expect one day to find myself on the podium and presenting my work to others?.. :-)) Initial stress was very high.. but discussing and presenting to students was so fun - that in few minutes I've got a feeling I'm speaking with old friends, and everything goes just fine :-))

Presentations :

• Databases & Scalability slides
• MySQL Performance slides
  
  

MySQL Performance conference @i-Klass

i-Klass is very well placed in Kiev near and face to the one of the most famous and beautiful Church in Kiev - Kiev Pechersk Lavra - simply must to visit if you're traveling in Kiev :-)) BTW, there is also a famous museum of micro miniatures (the world's smallest chess board you may see on following photo). Also, did I say you the food is absolutely excellent in Kiev?.. ;-)

i-Klass is a very good partner of Sun, and for such event they prepared their bigger conference hall accepting near 350 persons. The event itself was very successful as nobody left till the end :-)) as well a big part of participants preferred to stay one or two hours more again but do not miss the last uncovered topics :-) As well I was surprised to discover Percona presence even in Kiev! :-)) And I'm still waiting for photos from this event :-))

Presentations :

• MySQL Performance slides
• DTrace & MySQL slides from Joyent

Solaris Performance Monitoring & Analyze @i-Klass

Two next days covered Solaris performance and Oracle-oriented system tuning. We expected 20 persons for each event as practice lab supposed to have a Solaris desktop on the desk and there was not too much place in the room. But finally we got 45 persons every day and most of people came with their own laptop running Solaris! :-))

I've enjoyed all the time during these trainings and was happy to see so many strong engineers loving Sun technology and proud of their choices! :-) Some partners and customers I've already met during their benchmarks in Paris :-) All other are always welcome to test and improve performance of their applications in our Sun Solution Centers !!!

Also, one of the fun events was a direct connection with our Paris office and presenting live (with my colleague Matthieu) the demo of Automated Dynamic Reconfiguration with LDOMs! It was absolutely fantastic seating in two different locations and work all together as a one single team! Seems we made a new step in our activity :-))

Note : Last day due Internet connection problems we did not finish our stress testing with Oracle in Solaris zones - all who still want to participate in the remote testing please contact me before next Tuesday, because on Tuesday we'll replay live all programmed tests! :-))

Presentations :

• Solaris Performance slides
• Pools & Zones Overview slides
• LDOMs Training slides by Maria AVILA (Sun Solution Center)
• Automated Dynamic Reconfiguration (ADR) via dim_STAT slides
  
  

Bye, bye...

Thanks again to all participants and see you next time! :-))

dim_STAT: version 8.3 was updated!

Dear friends/users!

I've just published an updated 8.3 version. This is a minor update, just to fix some abnormal issues and add few more features...

Here is a list of changes coming with update:

Fixes :

• dim_STAT-Server script on start did not restat active collects (special thanks to Didier DAHIER to find it!
• dim_STAT-Server script is now killing all clients too when involved with "stop" action
• Standard Bookmark kit was not installed by default within a template database (special thanks to Peter Hausdorf to find it!)
• Linux iostat binaries updated for STAT-service to fix broken output in some cases (special thanks to Melanie Ashworth-March to find it!

Improvements :

• Added UNIX signal traps to WebX
• Replaced crypt() function to reduce WebX binary dependencies (now again compatible back to Solaris 2.6)
• Added active collect(s) information (extending active connections)
• etc..

Database schema :

• Bookmark name size was increased to 32 characters now!

EasySTAT additional options :

• COMPRESS and TIMER options are now integrated within EasySTAT.sh and enabled by defaul
• Run forever if Hours == 0
• Supporting integration within /etc/inittab for automated stats collectin
• Special actions are involved on signal trap (see doc
• pid file is created within a working directory to simplify EasySTAT process identification

New Add-Ons :

• mysqlLOAD (compact MySQL stats oriented multi-host monitoring
• pgsqlLOAD (compact PostgreSQL stats oriented multi-host monitoring)

dim_STAT: Version 8.3 is ready!!! :-)

Dear friends/users!

I'm pleased to announce you the new release of dim_STAT - v.8.3 !

This is a mainly maintenance update release, just to fix all trailing issues before a big move to the v.9.0 :-))

Here is a list of some changes:

Fixes:

• security issue on STAT-service!! (special thanks to Marc Koderer @LHS to find it!)
• execution of dim_STAT-CLI from the web services
• fixed LANG=C and LC_ALL=C via the main STAT-service script

Improvements:

• Optional Admin password may be given on a database creation and then it'll be required for any admin action!
• Database error messages are now handled separately from LOG messages
• Java WebDRAW Applet updated
• add color LEDs near hostnames to signal running or stopped hosts
• add #Records column to have an idea about a number of database rows per collect
• Admin LOG management is working more friendly now with a long lists of messages :-)
• STAT-service daemon may listen exclusively on a given IP address now [IP:port]
• Whole database backup is added to the Admin menu
• etc..

Database schema:

• iostat disk names are extended to varchar(64)
• all float values are moved to float(25,5) to have an easy human reading :-)
• Add-On name limit is 14 characters now

Report Tool:

• wiki-like syntax is added to simplify writing!
• look & feel updated
• some minor fixes here & there :-)

New Add-Ons:

• HAR v2 (visit http://blogs.sun.com/openomics/entry/cpu_hardware_counter_stats for more details)
• Solaris CPU Set STAT (mpstat -a)
• Linux MPSTAT v2
• MySQL STAT
• InnoDB STAT
• InnoDB I/O STAT (adoption of Neel's DTrace script http://blogs.sun.com/realneel/entry/inniostat_innodb_io_statistics )
• PgSQL STAT (PostgreSQL)
• ZoneLOAD: zoneid => zonename

EasySTAT additional options:

• COMPRESS=gzip (compressing of output files)
• TIMER=yes (auto-timestamping within output files)

Also, since this 8.3 version dim_STAT is moving to GPLv2 license! Most of source code will be published in parallel with binaries - and with time you'll probably find it ported on any platform, even Mac :-)

As well several things are added to simplify a knowledge sharing between dim_STAT users:

• this blog is added now on my site: http://dimitrik.free.fr/blog  and it contains a special category "dim_STAT" - you may subscribe on it to stay updated about any news or features coming with dim_STAT
  
  
• there is a dim_STAT on Google Groups now: http://groups.google.com/group/dimstat - you may share here all your best practices, additional stuff you have, ideas about new features, etc. etc. etc. (For example, there is a STAT-service daemon rewritten in Perl by Marc KODERER (http://search.cpan.org/~mkoderer/ ), ZFS stats add-on added by Roman IVANOV (http://blogs.sun.com/pomah/entry/monitoring_zfs_statistic ) and many other you may google for, but now may all be referenced from the same place)..

And finally following users requests a "Donate" button is added for those who wants to support the development of this project and see new features coming faster! All credit cards are accepted! :-))

As usually you may download both versions (Solaris & Linux) from http://dimitrik.free.fr  

Have fun! :-))

dim_STAT: Release Candidate 8.3 version

I'm very happy to present the last 8.3 release candidate version of dim_STAT!

This preview version was announced last week during my Master Class sessions I gave directly in Kiev (UKRAINE) for Sun partners, customers and employees. The Master Class session covered Performance Analyzing on Solaris and as well dim_STAT presentation and hands-on. It was a big pleasure for me and seems for users too because all sessions were very well received, and all attendees sent us very positive feedbacks! I expected to blog about while I was there, but was too tired after each class :-))

So, as the story was successful, probably new sessions will take place again in Kiev this year, and if you're interested in - just drop me an email.

But for the moment you may try a 8.3 preview version from here:

• http://dimitrik.free.fr/dim_STAT-v83.tar  (Solaris/SPARC)
• http://dimitrik.free.fr/dim_STAT-v83-sol86.tar  (Solaris10/x86)
• http://dimitrik.free.fr/dim_STAT-v83-lux86.tar  (Linux/x86)

If you'll find any problem (even very minor) - don't hesitate to send me an email - I'll be happy to fix it before the official 8.3 will come!