更新/插入時不時需要幾秒鐘

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嗎？任何其他想法發生了什麼？我該如何改進它？

我的MySQL服務器是5.1.66。我試圖升級到5.5.x，但這並沒有幫助我，所以我將它降級。

Answer 1

當然這只是爲了那個〜1％的情況查詢（99％正常工作），然後HDD真的布西（13％ - 20％是在8個核服務器）

1. 你的磁盤出現問題 - 我敢打賭，這是在你的innodb日誌沖洗到磁盤時發生的 - 我會嘗試使用更小的（更頻繁地用於沖洗）和更大的日誌大小（用於不太頻繁的沖洗） - 我希望你獲得更多從更頻繁的沖洗。

2. 另一件需要注意的就是在這段時間裏吃什麼東西 - 運行iotop，如果你能抓住罪魁禍首。

3. 否則，請確保您的tmp，數據和日誌分區在物理上是分開的，如果可以的話。