java प्रक्रियाओं के साथ उच्च cpu / IO पर ps aux लटका


13

मैं जावा प्रक्रिया और एनआरईपी जांच के साथ कुछ मुद्दे रख रहा हूं। हमारे पास कुछ प्रक्रियाएं हैं जो कभी-कभी 32 कोर सिस्टम पर 1000% सीपीयू का उपयोग करती हैं। जब तक आप ऐसा नहीं करते हैं, तब तक प्रणाली बहुत संवेदनशील है

ps aux 

या कुछ भी करने की कोशिश / proc / pid # में

[root@flume07.domain.com /proc/18679]# ls
hangs..

पीएस ऑक्स की एक धारा

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/dev/pts1", 0x7fffb8526f00)       = -1 ENOENT (No such file or directory)
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
readlink("/proc/15693/fd/2", "/dev/pts/1", 127) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "root     15693 15692  0 06:25 pt"..., 55root     15693 15692  0 06:25 pts/1    00:00:00 ps -Af
) = 55
stat("/proc/18679", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/18679/stat", O_RDONLY)      = 5
read(5, "18679 (java) S 1 18662 3738 3481"..., 1023) = 264
close(5)                                = 0
open("/proc/18679/status", O_RDONLY)    = 5
read(5, "Name:\tjava\nState:\tS (sleeping)\nT"..., 1023) = 889
close(5)                                = 0
open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

जावा प्रक्रिया काम कर रही है और पूरी तरह से ठीक हो जाएगी, लेकिन मुद्दा यह है कि यह हमारी निगरानी को खत्म कर देता है नट सोच प्रक्रियाएं नीचे हैं क्योंकि यह समय पूरा होने के लिए पीएस ऑक्स की प्रतीक्षा कर रहा है।

मैंने कुछ ऐसा करने की कोशिश की है

 nice -19 ionice -c1 /usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -a 'diamond' -u root -t 30

भाग्य से नहीं

संपादित करें

सिस्टम चश्मा

  • 32 कोर इंटेल (R) Xeon (R) CPU E5-2650 0 @ 2.00GHz
  • 128 ग्राम राम
  • 12 4Tb 7200 ड्राइव
  • सेंटोस 6.5
  • मुझे यकीन नहीं है कि मॉडल लेकिन विक्रेता सुपरमाइक्रो है

जब ऐसा होता है तो लोड 1 मिनट के लिए लगभग 90-160ish होता है।

विषम भाग यह है कि मैं किसी अन्य / proc / pid # में जा सकता हूं और यह ठीक काम करता है। जब मैं ssh में होता हूं तो सिस्टम उत्तरदायी होता है। जब हम उच्च भार के बारे में सचेत हो जाते हैं तो मैं बस ठीक-ठाक में ssh कर सकता हूं।

एक और संपादन

मैं अनुसूचक के लिए समय सीमा का उपयोग कर रहा हूँ

[root@dn07.domain.com ~]# for i in {a..m}; do cat /sys/block/sd${i}/queue/scheduler; done
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq

पर्वत जैसा दिखता है

[root@dn07.manage.com ~]# mount
/dev/sda3 on / type ext4 (rw,noatime,barrier=0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdb1 on /disk1 type xfs (rw,nobarrier)
/dev/sdc1 on /disk2 type xfs (rw,nobarrier)
/dev/sdd1 on /disk3 type xfs (rw,nobarrier)
/dev/sde1 on /disk4 type xfs (rw,nobarrier)
/dev/sdf1 on /disk5 type xfs (rw,nobarrier)
/dev/sdg1 on /disk6 type xfs (rw,nobarrier)
/dev/sdh1 on /disk7 type xfs (rw,nobarrier)
/dev/sdi1 on /disk8 type xfs (rw,nobarrier)
/dev/sdj1 on /disk9 type xfs (rw,nobarrier)
/dev/sdk1 on /disk10 type xfs (rw,nobarrier)
/dev/sdl1 on /disk11 type xfs (rw,nobarrier)
/dev/sdm1 on /disk12 type xfs (rw,nobarrier)

ठीक है, मैंने ट्यून स्थापित करने की कोशिश की और इसे थ्रूपुट प्रदर्शन के लिए सेट किया है।

[root@dn07.domain.com ~]# tuned-adm profile throughput-performance
Switching to profile 'throughput-performance'
Applying deadline elevator: sda sdb sdc sdd sde sdf sdg sdh[  OK  ] sdk sdl sdm
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf:                                [  OK  ]
Calling '/etc/ktune.d/tunedadm.sh start':                  [  OK  ]
Applying sysctl settings from /etc/sysctl.d/99-chef-attributes.conf
Applying sysctl settings from /etc/sysctl.conf
Starting tuned:                                            [  OK  ]

क्या आप सर्वर वातावरण के बारे में जानकारी प्रदान कर सकते हैं? ओएस वितरण और संस्करण, हार्डवेयर प्लेटफॉर्म प्रासंगिक होगा।
ewwhite

आपका सिस्टम उस समय लोड होता है जब ऐसा होता है।
ewwhite

मैंने ऐनक के साथ कुछ संपादन किए और लोड क्या है
माइक

mountजैसा दिखता है उसका आउटपुट क्या है ?
ewwhite

बहुत अच्छा। tuned-adm profile enterprise-storageNobarrier और समय सीमा स्विच को संभालने के लिए कमांड का उपयोग करने पर विचार करें । dmesg|tailआउटपुट क्या दिखाता है? क्या आप I / O टाइमआउट देख रहे हैं?
इविविट

जवाबों:


8

सामान्य तौर पर, मैंने यह देखा है कि एक रुका हुआ-पढ़ने के कारण ऐसा होता है। यह आपके straceआउटपुट द्वारा पुष्टि की जाती है । ps auxकमांड चलाते समय / xxxx / cmdline फाइल को पढ़ने / खरीदने का प्रयास लटका रहता है ।

I / O में क्षणिक स्पाइक्स सिस्टम के संसाधनों को भुना रहे हैं। 90-160 का लोड बेहद बुरी खबर है अगर यह स्टोरेज सबसिस्टम से संबंधित है।

संग्रहण सरणी के लिए, क्या आप हमें बता सकते हैं कि क्या कोई हार्डवेयर RAID नियंत्रक है? सर्वर राइट-बायस्ड पर प्राथमिक अनुप्रयोग है? आपके द्वारा उल्लिखित डिस्क (12 x 4TB) एसएएस या एसएटीए डिस्क के पास कम गति वाली हैं। अगर ड्राइव अरै के सामने राइटिंग कैशिंग का कोई रूप नहीं है , तो लिखता है सिस्टम लोड तरीका ऊपर धकेलने में सक्षम है। यदि ये सुपरमाइक्रो बैकप्लेन पर शुद्ध SATA ड्राइव हैं, तो अन्य डिस्क समस्याओं ( टाइमआउट, फेलिंग ड्राइव, बैकप्लेन, आदि ) की संभावना को छूट न दें ) क्या यह सभी Hadoop नोड्स पर होता है?

एक आसान परीक्षण iotopयह हो रहा है जबकि चलाने की कोशिश करना है। इसके अलावा, चूंकि यह EL6.5 है, क्या आपके पास कोई tuned-admसेटिंग सक्षम है? क्या लेखन अवरोध सक्षम हैं?

यदि आपने सर्वर का I / O एलीवेटर नहीं बदला है, ioniceतो इसका प्रभाव पड़ सकता है। यदि आपने इसे CFQ के अलावा किसी अन्य चीज़ में बदल दिया है , ( यह सर्वर संभवतः समय सीमा पर होना चाहिए ), ioniceतो इससे कोई फ़र्क नहीं पड़ेगा।

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

एक और अजीब बात है जो मैंने उत्पादन वातावरण में देखी है। ये जावा प्रक्रियाएं हैं, और मुझे लगता है कि वे बहुत अधिक मल्टीथ्रेडेड हैं। आप पीआईडी ​​पर कैसे कर रहे हैं? Kernel.pid_max का sysctlमान क्या है ? मेरे पास ऐसी परिस्थितियां हैं जहां मैंने पहले पीआईडी ​​को समाप्त कर दिया है और जिसके परिणामस्वरूप उच्च भार है।

इसके अलावा, आप कर्नेल संस्करण 2.6.32-358.23.2.el6.x86_64 का उल्लेख करते हैं । यह एक वर्ष से अधिक पुराना है और CentOS 6.4 रिलीज का हिस्सा है, लेकिन आपके बाकी सर्वर 6.5 हैं। क्या आपने yum.conf में कर्नेल अपडेट को ब्लैकलिस्ट किया था? आपको संभवतः उस सिस्टम के लिए कर्नेल 2.6.32-431.xx या नया होना चाहिए। आपके पास पुराने कर्नेल के साथ एक बहुत बड़ा मुद्दा हो सकता है । यदि आप कर्नेल को नहीं बदल सकते हैं, तो उन्हें अक्षम करने का प्रयास करें:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled


एक छापे कार्ड है, लेकिन इसका इस्तेमाल सर्वर पर 12 ड्राइव को संभालने के लिए किया जाता है। Hadoop क्लस्टर का इसका एक भाग है इसलिए यह बहुत अधिक लेखन करता है लेकिन ये लॉक अप भी तब आते हैं जब यार्न मानचित्र को कम करने के लिए बहुत सारा डेटा खींच रहा होता है।
माइक

मुझे यह देखने के लिए कॉल करने के लिए डेटासेंटर मिल रहा है कि क्या वे जानते हैं कि कैश लिखने के लिए छापा नियंत्रक क्या सेट है। कार्ड के लिए एक 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID मैं सत्यापित वे SATA ड्राइव भी हैं Western Digital WD RE WD4000FYYZ
माइक

1
@ माइक यदि आप कर्नेल परिवर्तन नहीं कर सकते हैं, तो कोशिश करें: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledएक प्रभावित मशीन पर। मैं मान रहा हूँ कि यह काफी प्रतिलिपि प्रस्तुत करने योग्य है जिसे आप इस सेटिंग से पहले / बाद में देख सकते हैं।
इविविट

4
देखते हैं और विशाल पृष्ठ को अक्षम करने से समस्या को ठीक करने में मदद मिलती है!
माइक

1
@ बहुत बढ़िया। कर्नेल अद्यतन भी कुछ राहत प्रदान कर सकता है। लेकिन अगर आप रनिंग कर्नेल के साथ फंस गए हैं, तो मुझे खुशी है कि यह फिक्स काम करता है।
ewwhite

3

समस्या स्पष्ट है डिस्क से संबंधित समस्या नहीं। और यह लटकी हुई धारा से स्पष्ट है:

open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

/ proc कर्नेल और यूजरस्पेस के बीच एक इंटरफेस है। यह डिस्क को बिल्कुल भी नहीं छूता है। अगर किसी चीज को कमांड के तर्कों को पढ़ते हुए लटका दिया जाता है तो यह आमतौर पर एक कर्नेल से संबंधित समस्या होती है, और स्टोरेज की संभावना नहीं होती है। @Kasperd टिप्पणी देखें।

लोड समस्या का केवल एक साइड इफेक्ट है और उच्च संख्या पूरी कहानी नहीं बताती है। आपके पास बहुत अधिक लोड वाला एक सर्वर हो सकता है जिस पर एप्लिकेशन बिना किसी गड़बड़ के व्यवहार करता है।

आप इस बारे में अधिक जानकारी प्राप्त कर सकते हैं कि क्या हो रहा है cat /proc/$PID/stack$PIDप्रक्रिया आईडी कहां है जहां रीड स्टॉल है।

आपके मामले में मैं एक कर्नेल उन्नयन के साथ शुरू करूँगा।


2
आप गलत कर रहे हैं। पढ़ने के द्वारा जो लौटाया जाता /proc/%d/cmdlineहै वह प्रक्रिया के पते की जगह का हिस्सा है जिसमें कर्नेल ने execveकॉल के दौरान कमांड लाइन संग्रहीत की है । उपयोगकर्ता स्थान के किसी भी अन्य भाग की तरह इसे भी स्वैप किया जा सकता है। इसलिए इसे एक्सेस करने पर पेज को फिर से स्वैप करने के लिए इंतजार करना पड़ सकता है।
कास्परड

यह बहुत अच्छा तर्क है। ऊपर उठने के लिए धन्यवाद। हालांकि मुझे लगता है कि आपके स्वैप का जवाब नहीं देने पर स्ट्रेस की संभावना कम है, लेकिन असंभव नहीं है। मैं अपना जवाब अपडेट करूंगा।
Mircea Vutcovici

2

तो भी सभी tweaks और नवीनतम 2.6 कर्नेल के उन्नयन के साथ जो कि CentOS प्रदान करता है हम अभी भी हैंग देख रहे थे। पहले जितना नहीं लेकिन फिर भी उन्हें देखकर।

यह फ़र्क 3.10.x श्रृंखला कर्नेल में अपग्रेड करने के लिए था जो कि CentOS द्वारा उनके सेंटोसप्लस रेपो में यहाँ प्रदान किया गया है

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/

यह सभी प्रक्रिया के साथ दूर हो गया है पेड़ हैंग हो जाता है। जैसा कि मैंने कहा कि सिस्टम किसी भी पागल भार के अधीन नहीं था जहाँ नई प्रक्रियाएँ चलाना दुःखद नहीं था। तो सबसे कहीं एक 2.6 कर्नेल मुद्दा हो।


0

यह एक और फिक्स है।

लगता है कि हम निम्नलिखित छापे नियंत्रक चला रहे हैं

Adaptec 71605

मैं नवीनतम संस्करण के लिए सभी प्रभावित मशीनों के लिए फर्मवेयर अद्यतन कर रहा हूँ और यह समस्या को साफ करने लगता है।

CentOS 6 पर 3.10 स्थापित करने वाले अन्य यादृच्छिक मुद्दों के कारण हमें 3.10 कर्नेल प्रयोग से नीचे आना पड़ा, लेकिन फर्मवेयर अपग्रेड इस समस्या को ठीक करने के लिए लगता है।

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