Bug #49535 Available memory check slows down crash recovery tens of times

Description:
For more discussion see:
http://mituzas.lt/2009/12/08/crash-recovery-again/

But in short, there's very expensive call for mem_heap_get_size from recv_scan_log_recs, that will use >90% of CPU in crash-recovery log reading process.

How to repeat:
crash busy server with large transaction log

Suggested fix:
removing the 'memory overflow' check:

http://p.defau.lt/?xHI2A_wc1pwyYvNNx_SbWA

allowed the stage to complete in few minutes, instead of not being able to complete in half an hour.

triage: setting tag to SR51MRU (P2 based on Calvin's note - I level can be corrected once issues are attached to bug

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/104851

3497 Sergey Vojtovich	2010-04-01
      Applying InnoDB snapshot, fixes BUG#49535.
      
      Detailed revision comments:
      
      r6674 | inaam | 2010-02-11 17:54:44 +0200 (Thu, 11 Feb 2010) | 16 lines
      branches/zip bug# 49535
      
      This is a backport of r4924.
      mem_heap_get_size() scans all allocated blocks to calculate the total
      size of the heap. This patch introduces a new, total_size, field in
      mem_block_info_struct. This field is valid only for base block 
      (i.e.: the first block allocated for the heap) and is set to
      ULINT_UNDEFINED in other blocks.
      This considerably improves the performance of redo scan during recovery.
      
      rb://108 issue#216
      
      Approved by: Heikki

Pushed into 5.1.46 (revid:sergey.glukhov@sun.com-20100405111026-7kz1p8qlzglqgfmu) (version source revid:svoj@sun.com-20100401151005-c6re90vdvutln15d) (merge vers: 5.1.46) (pib:16)

The fix for this is in the InnoDB Plugin version 1.0.7 which was included with MySQL 5.1.46. Not 4.1.46.

Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Noted in 5.1.46, 5.5.4 changelogs.

The redo scan during InnoDB recovery used excessive CPU. The
efficiency of this scan was improved for InnoDB Plugin.

Paul,

Please adjust to this and add the performance tag:

The redo scan during InnoDB recovery used excessive CPU. The efficiency of this scan was improved for InnoDB Plugin, significantly speeding up crash recovery.

Added tag, revised wording per James' request.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)

Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)