জাভা প্রসেস সহ উচ্চ সিপিইউ / আইওতে ঝুলছে PS অক্স


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 কোর ইন্টেল (আর) জিয়ন (আর) সিপিইউ E5-2650 0 @ 2.00GHz
  • 128gig মেষ
  • 12 4Tb 7200 ড্রাইভ
  • CentOS 6.5
  • আমি নিশ্চিত নই যে মডেল তবে বিক্রেতা সুপার মাইক্রো

এটি যখন ঘটে তখন লোডটি 1 মিনিটের জন্য 90-160 এর কাছাকাছি।

বিজোড় অংশটি হ'ল আমি অন্য কোনও / প্রোক / পিড # তে যেতে পারি এবং এটি ঠিক কাজ করে। আমি যখন প্রবেশ করি তখন সিস্টেমটি প্রতিক্রিয়াশীল Like

অন্য একটি সম্পাদনা

আমি সময়সূচীর জন্য সময়সীমা ব্যবহার করছি

[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  ]

আপনি সার্ভার পরিবেশের উপর তথ্য সরবরাহ করতে পারেন? ওএস বিতরণ এবং সংস্করণ, হার্ডওয়্যার প্ল্যাটফর্ম প্রাসঙ্গিক হবে।
ew white

যখন এটি ঘটে তখন আপনার সিস্টেমের লোডটিও গুরুত্বপূর্ণ।
ew white

আমি চশমা এবং লোডটি কী তা দিয়ে কিছু সম্পাদনা করেছি
মাইক 15

আউটপুট mountদেখতে কেমন?
ew

খুব ভালো. tuned-adm profile enterprise-storageনোবারিয়ার এবং ডেডলাইন স্যুইচটি পরিচালনা করতে কমান্ডটি ব্যবহারের বিষয়ে বিবেচনা করুন । dmesg|tailআউটপুট কি দেখায়? আপনি কি I / O টাইমআউটগুলি দেখছেন?
ew white

উত্তর:


8

সাধারণভাবে, আমি স্থির-পড়া কারণে এই ঘটনাটি দেখেছি। এটি আপনার straceআউটপুট দ্বারা নিশ্চিত করা হয়েছে । আপনি যখন ps auxকমান্ডটি চালাচ্ছেন তখন / proc / xxxx / cmdline ফাইলটি পড়ার প্রচেষ্টা স্তব্ধ হয়ে যায় ।

আই / ও-এর ক্ষণিকের স্পাইকগুলি সিস্টেমের সংস্থানগুলিতে অনাহারী। 90-160 একটি লোড এটি অত্যন্ত খারাপ খবর, যদি এটি স্টোরেজ সাবসিস্টেম সম্পর্কিত।

স্টোরেজ অ্যারেটির জন্য, যদি সেখানে কোনও হার্ডওয়্যার র‌্যাড নিয়ামক রয়েছে তা কি আপনি আমাদের বলতে পারেন? সার্ভারে প্রাথমিক অ্যাপ্লিকেশনটি কি লেখার পক্ষপাতদুষ্ট? আপনি যে ডিস্কগুলি উল্লেখ করেছেন (12 x 4TB) হ'ল নিম্ন গতির নিকটবর্তী এসএএস বা SATA ডিস্কগুলি। ড্রাইভ অ্যারের সামনে লেখার ক্যাশে দেওয়ার কোনও ফর্ম না থাকলে , লেখাগুলি সিস্টেম লোডের পথে এগিয়ে যেতে সক্ষম। এগুলি যদি একটি সুপারমাইক্রো ব্যাকপ্লেনের খাঁটি এসএটিএ ড্রাইভ হয় তবে অন্যান্য ডিস্ক সমস্যার সম্ভাবনা ( টাইমআউটস, ব্যর্থ ড্রাইভ, ব্যাক প্লেন ইত্যাদি ) ছাড়বেন না সমস্ত হ্যাডোপ নোডগুলিতে কি এটি ঘটে?

একটি সহজ পরীক্ষা হচ্ছে এটি হওয়ার iotopসময় চালানোর চেষ্টা করা । এছাড়াও, যেহেতু এটি EL6.5, তাই আপনার কি কোনও tuned-admসেটিংস সক্ষম আছে? লেখার বাধা কী সক্ষম?

আপনি যদি সার্ভারের I / O লিফটটি পরিবর্তন না করেন তবে তার ioniceপ্রভাব থাকতে পারে। আপনি যদি এটিকে সিএফকিউ ব্যতীত অন্য কোনও কিছুতে পরিবর্তন করেছেন , ( এই সার্ভারটি সম্ভবত শেষ সময়সীমাতে থাকা উচিত ), ioniceকোনও পার্থক্য করবে না।

সম্পাদনা:

উত্পাদনের পরিবেশে আমি আর একটি অদ্ভুত জিনিস দেখেছি। এগুলি জাভা প্রক্রিয়াগুলি, এবং আমি ধরে নেব যে সেগুলি প্রচুর পরিমাণে বহুবিধ পড়েছে। আপনি পিআইডি-তে কী করছেন? কার্নেল.পিড_ম্যাক্সেরsysctl মান কী ? আমি এমন পরিস্থিতিতে পড়েছি যেখানে আগে আমি পিআইডি ক্লান্ত করেছি এবং ফলস্বরূপ উচ্চ চাপ ছিল।

এছাড়াও, আপনি কার্নেল সংস্করণটি উল্লেখ করেছেন 2.6.32-358.23.2.el6.x86_64 । এটি এক বছরেরও বেশি পুরানো এবং সেন্টোস 6.4 প্রকাশের অংশ, তবে আপনার সার্ভারের বাকী অংশ 6.5। আপনি কি yum.conf এ কার্নেল আপডেটগুলি কালো তালিকাভুক্ত করেছেন? আপনার সম্ভবত সম্ভবত কার্নেল ২.6.৩২-৪31১.১xx এক্স বা এই সিস্টেমের জন্য আরও নতুন হওয়া উচিত। আপনার কাছে থাকা পুরানো কার্নেলটির সাথে একটি হিটপেইজ সমস্যা থাকতে পারে । আপনি যদি কার্নেলটি পরিবর্তন করতে না পারেন তবে এগুলি দিয়ে অক্ষম করার চেষ্টা করুন:

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


একটি রাইড কার্ড আছে তবে এটি সার্ভারে 12 ড্রাইভ পরিচালনা করার জন্য ব্যবহৃত হয়েছে। এর একটি হডোপ ক্লাস্টারের অংশ তাই এটি প্রচুর লেখালেখি করে তবে এই লক আপগুলি তখনও আসে যখন কোনও মানচিত্রের জন্য কাজের পরিমাণ হ্রাস করার জন্য সুতা প্রচুর ডেটা টানছে।
মাইক 15

ক্যাশে লেখার জন্য রেড কন্ট্রোলার কী সেট করেছে তা তারা জানে কিনা তা জানতে আমাকে কল করার জন্য আমি ডেটাসেন্টার পাচ্ছি। কার্ড হিসাবে এটির জন্য 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID আমি একটি যাচাই করেছি তারা Western Digital WD RE WD4000FYYZ
মাইক

1
@ মাইক আপনি যদি কার্নেল পরিবর্তন করতে না পারেন তবে চেষ্টা করুন: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledএকটি প্রভাবিত মেশিনে on আমি ধরে নিচ্ছি যে এটি যথেষ্ট প্রজননযোগ্য যা আপনি এই সেটিংটির আগে / পরে পর্যবেক্ষণ করতে পারবেন।
ew

4
দেখে মনে হচ্ছে টিউন করা এবং বিশাল পৃষ্ঠাটি অক্ষম করা সমস্যার সমাধান করতে সহায়তা করেছে!
মাইক 16

1
পছন্দ করুন কার্নেল আপডেটে কিছুটা স্বস্তিও পাওয়া যায়। তবে আপনি যদি চলমান কার্নেলটির সাথে আটকে থাকেন তবে আমি আনন্দিত যে এই ফিক্সটি কাজ করে।
ew white

3

ডিস্ক সম্পর্কিত সমস্যা নয় সমস্যাটি স্পষ্ট। এবং এটি ফাঁসি স্ট্রেস থেকে পরিষ্কার:

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

/ proc হল কার্নেল এবং ইউজারস্পেসের মধ্যে একটি ইন্টারফেস। এটি ডিস্কটি মোটেই স্পর্শ করে না। কোনও আদেশ যদি কমান্ডের যুক্তিগুলি পড়তে ঝুলানো হয় তবে এটি সাধারণত কার্নেল সম্পর্কিত সমস্যা এবং কোনও স্টোরেজ হওয়ার সম্ভাবনা থাকে না। @ ক্যাস্পার্ড মন্তব্য দেখুন।

বোঝা সমস্যার কেবলমাত্র একটি পার্শ্ব প্রতিক্রিয়া এবং উচ্চ সংখ্যাটি পুরো গল্পটি বলে না। আপনার কাছে খুব বেশি লোড সহ এমন একটি সার্ভার থাকতে পারে যার উপর অ্যাপ্লিকেশনটি কোনও ত্রুটি ছাড়াই আচরণ করে।

আপনি কী নিয়ে যাচ্ছেন সে সম্পর্কে আরও তথ্য অর্জন করতে পারেন cat /proc/$PID/stack। কোথায় $PIDপ্রসেস ID যেখানে পঠিত স্টল রয়েছে।

আপনার ক্ষেত্রে আমি কার্নেল আপগ্রেড দিয়ে শুরু করব।


2
তুমি ভুল করছ. পড়ার মাধ্যমে যা ফিরে আসে তা হ'ল /proc/%d/cmdlineপ্রক্রিয়াটির ঠিকানার জায়গার অংশ যেখানে execveকল করার সময় কার্নেল কমান্ড লাইনটি সংরক্ষণ করে । ব্যবহারকারীর স্থানের অন্য কোনও অংশের মতো এটিও অদলবদল হতে পারে। সুতরাং এটি অ্যাক্সেস করার জন্য পৃষ্ঠাটি আবার অদলবদলের জন্য অপেক্ষা করতে হতে পারে।
ক্যাস্পারড

এটি একটি খুব ভাল যুক্তি। ওঠার জন্য আপনাকে ধন্যবাদ। তবে আমি মনে করি যে যখন আপনার সোয়াপটি উত্তর দিচ্ছে না তখন স্ট্রেসের সম্ভাবনা কম, তবে অসম্ভব নয়। আমি আমার উত্তর আপডেট করব।
মিরসিয়া ভুটকোভিচি

2

সুতরাং এমনকি সমস্ত টুইট এবং সর্বশেষতম 2.6 কার্নেলের একটি আপগ্রেড সহ যা সেন্টোস সরবরাহ করে যা আমরা এখনও হ্যাঙ্গগুলি দেখছিলাম। আগের মতো নয় তবুও তাদের দেখে them

ফিক্সটি ছিল সেন্টোসগুলি তাদের সেন্টোস্প্লাস রেপোতে সরবরাহ করে এমন 3.10.x সিরিজের কার্নেলটিতে আপগ্রেড করার

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

এটি সমস্ত প্রক্রিয়া গাছের ঝুলিয়ে ফেলেছে। যেমন আমি বলেছিলাম যে সিস্টেমটি কোনও উন্মাদ বোঝার অধীনে নয় যেখানে নতুন প্রক্রিয়াগুলি চালানো মোটেই সহজ নয়। সুতরাং বেশিরভাগ কোথাও একটি 2.6 কার্নেল সমস্যা হতে পারে।


0

এটি অন্য একটি সমাধান।

দেখে মনে হচ্ছে আমরা নিম্নলিখিত রাইড কন্ট্রোলারটি চালাচ্ছি

Adaptec 71605

আমি সমস্ত আক্রান্ত মেশিনগুলিতে সর্বশেষ সংস্করণে ফার্মওয়্যার আপডেট করছি এবং এটি সমস্যাটি পরিষ্কার করছে বলে মনে হচ্ছে।

CentOS 6 এ 3.10 ইনস্টল করার অন্যান্য এলোমেলো সমস্যাগুলির কারণে আমাদের 3.10 কার্নেল পরীক্ষা থেকে ডাউনগ্রেড করতে হয়েছিল তবে ফার্মওয়্যার আপগ্রেড সমস্যার সমাধান করতে পারে বলে মনে হচ্ছে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.