Michael

you’re testing this with ext3’s journal data, ordered data or write-back mode? As the default is ordered data and the closest behavior to XFS can be achieved via the write-back mode (which btw will become the default soon).

I should note this does not only applies to MyISAM tables but to Innodb tables in innodb_file_per_table mode as well.

I recently spoke to the customer which simply can’t drop 400G table because it stalls everything for long time.

1) Our database is typically 100% cached (both data and indexes), 16 – 20 GB in a few hundred MyISAM tables (out of 24 GB RAM on the machine). It is 99.9999% reads on a very static but highly random set of data.
2) Most sorts are small or medium sized, we have max_heap_table_size=100M and tmp_table_size=100M in order to do these in memory
3) We have occasional large (2-4 GB +) sorts that we’d like to spill to disk. It’s okay if these are somewhat slow. I/O contention is not an issues since all reads are cached and the few writes we have are not performance critical.

I’m just wondering if in this case this lock will bite us for these large sorts (which afaics, we definitely do need on disk, since our ram is mostly dedicated to caching the db / indexes). I’d go spelunking, but have no experience with the mysql codebase really. Just a concerned user here

Actually typically /tmp is created on the system storage (i.e. local disk) using whatever file system chosen for the installation. To boost some occasional but rather smallish temporary tables some people move it to tmpfs (which I think is unreasonable design, because you would rather want MySQL tmpdir on tmpfs rather than the system-wide /tmp).

Maciek

I haven’t examined the sources for temp tables, so I do not know if they suffer from a similar problem. I suppose since they do not require such locking, because there is no possibility for any concurrent access to them, MySQL may do things differently. However obviously if there is a large temporary table located on ext3 partition, it will cause a lot of random I/O on delete thus affecting the system performance.

Maciek

/dev/vg00/lvtmp /tmp ext3 defaults 1 2

And indeed tmpfs is virtual memory (RAM+SWAP) backed (http://en.wikipedia.org/wiki/TMPFS), however for a dedicated mysql machine that doesn’t make too much sense, since if you had the ram you’d just increase your tmp_table_size etc to use that ram directly i imagine. I don’t mind that these large sorts use disk, but i do mind if it blocks my other select queries for no good reason. As a general rule, locks should absolutely never be held around any I/O operation…

See the mysql Worklog task for this at: forge.mysql.com/worklog/task.php?id=3983

http://en.wikipedia.org/wiki/TMPFS