[MDEV-8702] Unexpected Memory Consumption for Bulk Index Creation in InnoDB. Created: 2015-08-30 Updated: 2023-04-12 Resolved: 2023-04-11 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.0.21 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Minor |
| Reporter: | Jean-François Gagné | Assignee: | Jan Lindström (Inactive) |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | upstream-wontfix | ||
| Environment: |
CentOS release 6.6 |
||
| Description |
|
Hi, I am creating a table without indexes and then adding indexes to the table. The table definition is the following:
and the indexes are the following:
When I add the indexes on the table containing 5.000.000 rows with "innodb_sort_buffer_size = 64M", memory consumption raises by 10 GB. According to the documentation, it should only raise by 3x 64 MB plus row pointers. My observations are far from what is described in the documentation. Thanks for looking into that. Best regards, JFG |
| Comments |
| Comment by Jean-François Gagné [ 2015-08-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Corresponding MySQL bug: http://bugs.mysql.com/bug.php?id=78270 From the Suggested fix: From storage/innobase/row/row0merge.cc, it looks like the scanning of the table allocates RAM to store the index data prior to sorting, not only auxiliary pointers. Once enough data is gathered, it is sorted and then written to disk via a buffer of innodb_sort_buffer_size. From what I understand of the code, I would expect to consume an additional innodb_sort_buffer_size per created index (an additional 2 GB for 32 indexes), but I observe much more (10 GB). The delta might be in InnoDB memory management structures (heap), but the full details escape me. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jean-François Gagné [ 2015-08-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some more details in the following: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-08-31 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Strangely, even though in a comment to the blogpost Marko Mäkelä said that the problem was partially fixed in 5.7 (and a part of that part was fixed in an early version of 5.7), I still observe it on 5.7.8. Of course, maybe it consumes somewhat less memory or does it slower, but it's not enough to preserve my instance from OOM. I don't know if it's any helpful, but here is some info from 5.7 (it has some new memory-related capabilities). The same ALTER was performed on the same table, only with ~2.5M rows instead of 5M (to avoid OOM).
(Truncate does not work on this, so I provide 'before' and 'after' to see what relates to the ALTER). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jean-François Gagné [ 2015-08-31 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Elena, I think Marko's comment was about the following bug: https://bugs.mysql.com/bug.php?id=78262 JFG | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jan Lindström [ 2023-04-11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
10.1 is EOL. |