समय-समय पर अद्यतन/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; 

यह मुद्दा की तरह लग रहा विशिष्ट तालिका के आधार पर नहीं है। मेरे पास उन तालिकाओं पर ट्राइगर्स नहीं हैं।

टेबल परिभाषाएँ:

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), लेकिन बड़ा कुछ भी नहीं है। सभी डेटाबेस का डंप लगभग 300 एमबी है।

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% वा)

क्या मुझे table_cache बढ़ाना जारी रखना चाहिए? कोई अन्य विचार क्या चल रहा है? मैं इसे कैसे सुधार सकता हूँ?

मेरा MySQL सर्वर 5.1.66 है। मैंने 5.5.x पर अपग्रेड करने का प्रयास किया लेकिन इससे मेरी मदद नहीं हुई, इसलिए मैंने इसे वापस डाउनग्रेड कर दिया।

Answer 1

बेशक यह केवल इस बात का ~ 1% के लिए होता है प्रश्नों (99% ठीक काम करता है), और फिर HDD वास्तव में बुस्सी है -

1. (13% 20% 8 कोर सर्वर पर था) आप अपनी डिस्क के साथ एक समस्या का सामना कर रहे हैं - मुझे लगता है कि यह तब होता है जब आपका innodb लॉग डिस्क पर फ़्लश कर रहा है - मैं दोनों छोटे (फ्लश के लिए अधिक बार) के साथ प्रयोग करता हूं और बड़े लॉग आकार (कम लगातार फ्लश के लिए) - मुझे उम्मीद है कि आप और अधिक प्राप्त करेंगे अधिक लगातार flushes से।

2. दूसरी बात यह है कि अगर आप अपराधी को पकड़ सकते हैं तो इस समय के दौरान आपके आईओ-रन आईपोट को खा रहा है।

3. अन्यथा, सुनिश्चित करें कि आपका टीएमपी, डेटा और लॉग विभाजन शारीरिक रूप से अलग हैं यदि आप कर सकते हैं।