Bug #31314 | Strange impact of ndb_cache_check_time on cluster auto_increment performance | ||
---|---|---|---|
Submitted: | 1 Oct 2007 12:47 | Modified: | 14 Feb 2010 8:11 |
Reporter: | Hartmut Holzgraefe | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
Version: | mysql-5.1 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | 5.1.21 |
[1 Oct 2007 12:47]
Hartmut Holzgraefe
[1 Oct 2007 13:13]
Hartmut Holzgraefe
a few more observations: after running the tests i see the following query cache status mysql> show status like "q%"; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_free_blocks | 1 | | Qcache_free_memory | 33545304 | | Qcache_hits | 0 | | Qcache_inserts | 0 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 0 | | Qcache_queries_in_cache | 0 | | Qcache_total_blocks | 1 | | Questions | 30022 | +-------------------------+----------+ 9 rows in set (0.01 sec) compared to the status before running the test only the Questions value changed by ~30k there have been only two procedure calls, 10k INSERTs and 10k SETs though so i have no idea how this should add up to 30k query cache questions? The only substantial ammount shown in SHOW STATUS LIKE "Com%" is | Com_insert | 10000 | which is the expected result, all other Com_* values are < 10
[22 Apr 2009 14:44]
Jonathan Miller
This was also reported in http://bugs.mysql.com/bug.php?id=42729
[14 Jan 2010 8:11]
Martin Skold
Please verify this is not a bug, the cost of maintaining QC is independent of the operations since it is done by a separate monitoring thread.
[15 Feb 2010 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".