Bug #98739 | TempTable storage engine slow if mmap is required | ||
---|---|---|---|
Submitted: | 25 Feb 2020 18:27 | Modified: | 11 Jun 2020 17:21 |
Reporter: | Marcelo Altmann | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Storage Engines | Severity: | S3 (Non-critical) |
Version: | 8.0.19 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[25 Feb 2020 18:27]
Marcelo Altmann
[25 Feb 2020 21:52]
MySQL Verification Team
Thank you for the bug report.
[2 Mar 2020 23:11]
Marcelo Altmann
Just did some further testing and something seems a bit broken with TempTable SE: For the above reproducible test case, I ran it with strace attached to it: Command: strace -f -s8192 -ttt -p $(pidof mysqld) -e trace=recvfrom,open,mmap,close -o/tmp/temptable.trace for each allocation, mysql does creates the file with: open("/var/lib/mytmp/", O_RDWR|O_DIRECTORY|O_CLOEXEC|O_TMPFILE, 0600) = 51 lseek(51, 0, SEEK_END) = 0 Then it writes \n to it (https://github.com/mysql/mysql-server/blob/mysql-8.0.19/storage/temptable/include/temptabl...) in 4k chunk each time , until it reaches 8M write(51, "\n\n\n\n\n\.... Then i mmaps it and close mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_SHARED, 51, 0) = 0x7f58f822b000 close(51) = 0 The above process was repeated 26036 for the union select. Querying performance_schema.memory_summary_global_by_event_name it reports that more than 203G was been allocated in disk, which goes align with the 26036 * 8M mmap calls.
[11 Jun 2020 17:21]
Daniel Price
Fixed as of the upcoming 8.0.21 release, and here's the proposed changelog entry from the documentation team: Use of memory-mapped files after exceeding the temptable_max_ram threshold caused a performance degradation.