OS X पर lsof इतना हास्यास्पद रूप से धीमा क्यों है?

Question

मैं यह पता नहीं लगा सकता कि मेरे मैक पर lsof क्यों (10.8.2, मैकबुक प्रो) इतना धीमा है।

मेरे मैक पर, lsofएक मिनट से अधिक समय लगता है:

$ touch /tmp/testfile
$ time lsof /tmp/testfile

real   1m16.483s
user   0m0.029s
sys    1m15.969s

एक विशिष्ट लिनक्स बॉक्स पर, Ubuntu 12.04 चल रहा है, lsof20 एमएस लेता है:

$ touch /tmp/testfile
$ time lsof /tmp/testfile

real   0m0.023s
user   0m0.008s
sys    0m0.012s

समस्या तब बनी रहती है अगर मैं चला lsof -n(DNS लुकअप से बचने के लिए)। इसके अलावा, मैंने जांचने की कोशिश की कि कौन से सिस्टम कॉल lsofका उपयोग करके किया जाता है dtruss, और पाया कि यह proc_infoदसियों बार कॉल कर रहा है:

$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | sort | uniq -c | sort -nr | head
10000 proc_info(0x2, 0x1199, 0x8) = 1272 0
 6876 proc_info(0x2, 0x45, 0x8) = 1272 0
 2360 proc_info(0x2, 0x190D, 0x8) = 1272 0
 1294 proc_info(0x2, 0xFF, 0x8) = 1272 0
 1152 proc_info(0x2, 0x474, 0x8) = 1272 0
 1079 proc_info(0x2, 0x2F, 0x8) = 1272 0
  709 proc_info(0x2, 0xFE, 0x8) = 1272 0
  693 proc_info(0x2, 0x1F, 0x8) = 1272 0
  623 proc_info(0x2, 0x11A, 0x8) = 1272 0
  528 proc_info(0x2, 0xF7, 0x8) = 1272 0

कोई विचार? मैंने ये परीक्षण चलाए हैं और lsofOS X (4.85) के साथ-साथ ftp ●sunsite.ualberta.ca/pub/Mirror/lsof/ (4.87) के नवीनतम संस्करण का उपयोग करते हुए एक ही परिणाम प्राप्त किया है ।

(जिज्ञासु के लिए, मैं इस प्रदर्शन से निराश हूं, इसका कारण यह है कि जब मैं छवियों को एवरनोट तक खींचता हूं, तो यह lsofफ़ाइल को कॉपी करने की प्रक्रिया में चलता है, जिससे मेरा सिस्टम हर बार एक पूरे मिनट के लिए लटका रहता है जब मैं एक छवि सम्मिलित करने का प्रयास करता हूं (एवरनोट में।)

Comments

यदि आपके पास फ़ाइल के बजाय कंसोल के लिए आउटपुट है, तो क्या यह किसी विशेष बिंदु पर लटका है? मैं भी 10.8.2 पर हूं। यह मेरे लिए 6 सेकंड ले रहा था, और मैंने देखा कि यह हर बार आधे रास्ते में AirServer की खुली फाइलों को सूचीबद्ध करने के लिए लटका रहा था। मैंने AirServer को मार दिया, और समय घटकर 1.76 हो गया। शायद आपके सिस्टम में कुछ ऐसा है जो मूल्यांकन करने में लंबा समय ले रहा है?

— वॉरेन पेना

दिलचस्प डेटा बिंदु, @WarrenPena। अगर मैं lsofबिना किसी तर्क (सभी फाइलों को सूचीबद्ध करने के लिए) के साथ चलता हूं , तो यह एक मिनट के लिए लटका रहता है और फिर सभी फाइलों को प्रिंट करता है। लेकिन, जैसा कि मैंने उल्लेख किया है, यह अभी भी लटका हुआ है अगर मैं यह सूचीबद्ध करने की कोशिश करता हूं कि किसके पास / tmp निर्देशिका में एक एकल फ़ाइल खुली है, इसलिए यह एक विशेष खुली फ़ाइल नहीं है जो समस्या है। इसके अलावा, मैं कोई AirServer प्रक्रिया नहीं चला रहा हूं।

— जेसन

यह (केवल?) मेरे लिए लगभग एक सेकंड लेता है। आप भी आजमा सकते हैं sudo opensnoop -n lsof।

— 12

यह मेरे लिए 19 s लेता है। पता नहीं क्यों ...

— daviewales

अच्छा विचार, @LauriRanta मैंने दौड़ने की कोशिश की sudo opensnoop -n lsofऔर lsof /tmp/testfileदो टैब में, और ओपननोप ने केवल सूचना दी कि तीन फाइलें खोली गई थीं। तो समस्या अधिक संख्या में फ़ाइल खोलने की नहीं होनी चाहिए, लेकिन अत्यधिक proc_infoकॉल से संबंधित कुछ ।

— जेसन

Answer 1

मेरे अनुभव के रूप में, मैक ओएस एक्स 10.7 (लायन) से 10.11.5 Cap ईआई कैपिटन), lsofहमेशा लटका।

समस्या को हल करने के लिए, -nविकल्प जोड़ें ।

lsof -n

के मैनुअल के अनुसार lsof, -nविकल्प:

inhibits the conversion of network numbers to host names for network files.  
Inhibiting conversion may make  lsof  run faster.  It is also useful when host 
name lookup is not working properly

EDIT 2018-04-25: यदि यह अभी भी धीमा है, तो आप कोशिश कर सकते हैं

-O to bypass  the  strategy it uses to avoid being blocked by some kernel operations
-P to inhibits the conversion of port numbers to port names for network files
-l to inhibits  the  conversion of user ID numbers to login names

यह पता लगाने का अंतिम तरीका कि इतना धीमा "इंस्ट्रूमेंट्स" टूल (ऊपरी दाएं कोने के स्पॉटलाइट खोज आइकन से) चलाने के लिए / usr / sbin / lsof पर "सिस्टम ट्रेस" करने के लिए फिर ग्राफ और sys कॉल देखें।

Comments

वाह! जोड़ने के -nलिए मेरे lsof +Dनीचे से काट रहा 5.31 realहै 0.25 real। यह विकल्प ... असली

— वेटजॉश

फिर भी मेरे लिए हास्यास्पद रूप से धीमी ...

— नोल्डोरिन

हाय @ नोल्डोरिन क्या आप इस पुराने धागे के समान ओएस पर हैं? यदि नहीं, तो आपके विशिष्ट सेटअप और विशिष्ट समय के साथ लिंक करने वाला एक नया विशिष्ट प्रश्न एक नए उत्तर के लायक हो सकता है।

— bmike

Answer 2

मुझे लगता है कि समस्या का सबसे बड़ा हिस्सा यह है कि व्यर्थ फ्रेमवर्क की परतों पर ब्लोस और अनावश्यक परतों के साथ macOS कभी अधिक हास्यास्पद होता जा रहा है। इसका मतलब सैकड़ों अतिरिक्त प्रक्रियाओं और हजारों अतिरिक्त फ़ाइलों को खुला रखना है, काम की मात्रा में वृद्धि को lsofकम से कम परिमाण के एक आदेश से करना पड़ता है, और शायद दो आदेशों की तरह।

lsof उचित गति से 10.6 और 10.13 के बीच अत्याधिक धीमी गति से चला गया।

यहाँ एक चालू 10.13.4 सिस्टम पर मैं केवल 7 ऐप्स को खुला और रनिंग (टर्मिनल, क्रोम, कैलेंडर, फाइंडर, एडियम, आईपीगैड और स्टिकिज़) के साथ देखता हूँ। (क्रोम में 7 विंडो हैं, जिनमें से प्रत्येक में शायद 10 टैब हैं।)

# ps ax | wc -l
     401
# time lsof -lnP | wc -l
   10976

real    0m49.684s
user    0m0.250s
sys 0m40.172s

रन के दौरान दोनों सीपीयू 50% सिस्टम समय से अधिक हैं

जोड़ना -Oकभी - कभी मदद करता है, खासकर अगर lsofहाल ही में नहीं चलाया गया है, लेकिन मैंने जो सबसे अच्छा देखा है वह लगभग 10% बचत थी। आमतौर पर यह ऋणात्मक है और मैन्युअल पृष्ठ में उल्लिखित जोखिमों के लायक नहीं है:

# time lsof -lnPO | wc -l
   10994

real    0m47.482s
user    0m0.249s
sys 0m40.472s

dtrussproc_info()मेरे वर्तमान प्रक्रिया लोड के साथ 89,000 से अधिक कॉल का दावा है , और वे कर्नेल में हैं, और timeरिपोर्ट के अनुसार, समय का सबसे बड़ा हिस्सा कर्नेल में है। मुझे नहीं पता कि प्रति खुली फ़ाइल में लगभग 8 कॉल क्यों हैं।

दुर्भाग्य से macOS / डार्विन में कभी भी अधिक उपयोगी और कुशल बीएसडी fstatकमांड शामिल नहीं है।

Answer 3

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

मैंने तीन मैक की कोशिश की है और 10.7.5 पर चलने वाले लोग मेरे 10.8.2 मैक की तुलना में एक दूसरे तेजी से हैं। पुराने ओएस धीमे कोर 2 डुओ प्रोसेसर हैं और मुझे लगता है कि नया ओएस चलाने वाला i7 मैक पुराने ओएस और सीपीयू की तुलना में तेज या तेज होगा, लेकिन मैं गलत होगा।

सभी मशीनें proc_info कॉल की समान संख्या के बारे में बनाती हैं, और सभी मशीनों में कमांड के लिए उपयोगकर्ता का दुबला समय होता है - लेकिन आप समग्र समय पर धीमी गति से हो सकते हैं (और मुझे कोई सुराग नहीं है कि आपका माउंटेन लायन की तुलना में आपका नाटकीय रूप से धीमा क्यों है मैक)।

11 इंच एयर (i7) 2011 में माउंटेन लायन - SSD:

$ system_profiler SPSoftwareDataType
      System Version: OS X 10.8.2 (or something)
      Kernel Version: Darwin 12.3.0
      Secure Virtual Memory: Enabled
$ time lsof /tmp/testfile 

real    0m1.179s
user    0m0.012s
sys     0m1.158s
$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | sort | uniq -c | sort -nr | head
9310 proc_info(0x2, 0x68, 0x8)           = 1272 0
1220 proc_info(0x2, 0xCEB6, 0x8)                 = 1272 0
$ cat /tmp/dump | cut -c -9 | sort | uniq -c | sort -nr | head
30884 proc_info
 116 write(0x4
  87 read(0x5,
  60 sigaction
  60 setitimer
  35 stat64("/
  30 sigprocma
  30 sigaltsta
  21 close(0x3
  18 close(0x6 

15 इंच मैकबुक प्रो रनिंग लायन सर्वर - एचडीडी:

$ system_profiler SPSoftwareDataType
      System Version: Mac OS X Server 10.7.5 (11G63)
      Kernel Version: Darwin 11.4.2
$ time lsof /tmp/testfile

real    0m0.329s
user    0m0.005s
sys     0m0.324s

27 इंच का iMac रनिंग लायन - HDD:

$ system_profiler SPSoftwareDataType
      System Version: Mac OS X 10.7.5 (11G63b)
      Kernel Version: Darwin 11.4.2
$ time lsof /tmp/testfile

real    0m0.066s
user    0m0.002s
sys     0m0.065s
$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | cut -c -9 | sort | uniq -c | sort -nr | head
23034 proc_info
 188 write(0x4
 141 read(0x5,
  96 sigaction
  96 setitimer
  48 sigprocma
  48 sigaltsta
  31 stat64("/
  21 close(0x3
  18 close(0x6

Comments

+1। मैं एक देर से 2010 MBP (i7 + 8GB) पर 10.8.2 चला रहा हूं, और उन ऐप्स का एक गुच्छा चला रहा हूं, जो मुझे ~ 1.8s मिल रहे हैं।

— हार्व