Bug #42215 ndb_mgm, incorrect result from 'report MemoryUsage'
Submitted: 20 Jan 2009 12:58 Modified: 11 Feb 2009 18:36
Reporter: Ole John Aske Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:5.1.30-ndb-6.4.1 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[20 Jan 2009 12:58] Ole John Aske
Description:
During the performance evaluation project for NSN pre-paid, test-DB is filled with 10M rows. During this fill process, it fails with 'Table is full'. ndb_mgm still reports only 24-25% memory used ('all report MemoryUsage') for both tables and indexes.

My configuration is with mt-NDB, running 4 LQHs, (Thread=8). I suspect the
memory calculation / reporting to be off by a factor 4 (#LQHs!) - or that ndb_mgm
is only reporting the memory usage from one of the 4 LQH's...

How to repeat:
Fill a test-DB until all memory are consumed - or use test client I will attach.
[21 Jan 2009 23:16] Hartmut Holzgraefe
Verified, each ndbmtd worker thread seems to assume it owns the whole DataMemory when replying to an ALL REPORT MEMORYUSAGE request.
[22 Jan 2009 14:18] Martin Skold
Setting prio P2 since if incorrect alarms might
cause cluster to run out of memory.
[11 Feb 2009 15:07] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/65918

3256 Jonas Oreland	2009-02-11
      ndb - bug#42215 - fix memory reporting for mt-lqh (tup memory)
[11 Feb 2009 15:08] Bugs System
Pushed into 5.1.31-ndb-6.4.3 (revid:jonas@mysql.com-20090211150728-xs02e448s5bb64q3) (version source revid:jonas@mysql.com-20090211150728-xs02e448s5bb64q3) (merge vers: 5.1.31-ndb-6.4.3) (pib:6)
[11 Feb 2009 15:10] Jonas Oreland
note, only if using ndbmtd with more than 1 LQH
[11 Feb 2009 18:36] Jon Stephens
Documented bugfix in the NDB-6.4.3 changelog as follows:

        When using multi-threaded data nodes, their DataMemory and
        IndexMemory usage as reported was multiplied by the number of
        local query handlers (worker threads), making it appear that
        much more memory was being used than was actually the case.