CẬP NHẬT/INSERT theo thời gian chỉ mất vài giây

Question

Tôi gặp sự cố với INSERT/UPDATES thực sự đơn giản trên máy chủ của mình. Đôi khi phải mất hơn một vài giây để hoàn tất truy vấn như thế này:

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; 

Có vẻ như vấn đề không phụ thuộc vào bảng cụ thể. Tôi không có TRIGGERS trên những bảng đó.

định nghĩa Bảng:

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 

On cùng một máy chủ tôi có nhiều cơ sở dữ liệu (~ 100) nhưng không lớn. Dump của tất cả các cơ sở dữ liệu là khoảng 300MB.

đầu ra

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) 

Tất nhiên nó chỉ xảy ra cho ~ 1% so với truy vấn (99% hoạt động tốt), và sau đó HDD thực sự là Bussy (13% - 20% wa vào ngày 8 lõi máy chủ)

Tôi có nên tiếp tục tăng table_cache không? Bất kỳ ý tưởng khác những gì đang xảy ra? Làm thế nào tôi có thể cải thiện nó?

Máy chủ MySQL của tôi là 5.1,66. Tôi đã cố gắng nâng cấp lên 5.5.x nhưng điều đó không giúp tôi, vì vậy tôi hạ cấp nó xuống.

Answer 1

Tất nhiên nó chỉ xảy ra cho ~ 1% so với truy vấn (99% hoạt động tốt), và sau đó HDD thực sự là Bussy (13% - 20% là trên 8 lõi máy chủ)

1. Bạn đang gặp vấn đề với đĩa của mình - tôi đặt cược điều này xảy ra trong khi nhật ký innodb của bạn đang chuyển sang đĩa - tôi sẽ thử nghiệm với cả hai nhỏ hơn (để bung thường xuyên hơn) và kích thước nhật ký lớn hơn (để giảm bớt thường xuyên) - Tôi mong bạn sẽ nhận được nhiều hơn từ tuôn ra thường xuyên hơn.

2. Điều khác để xem là những gì đang ăn IO của bạn - chạy iotop trong thời gian này nếu bạn có thể nắm bắt được thủ phạm.

3. Nếu không, hãy đảm bảo phân vùng tmp, dữ liệu và nhật ký của bạn tách biệt về mặt vật lý nếu có thể.