Make sure your version is late enough to actually use more than 4GB of key_buffer. (key_buffer = 10240M):
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_key_buffer_size
As of MySQL 5.0.52 and 5.1.23, values larger than 4GB are permitted for 64-bit platforms.
table_cache = 2500
Large values of this can be sluggish (until the hashing code is pushed).
It is questionable whether the Query cache is helping or hurting:
| Qcache_hits | 75868572 |
| Qcache_inserts | 104791726 |
That's a low hit rate.
| Slow_queries | 5386 |
Run mydumpslow to see what is sluggish. It might give clues into what is impacting performance.
| Threads_running | 119 |
That's a lot.
How many cores in the old machine? In the new? Because of lock contention for the key_buffer and the Query Cache, more cores --> slower performance (after 4-8 cores, depending on benchmark).
Good key_buffer caching:
| Key_read_requests | 3372652073 |
| Key_reads | 11698294 |
No InnoDB?
Any network differences? Or are you always on the same machine?
16x internal 15k RPM drives -- same RAID controller?
HyperThreading is bad.
NUMA can (perhaps) lead to swapping, which is very bad.
8K qps is very good.