उच्च उपयोग के लिए kjournald कारण


15

मैं यह पता लगाने की कोशिश कर रहा हूं कि kjournaldमेरी मशीन पर पागल क्यों हो रहा है। यह मेमोरी के भार के साथ एक 8-कोर बॉक्स है। यह ~ 50% सीपीयू लोड है।

Iotop किसी भी विशिष्ट प्रक्रियाओं को इंगित नहीं करता है - कुछ इधर-उधर लिखने के फटने (ज्यादातर क्रोन शुरू, कुछ निगरानी आँकड़े उत्पन्न, आदि) जब मैं sys/vm/block_dumpलिखने के आँकड़े इकट्ठा करता था, तो मुझे इस तरह की सूची मिली:

kjournald(1352): 1909
sendmail(28934): 13
cron(28910): 12
cron(28912): 11
munin-node(29015): 3
cron(28913): 3
check_asterisk_(28917): 3
sh(28917): 2
munin-node(29022): 2
munin-node(29021): 2

जहां kjournaldक्रियाएं सिर्फ WRITE होती हैं।

ऐसा क्यों हो रहा है? Kjournald गतिविधि को थोड़ा सीमित करने के लिए मुझे और क्या देखना चाहिए? ऐसा लगता है कि वास्तव में जो लिखा जा रहा है, उसके प्रति असंतुष्ट है।


आप किस ओएस का उपयोग कर रहे हैं। क्या आप बिना जानकारी के पोस्ट कर सकते हैं।
सोहम चक्रवर्ती

मुझे ठीक वैसी ही समस्या थी
शेर इयर्स

जवाबों:


15

kjournaldext3 (जर्नलिंग फाइल सिस्टम) की पत्रिका के लिए जिम्मेदार है। यह कुछ विशेष लोड के तहत बहुत सारे सीपीयू का उपयोग करने के लिए जाना जाता है। एक और फाइल सिस्टम का उपयोग करने या जर्नलिंग को अक्षम करने के अलावा बहुत कुछ नहीं है (प्रभावी रूप से एफएस एक्स 2 बना रहा है)।

सैद्धांतिक रूप से आप ext3 जर्नलिंग के अन्य तरीकों में से एक का उपयोग कर सकते हैं और जांच सकते हैं कि क्या सीपीयू का उपयोग कम हो गया है, लेकिन याद रखें कि प्रत्येक विधि डिस्क पर लिखे जा रहे डेटा की सुरक्षा पर एक समझौता है। आपने मोड, राइटबैक मोड और 'सब कुछ' मोड का आदेश दिया है।

  1. आदेश दिया गया: जर्नल केवल मेटाडेटा, लेकिन यह आश्वासन देता है कि मेटाडेटा से संबंधित डेटा जर्नल में मेटाडेटा परिवर्तन करने से पहले सहेजा जाता है।
  2. राइटबैक: जर्नल केवल मेटाडेटा, लेकिन इस बात की कोई गारंटी नहीं है कि डेटा जर्नल कमिट करने से पहले सहेजा जाता है।
  3. जर्नल: सब कुछ जर्नल, डेटा और मेटाडेटा है। यह धीमा हो सकता है लेकिन YMMV।

आप data=सिस्टम को बढ़ते समय विकल्प का उपयोग करके मोड सेट करते हैं , जैसे data=ordered


जर्नलिंग मोड को पूरी तरह से बंद करने के विपरीत इस बिंदु के लिए कोई अर्थ नहीं है, लेकिन इसमें बहुत कम समझ भी है। इसलिए यह बताना कि पत्रिका के विकल्प क्या व्यर्थ करते हैं।
पूज

3
विभिन्न जर्नल मोड विभिन्न CPU व्यवहारों को प्रदर्शित करते हैं। कुछ परीक्षण यहाँ
coredump

1
@coredump, अभी भी व्यर्थ है । अलग-अलग जर्नलिंग मोड के लिए सीपीयू के उपयोग को दिखाने वाला कोई ग्राफ नहीं है, केवल थ्रूपुट। सीपीयू उपयोग ग्राफ वास्तव में केवल एफएसई के बीच अंतर दिखाता है। इसके अलावा, उस ग्राफ पर EXT3 और Reiser3 के बीच ध्यान देने योग्य अंतर को ध्यान में रखते हुए, यह स्पष्ट है कि समग्र और औसत सीपीयू पदचिह्न का विश्लेषण किया जाता है, @viraptor में kjournald गतिविधि की बाइक है।
2

हम तब असहमत होंगे। केवल उसके पर्यावरण पर परीक्षण से पता चलेगा कि CPU उपयोग पर कोई अंतर है या नहीं। इसके अलावा, मैं ReiserFS की सिफारिश नहीं करूंगा, क्योंकि सरकार को FS लेखक पर एक स्थायी ताला मिला है :)।
coredump

8
यहां, इस कप ऑफ ह्यूमर: \
coredump

4

डिफ़ॉल्ट रूप से आपका ext3 फाइल सिस्टम चालू होने वाले अपराधों के साथ आरोहित होने वाला है। जब भी कोई फ़ाइल या निर्देशिका पढ़ी जाती है / एक्सेस की जाती है, तो इस atime रिकॉर्ड को अपडेट करने के लिए फाइल सिस्टम को डिस्क पर वापस लिखना होगा। इसका मतलब यह है कि भले ही आपका कार्यभार अधिकतर पढ़ा जाता है, फिर भी आपको प्रत्येक फ़ाइल और निर्देशिका के एक्सेस समय को अपडेट करने के लिए डिस्क को हिट करने की आवश्यकता होगी, और यह मेरा अनुमान है कि आपकी kjournaldप्रक्रिया इतने सारे ब्लॉक क्यों लिख रही थी।

Atime के बंद होने से प्रदर्शन को बड़ा बढ़ावा मिलेगा लेकिन POSIX अनुपालन को तोड़ देगा। की जाँच करें यह विकिपीडिया लेख atime की की आलोचना के आसपास कुछ चर्चा के लिए।

केवल noatimeअपने फाइल सिस्टम के लिए माउंट विकल्पों में जोड़ें अपराधों को बंद करने के लिए, या आप poige द्वारा सुझाए गए अनुसार हटा सकते हैं। यहाँ आपके रूट फाइल सिस्टम के लिए एक उदाहरण है:

mount -o remount,noatime /

3
ध्यान दें कि अधिक हाल के गुठली डिफ़ॉल्ट है relatimeजो के बीच एक स्वीकार्य समझौता लगता है noatimeऔर atime
ओलिवर

1

यदि डेटा की परिपूर्णता महत्वपूर्ण नहीं है: ऐसा करें

iostat -o -a

सुनिश्चित करें कि यह वास्तव में kjournald है। यह मेरे सर्वर को क्रैश करने का कारण बनता है।

SSD को हार्ड ड्राइव बदलने से काम चल जाएगा।

जब आप kjournald को 5-10MB डेटा लिखते हुए देखते हैं

http://ubuntuforums.org/showthread.php?t=56621

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck /dev/sda1

जहाँ sda1 आपके विभाजन का नाम है

टिप्पणी में परिणाम रिपोर्ट करें ताकि मैं आगे की जांच कर सकूं।


3
आप का मतलब है iotop, नहीं iostat, है ना?
जो नाइलैंड

0

करने के क्रम में नहीं, सिर्फ उल्लेख करने के लिए:

  1. mount -oremount,noatime /fs/being_over/journaled- एक त्वरित अनुमान-शॉट के रूप में (आपने हमें यह नहीं दिखाया कि आपका mountकैसा भी दिख रहा है)
  2. जर्नल का आकार कम करने का प्रयास करें ( tune2fs -J …)
  3. Reiser3 पर स्विच करें (काफी लंबे समय के लिए मजबूत, हाँ। और ऐसा कोई गंदा पत्रकार नहीं है।)
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.