時折UPDATE/INSERTに数秒かかる

Question

私のサーバ上で本当に簡単なINSERT/UPDATESに問題があります。時々、このもののようなクエリを完了するまでに数秒以上かかる：

2.1062s - INSERT INTO `transaction` SET `idUser` = 72, `currency` = 50, `amount` = '10', `action` = 'buyCoins'; 
11.785s - UPDATE `user` SET `cash` = 10, `crystal` = 10, `expPoints` = 10, `energy` = 10 WHERE idUser = 72; 
0.6296s - UPDATE `user` SET `lastEnergyUpdate` = CURRENT_TIMESTAMP WHERE idUser = 72; 

問題が特定のテーブルに依存していないように見えます。私はこれらのテーブルにTRIGGERSを持っていません。

表の定義：同じサーバー上に

CREATE TABLE `user` (
`idUser` int(10) unsigned NOT NULL AUTO_INCREMENT, 
`expPoints` int(10) NOT NULL DEFAULT '0', 
`cash` int(10) NOT NULL DEFAULT '1000', 
`crystal` int(10) NOT NULL DEFAULT '10', 
`energy` int(4) NOT NULL DEFAULT '0', 
`name` varchar(50) DEFAULT NULL, 
`surname` varchar(50) DEFAULT NULL, 
`age` int(4) unsigned DEFAULT NULL, 
`sex` enum('men','women','unknown') DEFAULT NULL, 
`lastEnergyUpdate` timestamp NULL DEFAULT NULL, 
`lastLogin` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
`insertDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
PRIMARY KEY (`idUser`), 
UNIQUE KEY `serviceUnique` (`serviceName`,`serviceId`) 
) ENGINE=InnoDB AUTO_INCREMENT=5333 DEFAULT CHARSET=utf8 

CREATE TABLE `transaction` (
    `idTransaction` int(10) NOT NULL AUTO_INCREMENT, 
    `idUser` int(10) unsigned NOT NULL, 
    `currency` enum('crystal','partnerCurrency','cash') DEFAULT NULL, 
    `amount` int(5) NOT NULL, 
    `action` enum('unlockPlace','buyExtra','collectReleased') NOT NULL, 
    `insertDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    PRIMARY KEY (`idTransaction`), 
    KEY `fk_transaction_user1` (`idUser`), 
    CONSTRAINT `fk_transaction_user1` FOREIGN KEY (`idUser`) REFERENCES `user` (`idUser`) ON DELETE CASCADE ON UPDATE CASCADE 
) ENGINE=InnoDB AUTO_INCREMENT=156329 DEFAULT CHARSET=utf8 

私はそれ以上のデータベース（〜100）が、大きな何を持っています。すべてのデータベースのダンプは約300MBです。

Mysqltunner出力：もちろん

>> MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net> 
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ 
>> Run with '--help' for additional options and output filtering 

-------- General Statistics -------------------------------------------------- 
[--] Skipped version check for MySQLTuner script 
[OK] Currently running supported MySQL version 5.1.66-0ubuntu0.11.10.2-log 
[OK] Operating on 64-bit architecture 

-------- Storage Engine Statistics ------------------------------------------- 
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 138M (Tables: 267) 
[--] Data in InnoDB tables: 170M (Tables: 327) 
[--] Data in MEMORY tables: 0B (Tables: 1) 
[!!] Total fragmented tables: 329 

-------- Performance Metrics ------------------------------------------------- 
[--] Up for: 20h 45m 57s (558K q [7.468 qps], 58K conn, TX: 685M, RX: 98M) 
[--] Reads/Writes: 66%/34% 
[--] Total buffers: 1.1G global + 6.0M per thread (150 max threads) 
[OK] Maximum possible memory usage: 2.0G (12% of installed RAM) 
[OK] Slow queries: 0% (54/558K) 
[OK] Highest usage of available connections: 6% (10/150) 
[OK] Key buffer size/total MyISAM indexes: 16.0M/8.8M 
[OK] Key buffer hit rate: 99.9% (245K cached/258 reads) 
[OK] Query cache efficiency: 51.5% (176K cached/342K selects) 
[OK] Query cache prunes per day: 0 
[OK] Sorts requiring temporary tables: 6% (1K temp sorts/19K sorts) 
[!!] Temporary tables created on disk: 34% (2K on disk/8K total) 
[OK] Thread cache hit rate: 99% (10 created/58K connections) 
[!!] Table cache hit rate: 16% (786 open/4K opened) 
[OK] Open file limit used: 32% (714/2K) 
[OK] Table locks acquired immediately: 99% (329K immediate/329K locks) 
[OK] InnoDB data size/buffer pool: 170.3M/512.0M 

-------- Recommendations ----------------------------------------------------- 
General recommendations: 
    Run OPTIMIZE TABLE to defragment tables for better performance 
    MySQL started within last 24 hours - recommendations may be inaccurate 
    Temporary table size is already large - reduce result set size 
    Reduce your SELECT DISTINCT queries without LIMIT clauses 
    Increase table_cache gradually to avoid file descriptor limits 
Variables to adjust: 
    table_cache (> 1024) 

その〜1％（99％は正常に動作します）照会のみのために起こり、その後、HDDは本当にビュセ（13％である - 8つのコアサーバ上で20％のWA ）

table_cacheを増やすべきですか？何が起こっている他のアイデア？どうすれば改善できますか？

My MySQL Serverは5.1.66です。私は5.5.xにアップグレードしようとしましたが、それは役に立たなかったので、私はそれを元に戻します。もちろん

Answer 1

その〜1％（99％は正常に動作します）照会のみのために起こり、その後、HDDが本当にブュッシーである（13％ - 20％が8つのコアサーバ上にあった）

1. あなたのディスクに問題があります - これはあなたのinnodbログがディスクにフラッシュされている間に起こると思います - 私は小さなフラッシュ（より頻繁にフラッシュ）とより大きいログサイズ（フラッシュ回数が少ない）の両方で実験します - より頻繁なフラッシュから。

2. あなたがIOを実行しているものは何ですか？アイトップは、この時間中に犯人を捕まえることができます。

3. 可能であれば、tmp、data、およびlogパーティションが物理的に分離されていることを確認してください。