लगभग सभी उत्पादन सर्वरों में, क्वेरी कैश को बंद करना बुद्धिमानी है। हर तालिका में संशोधन के कारण सभी . का शुद्धिकरण होता है उस तालिका के लिए QC प्रविष्टियाँ। तालिका जितनी बड़ी होगी, उतना ही अधिक समय लगेगा। 128M खतरनाक रूप से उच्च है।
आम तौर पर, innodb_buffer_pool_size . सेट करना बुद्धिमानी है उपलब्ध . में से लगभग 70% तक टक्कर मारना। आपने इसे बहुत कम मान पर सेट किया है, यहां तक कि डेटासेट आकार से भी कम। 3जी शायद मदद करेगा। 20G अब और मदद नहीं करेगा (जब तक कि आपका डेटासेट महत्वपूर्ण रूप से नहीं बढ़ता)।
सुनिश्चित करें कि OS और MySQL दोनों ही 64-बिट संस्करण हैं।
अधिक गहन विश्लेषण के लिए, प्रदान करें
- रैम आकार (32जी)
SHOW VARIABLES;SHOW GLOBAL STATUS;(कम से कम 24 घंटे चलने के बाद)
विश्लेषण चर और स्थिति की:
अधिक महत्वपूर्ण मुद्दे
चूंकि आप केवल (?) InnoDB और केवल 2GB डेटा का उपयोग कर रहे हैं, इसलिए innodb_buffer_pool_size के बारे में टिप्पणियों का जवाब देना महत्वपूर्ण नहीं है। और key_buffer_size
DELETE . के अपने भारी उपयोग के बारे में कुछ और विवरण प्रदान करें ।
'सबसे खराब' प्रश्नों को खोजने के लिए स्लोलॉग का उपयोग करें। अधिक विवरण यहां . इससे नीचे उल्लिखित tmp_table और तालिका स्कैन समस्याओं की पहचान होनी चाहिए।
OPTIMIZE TABLE . का उपयोग करके परेशान न हों ।
आप "लेनदेन" कैसे कर रहे हैं? कभी ऑटोकॉमिट के साथ, कभी COMMIT . के साथ ?
विवरण और अन्य अवलोकन
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- उपयोग किए गए key_buffer का प्रतिशत। उच्च-जल-चिह्न।-- अनावश्यक स्मृति उपयोग से बचने के लिए key_buffer_size कम करें।
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% - % RAM का उपयोग InnoDB बफर_पूल के लिए किया जाता है
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- अधिकांश उपलब्ध रैम को कैशिंग के लिए उपलब्ध कराया जाना चाहिए।-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% - बफर पूल फ्री-- बफर_पूल_साइज वर्किंग सेट से बड़ा है; इसे कम कर सकता है
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- डिस्क को हिट करने के लिए अनुरोध लिखें-- चेक innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- डेटा द्वारा लिए गए बफर पूल का प्रतिशत-- एक छोटा प्रतिशत हो सकता है इंगित करें कि बफ़र_पूल अनावश्यक रूप से बड़ा है।
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 - InnoDB लॉग रोटेशन के बीच मिनट 5.6.8 से शुरू होकर, इसे गतिशील रूप से बदला जा सकता है; my.cnf.-- को भी बदलना सुनिश्चित करें। (घूर्णन के बीच 60 मिनट की सिफारिश कुछ हद तक मनमानी है।) innodb_log_file_size समायोजित करें। (एडब्ल्यूएस में नहीं बदल सकता।)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 - मंथन-- "इसे कतार में मत लगाओ, बस करो।" (यदि MySQL का उपयोग कतार के रूप में किया जा रहा है।)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- अस्थायी तालिकाओं का प्रतिशत जो डिस्क पर फैल गया-- शायद tmp_table_size और max_heap_table_size बढ़ाएँ; बूँद आदि से बचें।
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- पूर्ण तालिका स्कैन-- अनुक्रमणिका जोड़ें / क्वेरी अनुकूलित करें (जब तक कि वे छोटी तालिकाएं न हों)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% - पूर्ण तालिका स्कैन करने वाले चयनों का%। (संग्रहीत रूटीन द्वारा मूर्ख बनाया जा सकता है।)-- अनुक्रमणिका जोड़ें / प्रश्नों को अनुकूलित करें
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- ऑप्टिमाइज़ टेबल कितनी बार किया जाता है।-- ऑप्टिमाइज़ टेबल शायद ही कभी उपयोगी होता है, निश्चित रूप से उच्च आवृत्ति पर नहीं।
( long_query_time ) = 10.000000 = 10 -- "धीमी" क्वेरी को परिभाषित करने के लिए कटऑफ (सेकंड)।-- सुझाव 2
चरम (टिप्पणी के बिना):
असामान्य रूप से छोटा:
Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360
असामान्य रूप से बड़ा:
Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8 (This may be unused? It was removed in 5.6.3, but possibly left in MariaDB 10.1?)
असामान्य तार:
Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off
क्वेरी कैश
चूंकि इसे बंद कर दिया गया था, कोई भी Qcache स्थिति मान सेट नहीं किया गया था। इसलिए मैं मूल प्रश्न का समाधान नहीं कर सकता। यदि आप QC चालू करना चाहते हैं और सर्वर को पुनरारंभ करना चाहते हैं और कुछ दिन प्रतीक्षा करना चाहते हैं, तो मैं इसके साथ फिर से विश्लेषण कर सकता हूं। हिट, प्रून आदि के बारे में विभिन्न मीट्रिक मई मूल प्रश्न को संबोधित करें।
