Bug #68276 Heavy write IO when schema is refreshed.

• Submitted: 5 Feb 2013 15:18
• Modified: 5 Nov 2013 20:26
• Reporter: Richard Ayotte
• Status: Closed
• Category: MySQL Workbench
• Severity: S5 (Performance)
• Version: 5.2.46, 6.0.5
• OS: Linux (Ubuntu 64bit)
• CPU Architecture: Any

[5 Feb 2013 15:18] Richard Ayotte

Description:
There's some heavy drive thrashing that lasts 25 to 30 seconds when MySQL Workbench starts. The thrashing isn't on the same drive as the database, it's in the home directory and according to iotop, it's all write access. I would guess that it is writing about 15MB of data somewhere in my home directory.

How to repeat:
Start MySQL Workbench

or 

From the SQL Editor, right click on a schema and select Refresh All.

[11 Feb 2013 17:38] Richard Ayotte

Attached is an strace and a few interesting things happened.

Steps taken:
1. strace -ff -o mysql-workbench-process mysql-workbench 
2. Double click on Cheetah database connection
3. Click the + tree expansion of officemovepro_dev schema
4. Exit

$ grep write mysql-workbench-process.23171|wc -l
5766

5766 write calls in process 23171 seems a little high. I'm not sure what's being written.

$ grep read mysql-workbench-process.23183|wc -l
145375
Again 145375 read calls seems very high as well for the steps that I took.

[15 Feb 2013 12:44] Richard Ayotte

To test my theory that the cache was the problem, I created a link to the shared memory.

mkdir /run/shm/rich-workbench-cache
ln -s /run/shm/rich-workbench-cache/ ~/.mysql/workbench/cache

Wow! What a difference. Workbench is running amazingly fast with hardly any disk activity at all. As an added bonus, it doesn't crash on exit with this setup. The crash on exit was another bug that I was going to report.

Even without the persistent cache, this setup is way faster. There's something really wrong with the cache.

[25 Mar 2013 17:52] Armando Lopez Valencia

Hello Richard.
Can you please attach the Cache file?
This is interesting for our dev team due that this file only contains schema object and column names.
Thanks.

[13 Apr 2013 5:00] Richard Ayotte

Sample Cache

Attachment: Cheetah.cache (chemical/x-cache, text), 51.00 KiB.

[13 Apr 2013 5:00] Richard Ayotte

Sample Cache

Attachment: OfficeMovePro_VPS.cache (chemical/x-cache, text), 68.00 KiB.

[13 Apr 2013 5:00] Richard Ayotte

Sample Cache

Attachment: Polarbear.cache (chemical/x-cache, text), 196.00 KiB.

[13 Apr 2013 5:08] Richard Ayotte

The crash on exit still occurs, I spoke too fast. Also, I for some reason didn't get a notification when you added a comment otherwise, I would have submitted the files much sooner.

[5 Aug 2013 13:51] MySQL Verification Team

Please try version 5.0.5. Thanks.

[7 Aug 2013 11:51] Richard Ayotte

Problem persists in 6.0.5.

[7 Aug 2013 17:07] Marcin Szalowicz

Thank you for the bug report.

[10 Sep 2013 20:20] Vasileios Lourdas

Version 5.2.47 is also affected. Symlinking ~/.mysql/workbench/cache to a tmpfs mount point is a temporary hack until a proper fix is applied.

[30 Oct 2013 16:01] Armando Lopez Valencia

Posted by developer:
 
Verified in:
MySQL Server 5.6
WB 6.0.8.11345
Code change verified.

[5 Nov 2013 20:26] Philip Olson

Fixed as of MySQL Workbench 6.0.8, and here's the changelog entry:

I/O writes were reduced, which was especially a problem visible when
closing MySQL Workbench with tables that had over 500 columns.

Thank you for the bug report.