सवाल MySQL (InnoDB) के लिए सबसे अच्छा लिनक्स फाइल सिस्टम क्या है?


मैंने MySQL InnoDB के साथ विभिन्न फाइल सिस्टम के प्रदर्शन पर बेंचमार्क देखने की कोशिश की लेकिन कोई भी नहीं मिला।

मेरा डेटाबेस वर्कलोड ठेठ वेब-आधारित OLTP है, लगभग 9 0% पढ़ा गया है, 10% लिखना है। यादृच्छिक आईओ।

लोकप्रिय फाइल सिस्टम जैसे ext3, ext4, xfs, jfs, Reiserfs, Reiser4, आदि में से एक जो आपको लगता है कि MySQL के लिए सबसे अच्छा है?


47
2018-06-20 19:06


मूल




जवाब:


आप डेटा को कितना महत्व देते हैं?

गंभीरता से, प्रत्येक फाइल सिस्टम का अपना ट्रेडऑफ होता है। इससे पहले कि मैं आगे जाऊं, मैं एक्सएफएस और रीज़र दोनों का बड़ा प्रशंसक हूं, हालांकि मैं अक्सर Ext3 चलाता हूं। तो यहां काम पर वास्तविक फाइल सिस्टम पूर्वाग्रह नहीं है, बस आपको बता रहा है ...

यदि फाइल सिस्टम आपके लिए एक कंटेनर से थोड़ा अधिक है, तो जो भी आपको सर्वोत्तम पहुंच के समय प्रदान करता है उसके साथ जाएं।

यदि डेटा किसी भी महत्वपूर्ण मूल्य का है, तो आप एक्सएफएस से बचना चाहेंगे। क्यूं कर? क्योंकि अगर यह जर्नल की गई फ़ाइल के एक हिस्से को पुनर्प्राप्त नहीं कर सकता है यह ब्लॉक को शून्य कर देगा और डेटा को पुनर्प्राप्त करने योग्य बनाओ। यह मुद्दा है लिनक्स कर्नेल 2.6.22 में तय किया गया

ReiserFS एक महान फाइल सिस्टम है, बशर्ते कि यह कभी कड़ी मेहनत नहीं करता है। जर्नल रिकवरी ठीक काम करती है, लेकिन अगर किसी कारण से आप अपनी विरोधाभास जानकारी खो देते हैं, या फाइल सिस्टम के मूल ब्लॉक उड़ा दिए जाते हैं, तो डिस्क पर एकाधिक रेइज़रफ़ेस विभाजन होने पर आपके पास एक कंड्री हो सकती है - क्योंकि रिकवरी तंत्र मूल रूप से पूरे डिस्क को क्षेत्र से क्षेत्र में स्कैन करता है, जो कि "सोचता है" फाइल सिस्टम की शुरुआत है। यदि आपके पास रीइज़रएफएस के साथ तीन विभाजन हैं लेकिन केवल एक उड़ाया गया है, तो आप कल्पना कर सकते हैं कि अराजकता का कारण यह होगा क्योंकि पुनर्प्राप्ति प्रक्रिया अन्य दो प्रणालियों से फ्रेंकस्टीन गड़बड़ी को एक साथ जोड़ती है ...

Ext3 "धीमा" है, "मेरे पास 32,000 फाइलें हैं और उन्हें सभी चलने में समय लगता है ls"थोड़े तरीके से। यदि आपके पास हर जगह हजारों छोटी अस्थायी तालिकाओं की जा रही है, तो आपको बहुत दुख होगा। नए संस्करणों में अब एक इंडेक्स विकल्प शामिल है जो नाटकीय रूप से निर्देशिका ट्रैवर्सल को घटा देता है लेकिन यह अभी भी दर्दनाक हो सकता है।

मैंने कभी जेएफएस का उपयोग नहीं किया है। मैं केवल टिप्पणी कर सकता हूं कि मैंने कभी भी जो भी समीक्षा की है, वह "ठोस, लेकिन ब्लॉक पर सबसे तेज़ बच्चा नहीं" की तरह कुछ है। यह जांच योग्यता हो सकती है।

विपक्ष के पर्याप्त, आइए पेशेवरों को देखें:

XFS:

  • भारी फाइलों, तेजी से वसूली का समय के साथ चिल्लाती है
  • बहुत तेज निर्देशिका खोज
  • डंपिंग के लिए फाइल सिस्टम को ठंडा करने और मुक्त करने के लिए Primitives

ReiserFS:

  • बेहद इष्टतम छोटी फ़ाइल का उपयोग
  • फाइल सिस्टम स्पेस को संरक्षित करने, एक ही ब्लॉक में कई छोटी फाइलों को पैक करता है
  • तेजी से वसूली, प्रतिद्वंद्वियों XFS वसूली के समय

ext3:

  • अच्छी तरह से परीक्षण किए गए Ext2 कोड के आधार पर कोशिश की और सही
  • इसके साथ काम करने के लिए आसपास के कई सारे उपकरण
  • वसूली के लिए चुटकी में Ext2 के रूप में फिर से घुड़सवार किया जा सकता है
  • दोनों हो सकते हैं सिकुड़ और विस्तारित (अन्य फाइल सिस्टम केवल विस्तारित किया जा सकता है)
  • नवीनतम संस्करणों को "लाइव" का विस्तार किया जा सकता है (यदि आप साहसी हैं)

तो आप देखते हैं, प्रत्येक के अपने स्वयं के quirks है। सवाल यह है कि, आपके लिए कम से कम quirky कौन सा है?


43
2018-06-22 05:54



XFS NULLed फ़ाइलों का मुद्दा 3 साल पहले तय किया गया था। xfs.org/index.php/... - EvilRyry
हालांकि यह सच है कि मेरे पास कर्नेल विकास में बदलाव (काम और परिवार के शीर्ष पर) रखने के लिए दुनिया में हर समय नहीं है, यह भी निश्चित रूप से सच है कि वहाँ क्रैक पुराने पुराने तैनाती हैं जिन्हें अपडेट करने की आवश्यकता है। हालांकि, मैं फिक्स किए गए इंगित करने के लिए +1 में चिप करूंगा। - Avery Payne


यह ध्यान देने योग्य भी हो सकता है कि आप फाइल सिस्टम के बिना इनो डीबी चला सकते हैं और फाइल सिस्टम ओवरहेड के बिना प्रदर्शन में सुधार कर सकते हैं। मुझे यकीन नहीं है कि मैं इसकी अनुशंसा करता हूं, लेकिन मैंने इसे बिना किसी समस्या के पहले इस्तेमाल किया है।

InnoDB कच्चे डिवाइस

इसके अतिरिक्त, यदि आप 90% पढ़ते हैं और 10% लिखते हैं, जब तक आपको इनो डीबी की लेनदेन क्षमता की आवश्यकता नहीं होती है, तो आप बेहतर पढ़ने के प्रदर्शन के लिए माईसाम को पोर्टिंग में देख सकते हैं।


12
2017-10-06 17:53



-1 बेहतर पढ़ने के प्रदर्शन के लिए MyISAM में जाने का सुझाव देने के लिए। इतनी सारी त्रुटियां और डाउनसाइड्स हैं। InnoDB को ठीक से कॉन्फ़िगर किया जाना चाहिए। InnoDB-on-raw-device सुझाव के लिए +1। - gertvdijk
मैं अपने बयान से खड़ा हूं, माईसाम की कमी है लेकिन वहां बहुत अच्छा है। MyISAM अभी भी वर्कलोड पढ़ने के लिए मालिक है। - Xorlev


यहां दिए गए उत्तरों को गंभीरता से बहिष्कृत किया गया है, और इसे अपडेट करने की आवश्यकता है क्योंकि यह Google परिणामों में आ रहा है।

उत्पाद वातावरण के लिए, एक्सएफएस। हर बार। एक्सएफएस जर्नल और गैर-अवरुद्ध है। सुनिश्चित करें कि आपके पास उत्पादन में InnoDB का उपयोग कर आधुनिक (2011/2012) MySQL डेटाबेस के लिए निम्न चर हैं:

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

EXT3 या यहां तक ​​कि EXT4 का उपयोग न करें। एक दिन बीटीआरएफएस वहां पहुंच जाएगा।

EXT3, और शायद EXT4, इनोड स्तर पर ताले, स्मार्ट नहीं!

सूत्रों का कहना है:  - www.mysqlperformanceblog.com  - http://dev.mysql.com/doc/internals/en/index.html  - साशा पाचेव द्वारा MySQL आंतरिक को समझना  - https://www.facebook.com/note.php?note_id=10150210901610933  - http://oss.sgi.com/projects/xfs/training/  - कुछ स्विंग किट, परीक्षण और त्रुटि।

संपादित करें: एक अद्यतन। लगता है कि मध्य 2013 के रूप में EXT4 बहुत अच्छी तरह से कर रहा है! बीटीआरएफएस अभी भी एक अच्छा विकल्प नहीं है। और आरएचईएल एक्सएफएस को नई डिफ़ॉल्ट फाइल सिस्टम अच्छी तरह से कर सकता है। फिर, EXT3 का उपयोग न करें।


10
2017-12-12 08:56



इसके अनुसार Vadim Tkachenko परीक्षण, EXT4 XFS पर 20% थ्रूपुट प्रदान करता है यदि MyoDB के साथ MySQL 5.5 का उपयोग किया जाता है। वादिम 'dioread_nolock' EXT4 विकल्प का उपयोग करने का सुझाव देता है जहां उपलब्ध है (हालांकि उसने परीक्षण के साथ इसका उपयोग नहीं किया था)। - caligari
इनोड स्तर पर लॉकिंग क्यों खराब है? - jpaugh
अन्य उत्तरों पुराने हैं ... अब, 5 साल बाद ... - kaiser
इनोड लॉकिंग की समस्याओं के लिए Google "इनोड लॉक विवाद"। - stark


लघु संस्करण यह है कि मैंने सिफारिश की है कि मैंने माइस्क्लुएल को फाइल सिस्टम पर बना दिया है, एक्सएफएस है, हालांकि ext3 ठीक भी होना चाहिए, ext4 एक अच्छा सुधार होने का वादा करता है, लेकिन यह अभी भी काफी स्थिर नहीं है, हालांकि यह पहले होना चाहिए साल का अंत।

यदि आप क्लस्टर फाइल सिस्टम चला रहे हैं तो सीएक्सएफएस, ओसीएफएस 2 और जीएफएस सभी ठीक होना चाहिए।

मैं दृढ़ता से किसी भी रेज़र डेरिवेटिव्स और जेएफएस के खिलाफ चेतावनी दूंगा हालांकि एक बार अच्छा एक्सएफएस और एक्सटी 4 द्वारा पीटा गया है जो दोनों व्यापक रूप से तैनात किए जाते हैं।


8
2018-06-21 10:35





इसमें बहुत अंतर नहीं होने की संभावना है। जो भी वितरण आपके डिफ़ॉल्ट के रूप में उपयोग करता है, उसके साथ जाएं, बशर्ते यह पर्याप्त हो।

अन्य प्रयासों को ट्यून करने के अपने प्रयास को खर्च करें - पर्याप्त रैम प्राप्त करें - एक RAID नियंत्रक प्राप्त करें जो चूसता नहीं है - और डेटाबेस के अनुप्रयोग के लंगड़ा (एबी) उपयोग को ठीक करें (एनबी: यह ज्यादातर मामलों में मुख्य अपराधी है जहां यह पहले से नहीं है किया गया)।

हालांकि, ध्यान से, फाइल सिस्टम जो आपने अपना mysql tmpdir डाल दिया है पर विचार करें; यह प्रदर्शन को प्रभावित करेगा, विशेष रूप से क्वेरी जो डिस्क-आधारित filesort () एस (अधिक जानकारी के लिए EXPLAIN देखें)।

मुझे लगता है कि एक फाइल सिस्टम जो देरी आवंटन का समर्थन करता है, वास्तव में यहां आसान है, क्योंकि आप कैश में रखने के लिए पर्याप्त RAM होने पर आईओ पूरी तरह से अल्पकालिक फाइलों से बच सकते हैं। उदाहरण के लिए, एक्सएफएस, उन सभी फ़ाइलों को लिखने से परेशान नहीं करता है जिन्हें आवंटित किए जाने से पहले हटा दिया जाता है और बंद कर दिया जाता है।

निश्चित रूप से एक tmpfs पर एक tmpdir डालने एक प्रदर्शन परिप्रेक्ष्य से आकर्षक है, लेकिन अंतरिक्ष को समाप्त करने और अन्यथा सफल होने के बावजूद पूछताछ करने का जोखिम होता है (हालांकि डिस्क अस्थायी फ़ाइलों के साथ) असफल हो जाता है।


6
2018-06-21 11:09





मुझे विभिन्न फाइल सिस्टम पर चल रहे MySQL पर बेंचमार्क "राउंडअप" के साथ कोई हालिया लेख नहीं मिल रहा है। आपके द्वारा वर्णित वर्कलोड को देखते हुए, मुझे संदेह है कि फ़ाइल-स्तरीय विखंडन एक मुद्दा होने वाला है। एक औपचारिक बेंचमार्क के बिना, मैं कुछ भी नहीं कह सकता जिसे आपको आधिकारिक के रूप में लेना चाहिए, लेकिन मेरा आंत कहता है कि ऊपर वर्णित हर फाइल सिस्टम लगभग उसी बॉलपार्क में प्रदर्शन करने जा रहा है (यानी सभी प्रदर्शन संख्याओं के लिए परिमाण के समान क्रम में) ।

डेटाबेस वास्तव में शो चला रहा है, क्योंकि फाइल सिस्टम केवल बड़े एक्सेंट्स का प्रबंधन कर रहा है जो स्टोरेज इंजन एक्सेस कर रहा है।

फिर भी, उन सभी फाइल सिस्टम के साथ प्रदर्शन राउंडअप करना दिलचस्प होगा। (मेरे पास MySQL के लिए कोई उत्साह नहीं है, हालांकि, मैं इसे करने वाला नहीं हूं। बेंचमार्किंग पोस्टग्रेस, ओटीओएच, दिलचस्प हो सकता है ...)


4
2018-06-20 19:26



आप भी एक है stackoverflow.com/questions/1021854/... कुछ संदर्भों के साथ डुप्लिकेट करें जो आपको रूचि दे सकते हैं - nik


आईएमएचओ लिनक्स के लिए उपलब्ध एफएस नोटिंग के लायक हैं:

एक्सएफएस (खराब पढ़ने की गति) सिस्टम संसाधनों पर प्रकाश और बड़ी फ़ाइलों के साथ तेज़ होने के लिए जाना जाता है लेकिन बहुत छोटी फाइलों को संभालने के लिए गरीब।

ReiserFS (खराब लेखन गति) सिस्टम संसाधनों पर बहुत दयालु नहीं है लेकिन बहुत सी छोटी फाइलों के साथ बहुत अच्छा प्रदर्शन करता है।

EXT3 सभी क्षेत्रों में स्वीकार्य प्रदर्शन करने के बीच में पड़ता है (इसका कारण यह माना जाता है चूक लिनक्स एफएस)।

मैंने अभी तक EXT4 को ReiserFS4 नहीं उपयोग किया है, लेकिन मैंने कुछ मानकों को देखा है और रीडरफ़ेस में पढ़ने की गति आने पर सबसे अच्छा प्रदर्शन होता है, जो आपने कहा था कि आपके लिए सबसे महत्वपूर्ण था।

इस पर एक नजर डालिए : ReserFS4 एक्स Ext4 एक्स Ext3

मैं अपनी स्थिरता, सुरक्षा और परिपक्वता के लिए Ext3 की अनुशंसा करता हूं, लेकिन अगर पढ़ने की गति आपके लिए सबसे महत्वपूर्ण है, तो आपको ReiserFS पर विचार करना चाहिए।

याद रखें कि आपको एफएस चुनने से पहले सीपीयू उपयोग, स्थिरता, सुरक्षा पर भी विचार करना चाहिए।

और निश्चित रूप से एक पायलट बनाने, अपने विशेष पर्यावरण पर परीक्षण और बेंचमार्किंग हमेशा यह बताने का सबसे अच्छा तरीका है कि आपके लिए सबसे अच्छा क्या काम करेगा।

पीएस: मैंने और अधिक बेंचमार्क पोस्ट किए होंगे लेकिन मैं एक से अधिक लिंक पोस्ट नहीं कर सकता।


2
2018-06-21 19:47