linux - কি আমার প্রক্রিয়া হত্যা এবং কেন?
process kill (9)
আমাকে প্রথমে ওমিলারকে কেন এবং কেন আহ্বান জানাতে হবে?
বলুন আপনার 512 র্যাম + 1 জিবি সোয়াপ মেমরি আছে। সুতরাং তত্ত্ব অনুসারে, আপনার সিপিইউটিতে মোট 1.5 গিগাবাইট ভার্চুয়াল মেমরি অ্যাক্সেস রয়েছে।
এখন, কিছু সময়ের জন্য সবকিছু মোট মেমরি 1.5 গিগাবাইট মধ্যে জরিমানা চলমান। কিন্তু হঠাৎ (বা ধীরে ধীরে) আপনার সিস্টেমটি আরও বেশি মেমরি খাওয়া শুরু করেছে এবং এটি ব্যবহৃত মোট মেমরির 95% প্রায় একটি পয়েন্টে পৌঁছেছে।
এখন যে কোনও প্রক্রিয়া কার্নেল থেকে মেমরির বড় চুককে অনুরোধ করেছে। উপলব্ধ মেমরির জন্য কার্নেল চেক করুন এবং এটি আপনার প্রসেসকে আরও মেমরি বরাদ্দ করতে পারে এমন কোন উপায় নেই। তাই এটি কিছু মেমরি কলিং / OOMKiller invoking ( http://linux-mm.org/OOM ) মুক্ত করার চেষ্টা করবে।
OOMKiller প্রতিটি প্রক্রিয়া জন্য র্যাঙ্ক স্কোর তার নিজস্ব অ্যালগরিদম আছে। সাধারণত যা প্রক্রিয়া আরো মেমরি ব্যবহার করা হত শিকার শিকার হয়ে।
আমি OOMKiller এর লগ কোথায় পাব?
সাধারণত / var / লগ ডিরেক্টরির মধ্যে। হয় /var/log/kern.log অথবা / var / log / dmesg
আশা করি এটা তোমাকে সাহায্য করবে।
কিছু সাধারণ সমাধান:
- মেমরি বাড়ান (স্য্যাপ নয়)
- আপনার প্রোগ্রামে মেমরি লিক খুঁজুন এবং তাদের ঠিক করুন
- মেমরি সীমাবদ্ধ করুন কোনও প্রক্রিয়া গ্রাস করতে পারে (উদাহরণস্বরূপ JVM মেমরি জাভা_OPTS ব্যবহার করে সীমিত করা যেতে পারে)
- লগ এবং গুগল দেখুন :)
আমার অ্যাপ্লিকেশন লিনাক্সে একটি ব্যাকগ্রাউন্ড প্রক্রিয়া হিসাবে সঞ্চালিত হয়। এটি বর্তমানে একটি টার্মিনাল উইন্ডোতে কমান্ড লাইনে শুরু হয়।
সম্প্রতি একজন ব্যবহারকারী কিছুক্ষণের জন্য আবেদনটি কার্যকর করছিলেন এবং এটি রহস্যজনকভাবে মারা গিয়েছিল। পাঠ্য:
নিহত
টার্মিনালে ছিল। এই দুই বার ঘটেছে। আমি জিজ্ঞেস করলাম, কেউ যদি অন্য কোন টার্মিনাল ব্যবহার করে হত্যাকান্ডটি ব্যবহার করে হত্যা করে? না।
লিনাক্স কীভাবে আমার প্রক্রিয়া হত্যা করার সিদ্ধান্ত নেবে? আমি বিশ্বাস করি শেল প্রদর্শিত "হত্যা" কারণ হত্যা (9) সংকেত প্রাপ্তির পরে প্রক্রিয়া মারা গেছে। যদি লিনাক্স পাঠানো হত তবে সেটি কোনও সিস্টেমে লগ ইন একটি বার্তা হতে পারে যা ব্যাখ্যা করে যে এটি কেন হত্যা করা হয়েছিল?
Systemtap (অথবা একটি ট্রেসার) মত একটি টুল কার্নেল সিগন্যাল-ট্রান্সমিশন লজিক এবং রিপোর্ট পর্যবেক্ষণ করতে পারে। উদাহরণস্বরূপ, https://sourceware.org/systemtap/examples/process/sigmon.stp
# stap .../sigmon.stp -x 31994 SIGKILL
SPID SNAME RPID RNAME SIGNUM SIGNAME
5609 bash 31994 find 9 SIGKILL
যে স্ক্রিপ্ট ব্লক ফিল্টারিং স্বাদ সমন্বয় করা যেতে পারে, অথবা systemwide সংকেত ট্রাফিক ট্রেস মুছে ফেলা। কারণগুলি ব্যাকট্র্যাক সংগ্রহ করে আরও পৃথক করা print_backtrace()
print_ubacktrace()
এবং ব্যবহারকারীর অবস্থানের জন্য print_backtrace()
একটি print_backtrace()
এবং / অথবা print_ubacktrace()
)।
আমি সাম্প্রতিক এই সমস্যা সম্মুখীন। অবশেষে, আমি দেখলাম আমার প্রসেসগুলি খালি হয়ে যাওয়ার পরেই জাইপার আপডেট স্বয়ংক্রিয়ভাবে ডাকা হয়েছিল। Zypper আপডেট অক্ষম আমার সমস্যা সমাধান।
এই লিনাক্স আউট মেমরি ম্যানেজার (ওওএম) । আপনার প্রক্রিয়াটি ' মন্দতা ' এর কারণে নির্বাচিত হয়েছিল - সাম্প্রতিকতার সমন্বয়, আবাসিক আকার (কেবল বরাদ্দ করার পরিবর্তে ব্যবহারযোগ্য মেমরি) এবং অন্যান্য কারণগুলি।
sudo journalctl -xb
আপনি একটি বার্তা দেখতে পাবেন:
Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU 0: hi: 186, btch: 31 usd: 30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
active_file:722 inactive_file:4126 isolated_file:0
unevictable:0 dirty:5 writeback:0 unstable:0
free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
mapped:792 shmem:12802 pagetables:1651 bounce:0
free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [ 241] 0 241 13581 1610 26 0 0 systemd-journal
Jul 20 11:05:00 someapp kernel: [ 246] 0 246 10494 133 22 0 -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [ 264] 0 264 29174 121 26 0 -1000 auditd
Jul 20 11:05:00 someapp kernel: [ 342] 0 342 94449 466 67 0 0 NetworkManager
Jul 20 11:05:00 someapp kernel: [ 346] 0 346 137495 3125 88 0 0 tuned
Jul 20 11:05:00 someapp kernel: [ 348] 0 348 79595 726 60 0 0 rsyslogd
Jul 20 11:05:00 someapp kernel: [ 353] 70 353 6986 72 19 0 0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [ 362] 70 362 6986 58 18 0 0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [ 378] 0 378 1621 25 8 0 0 iprinit
Jul 20 11:05:00 someapp kernel: [ 380] 0 380 1621 26 9 0 0 iprupdate
Jul 20 11:05:00 someapp kernel: [ 384] 81 384 6676 142 18 0 -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [ 385] 0 385 8671 83 21 0 0 systemd-logind
Jul 20 11:05:00 someapp kernel: [ 386] 0 386 31573 153 15 0 0 crond
Jul 20 11:05:00 someapp kernel: [ 391] 999 391 128531 2440 48 0 0 polkitd
Jul 20 11:05:00 someapp kernel: [ 400] 0 400 9781 23 8 0 0 iprdump
Jul 20 11:05:00 someapp kernel: [ 419] 0 419 27501 32 10 0 0 agetty
Jul 20 11:05:00 someapp kernel: [ 855] 0 855 22883 258 43 0 0 master
Jul 20 11:05:00 someapp kernel: [ 862] 89 862 22926 254 44 0 0 qmgr
Jul 20 11:05:00 someapp kernel: [23631] 0 23631 20698 211 43 0 -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884] 0 12884 81885 3754 80 0 0 firewalld
Jul 20 11:05:00 someapp kernel: [18130] 0 18130 33359 291 65 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18132] 1000 18132 33791 748 64 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18133] 1000 18133 28867 122 13 0 0 bash
Jul 20 11:05:00 someapp kernel: [18428] 99 18428 208627 42909 151 0 0 node
Jul 20 11:05:00 someapp kernel: [18486] 89 18486 22909 250 46 0 0 pickup
Jul 20 11:05:00 someapp kernel: [18515] 1000 18515 352905 141851 470 0 0 npm
Jul 20 11:05:00 someapp kernel: [18520] 0 18520 33359 291 66 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18522] 1000 18522 33359 294 64 0 0 sshd
Jul 20 11:05:00 someapp kernel: [18523] 1000 18523 28866 115 12 0 0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB
এটি এই বিষয়ে একটি ভাল নিবন্ধের মত দেখাচ্ছে: OOM killer টিমিং ।
লিস্ট লিনাক্স মেমরি overcommits হয় । যখন কোন প্রক্রিয়া আরো স্থান চাওয়া হয়, তখন লিনাক্স এটি স্থানটি দেবে, এমনকি যদি এটি অন্য প্রক্রিয়া দ্বারা দাবি করা হয় তবে অনুমান অনুযায়ী যে কেউ প্রকৃতপক্ষে যে সমস্ত মেমরি তারা চায় সেগুলি ব্যবহার করে না। প্রক্রিয়াটি যখন এটি ব্যবহার করে তখন এটি বরাদ্দ করা মেমরির একচেটিয়া ব্যবহার পাবে, এটি যখন এটি জিজ্ঞাসা করবে তখন নয়। এটি দ্রুত বরাদ্দ করে এবং আপনাকে "প্রতারণা" করার অনুমতি দেয় এবং প্রকৃতপক্ষে আপনার চেয়ে বেশি মেমরি বরাদ্দ করতে পারে। তবে, একবার এই মেমরিটি ব্যবহার করার প্রক্রিয়াগুলি শুরু হয়ে গেলে, লিনাক্স বুঝতে পারে যে এটির মেমরি বরাদ্দ করা খুব বেশি উদার ছিল না, এবং কিছু মুক্ত করার জন্য একটি প্রক্রিয়া বন্ধ করতে হবে। নিহত হওয়ার প্রক্রিয়াটি রান রানটাইম (দীর্ঘ-চলমান প্রক্রিয়াগুলি নিরাপদ) বিবেচনা করে একটি স্কোরের উপর ভিত্তি করে, মেমরির ব্যবহার (লোভী প্রক্রিয়াগুলি কম নিরাপদ) এবং কয়েকটি অন্যান্য কারণ রয়েছে যার মধ্যে একটি প্রক্রিয়া কম করার জন্য আপনি সামঞ্জস্য করতে পারেন সম্ভবত হত্যা করা হবে। এটা সব অনেক বিস্তারিত নিবন্ধে বর্ণিত।
সম্পাদনা করুন: এবং এখানে এমন একটি নিবন্ধ রয়েছে যা বেশ ভালভাবে ব্যাখ্যা করে যে কীভাবে একটি প্রক্রিয়া নির্বাচন করা হয় (কিছু কার্নেল কোড উদাহরণের সাথে টীকা দেওয়া হয়েছে)। এই সম্পর্কে মহান জিনিসটি বিভিন্ন badness()
নিয়মগুলির পিছনে যুক্তি নিয়ে কিছু মন্তব্য অন্তর্ভুক্ত করে।
চেষ্টা করুন:
dmesg -T| grep -E -i -B100 'killed process'
কোথায়- -B100
আগে লাইন সংখ্যা চিহ্নিত করে।
ম্যাক অপারেটিং সিস্টেম এমিট-টি ।
যদি ব্যবহারকারী বা sysadmin প্রোগ্রামটি মারতে না পারে তবে কার্নেলটি থাকতে পারে। কার্নেল শুধুমাত্র চরম সম্পদ ক্ষুধা (মনে মেম + সোয়াপ ক্লান্তি) হিসাবে ব্যতিক্রমী পরিস্থিতিতে একটি প্রক্রিয়া হত্যা করবে।
যেমন ডিভিসি এবং অ্যাডাম জাস্কুইচিক্স বলেছেন, অপরাধী সম্ভবত ওওএম হত্যাকারী। যাইহোক, পরবর্তী প্রশ্নটি অনুসরণ করা হল: আমি এটিকে কিভাবে প্রতিরোধ করব?
বিভিন্ন উপায় আছে:
- যদি আপনি করতে পারেন তবে আপনার সিস্টেমে আরও RAM দিন (এটি একটি ভিএমের পক্ষে সহজ)
- OOM হত্যাকারী একটি ভিন্ন প্রক্রিয়া চয়ন করুন তা নিশ্চিত করুন।
- OOM হত্যাকারী নিষ্ক্রিয় করুন
- একটি লিনাক্স ডিস্ট্রো নির্বাচন করুন যা OOM Killer দ্বারা জাহাজ নিষ্ক্রিয়।
আমি পাওয়া (2) বাস্তবায়ন করা বিশেষ করে সহজ, এই নিবন্ধ ধন্যবাদ।
সম্পদের সীমাবদ্ধ করার জন্য PAM মডিউলটি আপনার বর্ণনাগুলির ফলাফলগুলি ঠিক করেছে: কনসোল উইন্ডোতে নিহত হওয়া পাঠ্য সহ আমার প্রক্রিয়া রহস্যজনকভাবে মারা গেছে। কোন লগ আউটপুট, না syslog মধ্যে nor kern.log মধ্যে । top প্রোগ্রামটি আমাকে আবিষ্কার করতে সাহায্য করেছিল যে CPU এর এক মিনিটের ঠিক পরেই আমার প্রক্রিয়াটি মারা যায়।