लिनक्स IO प्रति फ़ाइल निगरानी?


29

मैं CentOS पर डिस्क IO प्रति फ़ाइल की निगरानी के लिए एक उपयोगिता या प्रक्रिया में दिलचस्पी रखता हूं ।

Win2008 पर, रेसमन उपयोगिता इस प्रकार के ड्रिलडाउन की अनुमति देती है, लेकिन मुझे जो भी लिनक्स यूटिलिटीज मिली हैं, उनमें से कोई भी ऐसा नहीं करता (iostat, iotop, dstat, nmon)।

डेटाबेस सर्वरों पर IO की अड़चनों की निगरानी में मेरी रुचि है। MSSQL के साथ, मुझे यह जानने के लिए एक सूचनात्मक निदान मिल गया है कि कौन सी फाइलें / फाइलस्पेस सबसे कठिन हिट हो रहे हैं।



1
यदि यह संभव है, तो नोट करें कि अधिकांश फ़ाइलों को पेजकेस में मैप किया जाता है, ताकि आपके नंबर बाइट्स के आधार पर सभी जगह पर हो सकें और पेजकेस में क्या हो।
मैथ्यू इफ

@ मट लेकिन एक काम के जवाब के साथ!
ewwhite

जवाबों:


18

SystemTap शायद आपका सबसे अच्छा विकल्प है।

यहाँ iotime.stp उदाहरण से आउटपुट कैसा दिखता है:

825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11

नुकसान (सीखने की अवस्था से हटकर) यह है कि आपको कर्नेल-डिबग स्थापित करना होगा , जो उत्पादन प्रणाली पर संभव नहीं हो सकता है। हालांकि, आप क्रॉस-इंस्ट्रूमेंटेशन का सहारा ले सकते हैं जहां आप एक विकास प्रणाली पर एक मॉड्यूल संकलित करते हैं, और उत्पादन प्रणाली पर उस .ko को चलाते हैं ।

या यदि आप अधीर हैं, तो अध्याय 4 देखें । शुरुआती गाइड से उपयोगी सिस्टमटैप लिपियों


17

SystemTap * स्क्रिप्ट:

#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
#   ./monitor-io.stp name-of-the-program

global program_name = @1

probe begin {
  printf("%5s %1s %6s %7s %s\n",
         "PID", "D", "BYTES", "us", "FILE")
}

probe vfs.read.return, vfs.write.return {
  # skip other programs
  if (execname() != program_name)
    next

  if (devname=="N/A")
    next

  time_delta = gettimeofday_us() - @entry(gettimeofday_us())
  direction = name == "vfs.read" ? "R" : "W"

  # If you want only the filename, use
  // filename = kernel_string($file->f_path->dentry->d_name->name)
  # If you want only the path from the mountpoint, use
  // filename = devname . "," . reverse_path_walk($file->f_path->dentry)
  # If you want the full path, use
  filename = task_dentry_path(task_current(),
                              $file->f_path->dentry,
                              $file->f_path->mnt)

  printf("%5d %1s %6d %7d %s\n",
         pid(), direction, $return, time_delta, filename)
}

आउटपुट इस तरह दिखता है:

[root@sl6 ~]# ./monitor-io.stp cat
PID D  BYTES      us FILE
3117 R    224       2 /lib/ld-2.12.so
3117 R    512       3 /lib/libc-2.12.so
3117 R  17989     700 /usr/share/doc/grub-0.97/COPYING
3117 R      0       3 /usr/share/doc/grub-0.97/COPYING

या यदि आप माउंटपॉइंट से केवल पथ प्रदर्शित करना चुनते हैं:

[root@f19 ~]# ./monitor-io.stp cat
  PID D  BYTES      us FILE
26207 R    392       4 vda3,usr/lib64/ld-2.17.so
26207 R    832       3 vda3,usr/lib64/libc-2.17.so
26207 R   1758       4 vda3,etc/passwd
26207 R      0       1 vda3,etc/passwd
26208 R    392       3 vda3,usr/lib64/ld-2.17.so
26208 R    832       3 vda3,usr/lib64/libc-2.17.so
26208 R  35147      16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R      0       2 vdb7,ciupicri/doc/grub2-2.00/COPYING

[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

सीमाएं / कीड़े:

  • mmap आधारित I / O दिखाई नहीं देता क्योंकि devnameहै"N/A"
  • पर फ़ाइलों tmpfs दिखाई नहीं देती हैं, क्योंकि devnameहै"N/A"
  • इससे कोई फर्क नहीं पड़ता कि रीड कैश से हैं या राइट्स बफर में हैं

मैथ्यू इफ के कार्यक्रमों के लिए परिणाम :

  • के लिए mmaptest निजी:

     PID D  BYTES      us FILE
    3140 R    392       5 vda3,usr/lib64/ld-2.17.so
    3140 R    832       5 vda3,usr/lib64/libc-2.17.so
    3140 W     23       9 N/A,3
    3140 W     23       4 N/A,3
    3140 W     17       3 N/A,3
    3140 W     17     118 N/A,3
    3140 W     17     125 N/A,3
    
  • साझा किए गए mmaptest के लिए :

     PID D  BYTES      us FILE
    3168 R    392       3 vda3,usr/lib64/ld-2.17.so
    3168 R    832       3 vda3,usr/lib64/libc-2.17.so
    3168 W     23       7 N/A,3
    3168 W     23       2 N/A,3
    3168 W     17       2 N/A,3
    3168 W     17      98 N/A,3
    
  • के लिए diotest (प्रत्यक्ष आई / ओ):

     PID D  BYTES      us FILE
    3178 R    392       2 vda3,usr/lib64/ld-2.17.so
    3178 R    832       3 vda3,usr/lib64/libc-2.17.so
    3178 W     16       6 N/A,3
    3178 W 1048576     509 vda3,var/tmp/test_dio.dat
    3178 R 1048576     244 vda3,var/tmp/test_dio.dat
    3178 W     16      25 N/A,3
    

* आरएचईएल 6 या समकक्ष के लिए त्वरित सेटअप निर्देश: yum install systemtapऔरdebuginfo-install kernel


Thats कुछ बहुत प्रभावशाली systemtap वहीं। इसकी बहुमुखी प्रतिभा का उत्कृष्ट प्रदर्शन।
मैथ्यू इफ

क्या यह उपाय I / O को प्रत्यक्ष करता है और एसिंक्रोनस I / O? (io_submit का उपयोग करते हुए, पॉज़िक्स नहीं)
मैथ्यू इफ

@ सहयोगी: धन्यवाद! एक साइड नोट के रूप में, स्क्रिप्ट लिखते समय मैं pv में एक छोटे से बग की खोज करने में सफल रहा और SystemTap ( task_dentry_path) :-) में एक और मुझे इस बारे में कोई पता नहीं है कि मैं / O हूं, लेकिन अगर आप मुझे एक कमांड देते हैं या मैं इसका परीक्षण कर सकता हूं एक नमूना कार्यक्रम। उदाहरण के लिए मैंने पैमाप का परीक्षण करने के लिए पायथन का उपयोग किया । dd iflag=direct oflag=directदिखाता है।
क्रिस्टियन सियुपिटु

2
Mmap के लिए यह प्रयास करें: gist.github.com/anonymous/7014284 मैं शर्त लगा रहा हूं कि निजी मैपिंग को मापा नहीं जाता है, लेकिन साझा किए जाते हैं ..
मैथ्यू इफ

2
एक सीधा आईओ परीक्षण का उपयोग करता है: gist.github.com/anonymous/7014604
मैथ्यू इफ

9

आप वास्तव में इसके लिए उपयोग करना चाहते हैं blktraceसीकवॉचर और ब्लुट्रेस के साथ विज़ुअलाइज़िंग लिनक्स IO देखें ।

मैं देखूंगा कि क्या मैं अपना एक उदाहरण जल्द ही पोस्ट कर सकता हूं।


संपादित करें:

आप लिनक्स के वितरण का उल्लेख नहीं करते हैं, लेकिन हो सकता है कि यह लिनक्स या यहां तक ​​कि सिस्टम टैप पर एक dtrace स्क्रिप्ट के लिए एक अच्छा मामला है , अगर आप किसी RHEL जैसी प्रणाली का उपयोग कर रहे हैं।


2
धन्यवाद, अच्छी बात और बिंदु के बहुत करीब, लेकिन यह विस्तृत ब्लॉक-लेयर जानकारी प्रदान करता है, मुझे कुछ ऐसा चाहिए जो वीएफएस अमूर्त परत पर काम करता है।
जियोमैक्स

मैंने इसे चलाने के लिए कुछ सिस्टमटैप स्क्रिप्ट का प्रयास करना शुरू किया। मैं विफल रहा क्योंकि सर्वर क्रैश हो गया। मुझे यह जानकारी Solaris पर Dtrace पर मिल सकती है। मैं आज लिनक्स के साथ प्रयास करूँगा।
ewwhite

4

एकमात्र उपकरण जो मुझे पता है कि मैं फ़ाइल द्वारा I / O गतिविधि की निगरानी कर सकता है inotifywatch। यह inotify-toolsपैकेज का हिस्सा है । दुर्भाग्य से, यह केवल आपको ऑपरेशन की गिनती देता है।


4

उच्च IO में योगदान देने वाली प्रक्रियाओं की PID पाने के लिए iotop का उपयोग करें

आपके द्वारा उत्पन्न पीआईडी ​​के खिलाफ रन स्ट्रेस, आप देखेंगे कि कौन सी फाइलें एक विशेष प्रक्रिया द्वारा एक्सेस की जा रही हैं

strace -f -p $PID -e trace=open,read,write

स्ट्रेस syscalls और एक्सेस की गई फ़ाइलों की जानकारी प्रदान करेगा, यह पार्स करने और उपयोग पर आंकड़े प्राप्त करने के लिए बहुत कठिन होगा ...
GioMac

1
सोचा कि मैं यह कोशिश करूँगा। यह डेटा का बहुत उत्पन्न करता है। और जब आप ctrl + c को प्रोसेस कर सकते हैं तो क्रैश कर सकते हैं। यह बल्कि खतरनाक लगता है।
मैट

4

मैंने अंततः इसके लिए Sysdig का उपयोग किया


कैसे करें : Sysdig स्थापित करें , चलाएँ csysdig, F2 दबाएँ, और Filesदृश्य चुनें । आप OPS कॉलम द्वारा एक्सेस की गई फ़ाइलों के शीर्ष देखेंगे (F9 दबाकर बदला जा सकता है)।
कैटपन्नोसिस

csysdig -v filesसीधे "फाइल" दृश्य में जाता है
गर्ट वैन डेन बर्ग

2

मेरा तर्क है कि आपने गलत सवाल पूछा होगा। यदि आप i / o बाधाओं के लिए देख रहे हैं, तो यह देखना महत्वपूर्ण है कि आपकी डिस्क पर क्या हो रहा है। डीबी के यादृच्छिक i / o करने के लिए कुख्यात हैं जो विशेष रूप से थ्रूपुट को कम कर सकते हैं, खासकर यदि आपके पास केवल कुछ स्पिंडल हैं।

यदि आप स्वयं डिस्क पर लंबे समय से प्रतीक्षा कर रहे हैं तो यह देखना अधिक दिलचस्प हो सकता है। आप इसे कमांड "collectl -sD" के माध्यम से कलेक्ट कर सकते हैं, जो व्यक्तिगत डिस्क प्रदर्शन आँकड़े दिखाएगा। क्या आप इसे शीर्ष-जैसी उपयोगिता में बदल सकते हैं। यदि बहुत सारे डिस्क शामिल हैं, तो इसे कॉलमक्स: कोलमक्स -कम "-sD" के माध्यम से चलाएं और यह आपको अपनी पसंद के एक कॉलम द्वारा, यहां तक ​​कि कई प्रणालियों में भी छाँटने देगा।


मैं डिस्क दृष्टिकोण से आपसे असहमत नहीं हूं। जहां मुझे कुछ जानकारी मिल सकती है जब डेटा, इंडेक्स, लॉग आदि के विभाजन के लिए एक डेटाबेस फाइल का उपयोग किया जाता है, लेकिन संसाधनों के सीमित होने पर साझा डिस्क पर घुड़सवार - उदाहरण के लिए विकास सर्वर। आदर्श रूप से, इनमें से प्रत्येक फाइलिंग अलग-अलग संस्करणों पर होगी, इस प्रकार डिस्क के दृष्टिकोण से आईओ को देखना पर्याप्त होगा - जिसके कारण सभी निगरानी उपयोगिताओं की डिस्क होती है, न कि फ़ाइल आधारित।
kermatt

यह सही सवाल है; लक्ष्य यह पता लगाने की कोशिश कर रहा है कि "किस तालिका में यह सब I / O हो रहा है?", और अधिकांश डेटाबेस में एक तालिका एक या अधिक फाइलें हैं। कोई भी डिस्क उस पर कई फ़ाइलों के साथ समाप्त होने जा रही है, और यह निर्धारित करना कि कौन से हॉटस्पॉट हैं, एक उपयोगी डेटाबेस ट्यूनिंग इनपुट है।
ग्रेग स्मिथ


0

हो सकता है कि inotify इसका समाधान निकाल दे

Inotify API फाइलसिस्टम घटनाओं की निगरानी के लिए एक तंत्र प्रदान करता है। नोटिफिकेशन का इस्तेमाल अलग-अलग फाइलों को मॉनिटर करने के लिए या डायरेक्ट्री मॉनिटर करने के लिए किया जा सकता है। जब एक निर्देशिका की निगरानी की जाती है, तो inotify निर्देशिका के लिए घटनाओं को वापस करेगा, और निर्देशिका के अंदर फ़ाइलों के लिए।

फ़ाइल सिस्टम गतिविधि को मॉनिटर करें inotify के साथ

संदर्भ निर्दिष्ट करें


यह फ़ाइल पर किए गए कॉल प्रदान कर सकता है, लेकिन यह जानने में मदद करने के लिए बहुत कम प्रदान करता है कि यह क्या किया, यह कितना बड़ा था, यह कहाँ और कितना समय लगा।
मैथ्यू इफ

सवाल प्रक्रिया के बारे में नहीं पूछता है (जो संभवतः अन्य तरीकों से खोजा जा सकता है, जैसे lsof)
गर्ट वैन डेन बर्ग

0

जबकि यहाँ के जवाबों में बहुत सारी अच्छी जानकारी है, मैं सोच रहा हूँ कि क्या यह वास्तव में लागू होगा?

यदि आप गीगाबाइट्स के 10 के दशक में फ़ाइलों के बारे में बात कर रहे हैं, तो लगातार लिखा जा रहा है, तो जब तक वे लॉग फाइल या समान नहीं होते हैं, जो लगातार संलग्न होते हैं (जिस स्थिति में बस फ़ाइल आकार की निगरानी करते हैं), यह सबसे अधिक संभावना है कि फाइलें mmap'd हैं । यदि ऐसा है, तो सबसे अच्छा जवाब यह हो सकता है कि आपको अधिकांश समाधानों को देखना बंद कर देना चाहिए। पहली बात तो आपको किसी अन्य प्रस्तावित समाधान के बारे में पूछना चाहिए "क्या यह एमएमएपी के साथ काम करता है", क्योंकि ज्यादातर वे अभ्यस्त नहीं होते हैं। आप किसी फ़ाइल को मॉनिटर करने के बजाय समस्या को ब्लॉक डिवाइस की निगरानी में बदल सकते हैं।

जब कोई प्रोग्राम mmap'd फ़ाइल से पेज मांगता है, तो यह वर्चुअल मेमोरी में एक स्थान को संदर्भित करता है। वह पृष्ठ पहले से ही स्मृति में हो सकता है या नहीं भी हो सकता है। यदि यह नहीं है, तो यह एक पृष्ठ दोष उत्पन्न करता है, जो पृष्ठ को डिस्क से लोड किए जाने पर ट्रिगर करता है, लेकिन यह वर्चुअल मेमोरी सिस्टम के भीतर होता है, जो आसानी से एक विशिष्ट एप्लिकेशन प्रक्रिया या किसी विशिष्ट फ़ाइल से बंधा नहीं होता है। इसी तरह, जब आपका ऐप फ्लैगशिप्स के आधार पर एक mmap'd पेज को अपडेट करता है, जो कि डिस्क पर तत्काल लिखने को ट्रिगर नहीं कर सकता है, और कुछ मामलों में डिस्क पर बिल्कुल भी नहीं जा सकता है (हालांकि संभवतः उन अंतिम मामलों में आपकी रुचि नहीं है। में)।

सबसे अच्छा मैं mmap'd फ़ाइलों के लिए सोच सकता हूं, अगर यह आपके लिए व्यवहार्य है, तो ब्याज की फ़ाइलों में से प्रत्येक को एक अलग डिवाइस पर रखना है, और अपने उपयोग की जानकारी एकत्र करने के लिए डिवाइस के आंकड़ों का उपयोग करना है। आप इसके लिए lvm विभाजन का उपयोग कर सकते हैं। एक बांध माउंट काम नहीं करेगा, क्योंकि यह एक नया ब्लॉक डिवाइस नहीं बनाता है।

एक बार जब आपके पास अलग-अलग ब्लॉक डिवाइस पर आपकी फाइलें होती हैं, तो आप / sys / block / *, या / proc / diskstats से आँकड़े प्राप्त कर सकते हैं

इसे उत्पादन सर्वर में पेश करना बहुत ही विघटनकारी हो सकता है, लेकिन शायद आप इसका उपयोग कर सकते हैं।

यदि फ़ाइलें mmapped नहीं हैं, तो हाँ, आप यहां अन्य समाधानों में से एक का चयन कर सकते हैं।


कृपया ध्यान से पढ़ें, मुझे ब्लॉक-स्तरीय आँकड़े की आवश्यकता नहीं है :)
GioMac

दाईं ओर, लेकिन आप जिस तरह के आंकड़े पूछ रहे हैं, वह मिमीप्ड फ़ाइलों के लिए संभव नहीं है, इसलिए यदि आप उसके खिलाफ चल रहे हैं, तो यह आपको डिवाइस के प्रति एक फ़ाइल का उपयोग करके और फ़ाइलों को पढ़कर फ़ाइलों के बारे में आँकड़े प्राप्त करने का एक संभव तरीका देता है। डिवाइस आँकड़े।
एमसीए

-1

मैं हाल ही में कलेक्ट के साथ छेड़छाड़ कर रहा था , यह एक महान उपकरण दिखता है, और स्थापित करने के लिए बहुत कठिन है। सबसे दिलचस्प यह है कि आप यह पता लगा सकते हैं कि IO की अड़चनों के लिए कौन सी जिम्मेदार प्रक्रिया है। मैं आपको कलेक्ट का उपयोग करके पढ़ने की सलाह दूंगा , यह उपयोगी हो सकता है।


1
संग्रह प्रति फ़ाइल की निगरानी नहीं करता है, यह प्रति प्रक्रिया काम करता है
ग्रेग स्मिथ

-1

मैं आपको http://dag.wieers.com/home-made/dstat/ चेक करने की सलाह दूंगा । यह महान उपकरण बहुत सारे आँकड़ों की जाँच करने की अनुमति देता है।


1
dstat प्रति फ़ाइल की निगरानी नहीं करता है, यह प्रति प्रक्रिया को सारांशित करता है
ग्रेग स्मिथ

-2

मुझे लगता है कि आईओटी पर अड़चनों की पहचान के लिए लिनक्स पर सबसे अच्छा उपकरण में से एक है।


3
-1 iotopप्रति फ़ाइल मॉनिटर नहीं करता है, यह प्रति प्रक्रिया काम करता है
dyasny
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.