প্রচুর পরিমাণে নিখরচায় (?) র‌্যামের সাহায্যে ওম হত্যাকারী জিনিসগুলি হত্যা করছে


11

OOM হত্যাকারী আমার সিস্টেমে পর্যাপ্ত ফ্রি র্যাম থাকা সত্ত্বেও জিনিসগুলি হত্যা করছে বলে মনে হচ্ছে:

স্মৃতি ব্যবহার গ্রাফ (পূর্ণ রেজল্যুশন)

আইও ব্যবহারের গ্রাফ (পূর্ণ রেজল্যুশন)

27 মিনিট এবং 408 প্রক্রিয়াগুলি পরে, সিস্টেমটি আবার প্রতিক্রিয়া শুরু করে। আমি প্রায় এক ঘন্টা পরে এটি পুনরায় বুট করেছিলাম এবং এরপরেই মেমরির ব্যবহারটি স্বাভাবিক (এই মেশিনটির জন্য) ফিরে আসে।

পরিদর্শন করার পরে, আমি আমার বাক্সে কয়েকটি আকর্ষণীয় প্রক্রিয়া পেয়েছি:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

এই নির্দিষ্ট সার্ভারটি প্রায় চলমান রয়েছে। 8 ঘন্টা, এবং এগুলি হ'ল দুটি প্রক্রিয়া যা এরকম ... বিজোড় মান। আমার সন্দেহ হ'ল "অন্য কিছু" চলছে, এই অ-সংবেদনশীল মানগুলির সাথে সম্ভাব্য প্রাসঙ্গিক। সুনির্দিষ্টভাবে, আমি মনে করি যে সিস্টেমটি মনে করে যে এটি মেমরির বাইরে, যখন বাস্তবে, এটি তা নয়। সর্বোপরি, এটি মনে করে যে আরএসস্লগড 55383984% সিপিইউ ধারাবাহিকভাবে ব্যবহার করছে, যখন তাত্ত্বিকভাবে এই সিস্টেমে সর্বোচ্চ 400% হয়।

এটি 768 এমবি র‌্যামের সাথে সম্পূর্ণ আপ টু ডেট সেন্টোস 6 ইনস্টল (6.2)। কেন এটি হচ্ছে তা নির্ধারণের জন্য কোনও পরামর্শ প্রশংসিত হবে!

সম্পাদনা: ভিএম সংযুক্ত করা। sysctl tunables .. আমি অদলবদল নিয়ে খেলছি (এটি 100 এর দ্বারা স্পষ্ট হয়ে গেছে), এবং আমি একেবারে ভয়ানক স্ক্রিপ্টও চালাচ্ছি যা আমার বাফার এবং ক্যাশে ফেলে দেয় (vm.DP_cache দ্বারা স্পষ্ট করে 3) + প্রতিটি ডিস্ক সিঙ্ক করে 15 মিনিট. এই কারণেই রিবুট হওয়ার পরে, ক্যাশেড ডেটা কিছুটা স্বাভাবিক আকারে বেড়েছে, তবে তাড়াতাড়ি আবার বাদ পড়ে যায়। আমি স্বীকার করেছি যে ক্যাশে রাখা খুব ভাল জিনিস, তবে যতক্ষণ না আমি এই বিষয়টি আবিষ্কার করি ...

কিছুটা মজার বিষয় হ'ল ঘটনাটি চলাকালীন আমার পেজফাইলটি যখন বেড়েছে তখন এটি কেবলমাত্র সম্ভাব্য ব্যবহারের 20% ডলারে পৌঁছেছে, যা সত্য OOM ইভেন্টগুলির অপ্রচলিত। স্পেকট্রামের অন্য প্রান্তে, ডিস্ক একই সময়কালে একেবারে বাদাম হয়ে যায়, যা পেজফাইলে প্লে হয় যখন একটি OOM ইভেন্টের বৈশিষ্ট্য।

sysctl -a 2>/dev/null | grep '^vm':

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

সম্পাদনা করুন: এবং প্রথম OOM বার্তাটি সংযুক্ত করা হচ্ছে ... কাছাকাছি পরিদর্শন করার পরে, এটি বলেছে যে কিছু কিছু পরিষ্কারভাবে আমার অদলবদল স্পেসটিও পুরোপুরি খায়।

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

আপনি কি আউটপুট সরবরাহ করতে পারেন sysctl -a 2>/dev/null | grep '^vm'?
প্যাট্রিক

যোগ করা হয়েছে। আশা করি আপনি (বা কেউ) এমন কিছু খুঁজে পেতে পারেন যা আমি মিস করেছি।
কাইল ব্রেন্টলে

আমার দিকে ঝাঁপিয়ে পড়া একমাত্র জিনিসটি overcommit_memoryসেটিংস। এটিকে 1 এ সেট করা এই আচরণের কারণ হয়ে উঠতে পারে না, তবে এর আগে 'সর্বদা ওভারকমিট' হিসাবে সেট করার দরকার আমার আগে কখনও হয়নি, তাই খুব বেশি অভিজ্ঞতা নেই। আপনার যোগ হওয়া অন্যান্য নোটগুলির দিকে তাকিয়ে আপনি বলেছিলেন যে অদলবস্তিটি কেবলমাত্র 20% ব্যবহৃত হয়েছিল। তবে ওওএম লগ ডাম্প অনুসারে Free swap = 0kB,। এটি অবশ্যই ভেবেছিল যে অদলবদল 100% ব্যবহৃত হয়েছিল।
প্যাট্রিক

উত্তর:


13

আমি কেবল ওম লগ ডাম্পের দিকে চেয়েছিলাম এবং আমি সেই গ্রাফের যথার্থতা নিয়ে প্রশ্ন করি। প্রথম 'নোড 0 ডিএমএ 32' লাইনটি লক্ষ্য করুন। এটি বলে free:3376kB, min:3448kBএবং low:4308kB। যখনই নিখরচায় নিম্ন মানের নীচে নেমে আসে, কেএসপিডিপ যখন মানটি উচ্চ মানের থেকে উপরে না আসে ততক্ষণ জিনিসগুলি অদলবদল করা শুরু করার কথা। যখনই মিনিটের নিচে ফ্রি ড্রপ হয়, কার্নেলটি ন্যূনতম মানের থেকে উপরে ফিরে না পারা পর্যন্ত সিস্টেমটি মূলত হিমশীতল হয়। যে বার্তা এছাড়াও ইঙ্গিত করে যে সোয়াপ সম্পূর্ণরূপে ব্যবহার করা হয়েছিল এটা বলছেন যেখানে Free swap = 0kB
সুতরাং মূলত কেস্যাপড ট্রিগার করেছিল, তবে অদলবদু পূর্ণ ছিল, সুতরাং এটি কিছুই করতে পারে না, এবং পৃষ্ঠাগুলি_মুক্ত মান এখনও পৃষ্ঠাগুলি_মিন্য্য মানের নীচে ছিল, সুতরাং পৃষ্ঠাগুলি_ফ্রি ব্যাকআপ না পাওয়া পর্যন্ত জিনিসগুলিকে হত্যা করা একমাত্র বিকল্প ছিল।
আপনি স্পষ্টভাবে স্মৃতি হারিয়ে না।

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html কীভাবে এটি কাজ করে তার একটি দুর্দান্ত ব্যাখ্যা রয়েছে। নীচে 'বাস্তবায়ন' বিভাগটি দেখুন।


1
আমি তখন ওপি সত্যিই কেবল আরো র্যাম প্রয়োজন ...
ewwhite

আরও মেষ, বা এটি খাচ্ছে তা খুঁজে বার করুন।
প্যাট্রিক

আমি সেই গ্রাফটিতে লাইনগুলি খুব স্পষ্টভাবে রেখেছি। এটি প্রথম প্রক্রিয়াটি হত্যার আগে 1-2 মিলিয়ন ডলারে ডেটা লগিং বন্ধ করে দিয়েছিল এবং শেষটি নিহত হওয়ার পরে 4-5m ডলার পুনরায় লগিং শুরু করে। এই মুহুর্তে, আমি বাজি ধরে চলেছি যে কিছু প্রক্রিয়া একেবারে ধীরে ধীরে গিয়েছিল এবং আমার পেজফাইলে ছাঁটাই শুরু করে - অবশেষে সবকিছু পেয়ে গেলে এটি পেজফাইলে কার্যকরভাবে চলমান প্রক্রিয়াগুলিকে মেরে ফেলেছিল, এই কারণেই যখন ডেটা ফিরে আসে, পেজফাইলে উন্নত ছিল তবে পূর্ণ নয়। এটি কী করছে তা নির্ধারণের জন্য পরামর্শগুলি স্বাগত হবে!
কাইল ব্রেন্টলে

@ কাইলবারেন্টলে গ্রাফটি তৈরি করতে আপনি কোন মানটি টানছেন? লিনাক্স ভার্চুয়াল মেমরি সিস্টেমের একটি ডাউনসাইড হ'ল 'ফ্রি' এর কোনও নিবিড় সংজ্ঞা নেই। 'ফ্রি মেমরি' সংজ্ঞায়নের এক ডজন উপায় রয়েছে। Kswapd পর্যন্ত যে বিষয়টি গুরুত্বপূর্ণ তা হল পৃষ্ঠাগুলি_মুক্ত মূল্য। বিনামূল্যে অদলবদলের জন্য, আমি জানি না আপনি কী মূল্য পড়তে পারেন যা খুব দূরেই থাকবে। মেমোরিটি কী খাচ্ছে তা দেখার একমাত্র উপায় হ'ল বাক্সের সমস্ত প্রক্রিয়ার ক্রমাগত স্ন্যাপশটগুলি লগইন করা এবং যখন ওম কিলার বাদাম বাদ দেওয়া শুরু করে তখন সমস্ত স্মৃতি ব্যবহার করে কী তা দেখুন।
প্যাট্রিক

2
হ্যাঁ, আমি স্মৃতি থেকে দূরে। আমি লগগুলিতে গ্রিপিং আপ করেছিলাম তা জানতে আমার অ্যাপাচি চাইল্ড প্রসেসগুলি বারবার মারা যাচ্ছিল, যার ফলে আমি বুঝতে পেরেছিলাম যে আমার কার্যত অসীম শিশু প্রক্রিয়াগুলি শুরু হয়েছিল যা এটি শুরু হতে পারে । এটি যা গ্রহণ করেছিল তা হ'ল স্বয়ংক্রিয় ব্লগস্প্যাম বটগুলি প্রচুর অনুরোধ / সেকেন্ডে নিক্ষেপ করার জন্য হোস্টের কাছে পড়ে for ট্যুইকিং অ্যাপাচি সবকিছু সমাধান করেছে।
কাইল ব্রেন্টলে

3

ড্রপ_ক্যাচ স্ক্রিপ্ট থেকে মুক্তি পান। উপরন্তু, আপনি আপনার প্রাসঙ্গিক অংশ পোস্ট করা উচিত dmesgএবং /var/log/messagesকরা হলে OOM kills বার্তাগুলি প্রদর্শন আউটপুট।

যদিও এই আচরণটি বন্ধ করতে, আমি এই sysctlটিউনেবল চেষ্টা করার পরামর্শ দিই । এটি একটি RHEL / CentOS 6 সিস্টেম এবং স্পষ্টভাবে সীমাবদ্ধ সংস্থানগুলিতে চলছে। এটি কি ভার্চুয়াল মেশিন?

সংশোধন করার চেষ্টা করুন /proc/sys/vm/nr_hugepagesএবং দেখুন সমস্যাগুলি স্থির থাকে কিনা। এটি একটি মেমরি খণ্ডিত সমস্যা হতে পারে, তবে দেখুন এই সেটিংটি কোনও পার্থক্য করে কিনা। পরিবর্তনটি স্থায়ী করতে, vm.nr_hugepages = valueআপনার যুক্ত করুন /etc/sysctl.confএবং sysctl -pকনফিগারেশন ফাইলটি পুনরায় পড়তে চালনা করুন ...

আরও দেখুন: ক্রিপ্টিক কার্নেল "পৃষ্ঠা বরাদ্দ ব্যর্থতা" বার্তা ব্যাখ্যা করে


প্রথম ওম-হত্যাকারী বার্তা যুক্ত করা হয়েছে। যদিও মাইএসকিউএল আমি চালাচ্ছি সবচেয়ে র‌্যাম ইনটেনসিভ জিনিস, আমি বাক্সটি কাটিয়ে উঠতে না পেরে এটি টিউন করেছি, সুতরাং আমি যে পাগলিক মানগুলি উপরে দেখছি সেগুলি বাদ দিয়ে আমি সত্যিই সন্দেহ করছি না (5.1%) মেমরির ব্যবহার ভাল, সমস্ত বিষয় বিবেচনা করা হয়)। এটি একটি ভিপিএস, 768 এমবি র‌্যামের। আমি এনআর_হেজপেজগুলি পড়ব এবং এটিকে একটি শট দেব, ধন্যবাদ!
কাইল ব্রেন্টলে

@ হুইট বরাদ্দ করে যে অনেক বিস্তৃত পৃষ্ঠা বাক্সটি মেরে ফেলবে। বাক্সটিতে কেবল 768 এমএম র‌্যাম রয়েছে এবং 2 মেগাবাইটের ডিফল্ট বিশাল প্যাকেজ সহ 2 জিবি হুইলপেজ বরাদ্দ করা হবে। বাক্সটি এটি পরিচালনা করতে সক্ষম হবে না এবং সাথে সাথে মারা যাবে।
প্যাট্রিক

আপডেট করা হয়েছে। যদিও মানটি শূন্য থেকে বাড়ানো উচিত।
ew white

এটি তার চেয়ে আরও জটিল। আপনাকে বিশাল পৃষ্ঠার অনুমতি সেট করতে হবে, এবং মাইএসকিএল অবশ্যই বিশাল পৃষ্ঠাগুলি ব্যবহার করার জন্য কনফিগার করা উচিত, অন্যথায় আপনি কেবল অকারণে তাদের বরাদ্দ করছেন।
প্যাট্রিক

2

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

মনে রাখবেন যে আপনার অদলবদলের স্থানটি পুনরায় বুট করার আগে পর্যন্ত প্রায় সম্পূর্ণরূপে ব্যবহৃত হয়। এটি প্রায়শই ভাল জিনিস না এবং একটি নিশ্চিত নিদর্শন অল্প অল্প স্মৃতি বাকী আছে।

সেই নির্দিষ্ট সময়সীমার জন্য কোনও ডেটা উপলভ্য হওয়ার কারণটি নয় কারণ সিস্টেমটি অন্যান্য জিনিসগুলির সাথে খুব ব্যস্ত। আপনার প্রক্রিয়া তালিকার "মজার" মানগুলি কেবল একটি ফলাফল হতে পারে, কোনও কারণ নয়। এটা শোনা যায় না।

/Var/log/kern.log এবং / var / লগ / বার্তাগুলি পরীক্ষা করুন, আপনি সেখানে কোন তথ্য খুঁজে পেতে পারেন?

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

আমি মনে করি আপনি দেখতে পাবেন যে প্রক্রিয়াটি (এস) যা আপনার সমস্যাগুলি শুরু করার সময়টি হ'ল (তার মধ্যে) সবচেয়ে বেশি সিপিইউ% ব্যবহার করছে are মাইএসকিএল-কেও সেভাবে আচরণ করতে আমি কখনও দেখিনি। ব্রাউজারের মতো জাভা অ্যাপ্লিকেশন এবং গুই চালিত অ্যাপস হ'ল সম্ভাব্য অপরাধীরা।


সেই ফাঁকে কোনও ডেটা নেই কারণ বাক্সের বোঝাটি এত অযৌক্তিকভাবে স্পাইক করে যে মনিটরিং এজেন্ট সহ সমস্ত কিছু সম্পূর্ণ থামে। এজেন্ট নিজেই কাছাকাছি-মৃত্যুর সময়কালে কখনই মারা যায়নি, তবে এটি কোনও তথ্যই রিপোর্ট করতে পারেনি। আমার অদলবদলের জায়গাটি আসলে ভাল ছিল। এটি পুনরায় বুট করার আগে মোট ~ 130 / 512MB ব্যবহার করছিল। rsyslogd একটি নেটওয়ার্ক অবস্থানে লগগুলি প্রতিবেদন করার জন্য কনফিগার করা হয়েছে, যেখানে যা ঘটেছিল তা লগ করা হয়েছিল - এবং এগুলি ছাড়া 408 টি প্রক্রিয়া (যার মধ্যে কিছুগুলি অ্যাপাচি বাচ্চাদের পুনরায় চালু করা হয়েছিল) হত্যা করে, কিছুই থেকে যায়নি।
কাইল ব্রেন্টলে

আমি প্রতি কয়েক সেকেন্ডে কোনও ফাইলের (বা নেটওয়ার্ক) সম্পূর্ণ প্রক্রিয়া তালিকাটি ডাম্প করে শেষ করতে পারি যদি আমি আসলে এখানে কী চলছে তা বুঝতে পারি না, তাই ভাল ধারণাটির জন্য ধন্যবাদ।
কাইল ব্রেন্টলে

হ্যাঁ আপনার এটি করা উচিত, প্রতিটি প্রক্রিয়াটির সিপিইউ ব্যবহার আপনিও রেকর্ড করে নিন, "টপ-বি" (ব্যাচ মোড) দেখুন। যে প্রক্রিয়াটি স্পাইকগুলি অপরাধী হতে পারে।
aseq
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.