একটি প্রক্রিয়া আসল মেমরি ব্যবহার


20

নীচে আমার সার্ভারে mysqlএবং apacheযথাক্রমে মেমরির ব্যবহার রয়েছে । pmapকথার আউটপুট অনুযায়ী , mysqlপ্রায় 379M ব্যবহার করছে এবং 277M apacheব্যবহার করছে।

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

এর আউটপুটটির সাথে তুলনা করে top, আমি দেখতে পাচ্ছি মানগুলি প্রায় মিলছে।

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

এখন এই মানগুলি অবশ্যই এই দুটি প্রক্রিয়ার বর্তমান মেমরির ব্যবহার নয়, কারণ এটি যদি হয় তবে এটি ramআমার সিস্টেমে 512 এম ছাড়িয়ে গেছে এবং আমি বুঝতে পারি যে এটি দুটি প্রক্রিয়াতে নির্ধারিত পৃষ্ঠাগুলির আকার এবং সত্যই নয় তাদের দ্বারা সক্রিয়ভাবে ব্যবহৃত মেমরির আকার। এখন, যখন আমরা ব্যবহার করি pmap -x, আমি একটি অতিরিক্ত কলোন দেখি Dirtyযা প্রক্রিয়াটির জন্য কম মেমরির ব্যবহার দেখায়। নীচের উদাহরণ শোতে দেখা গেছে, Dirtyপ্রথম কলম্বনে 379M এর বিপরীতে কলোন 15M দেখায়। আমার প্রশ্ন হ'ল কোলুমনের অধীন মানটি কি এই Dirtyপ্রক্রিয়াটির দ্বারা সক্রিয়ভাবে ব্যবহৃত মেমরির 'আসল' পরিমাণ? যদি তা না হয়, তবে আমরা কীভাবে কোনও প্রক্রিয়াটির আসল স্মৃতি ব্যবহার করতে পারি? উপরের একই কারণে নয় psএবং topআমাদের অধীনে কি কিছু আছে?/procএই তথ্য দেবে ?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

উত্তর:


18

এমন কোনও আদেশ নেই যা "প্রক্রিয়াটির প্রকৃত মেমরি ব্যবহার" দেয় কারণ কোনও প্রক্রিয়ার আসল মেমরি ব্যবহারের মতো কোনও জিনিস নেই

প্রক্রিয়াটির প্রতিটি স্মৃতি পৃষ্ঠা হতে পারে (অন্যান্য স্বাতন্ত্র্যগুলির মধ্যে):

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

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

দ্বারা প্রদর্শিত তথ্য pmapআসে এবং থেকে আসে । এটিই প্রক্রিয়াটির আসল স্মৃতি ব্যবহার - এটি একটি সংখ্যার দ্বারা সংক্ষিপ্ত করা যায় না।/proc/PID/maps/proc/PID/smaps


6

আমি কিছু আমি কোনো অ্যাপ্লিকেশনের জন্য man পৃষ্ঠা লিখেছে যে একই উত্স থেকে বিশ্লেষণ শীর্ষ অনুরূপ এবং অঙ্কন তথ্য আছে cite করব pmap(যেমন /proc/[N]/maps):

ভার্চুয়াল ঠিকানা স্পেস ভিএস। শারীরিক স্মৃতি

উপরের কয়েকটি পরিসংখ্যানের ব্যাখ্যায় ভার্চুয়াল ঠিকানার স্থান এবং শারীরিক মেমরির মধ্যে পার্থক্য বোঝা গুরুত্বপূর্ণ । নামটি থেকে বোঝা যায়, ভার্চুয়াল ঠিকানার স্থানটি আসল নয়; এটি মূলত সমস্ত প্রক্রিয়াতে বরাদ্দকৃত সমস্ত মেমরির মানচিত্র। এই মানচিত্রের আকারের সীমা প্রতিটি প্রসেসের জন্য সমান (সাধারণত, 2-4 গিগাবাইট), এবং এটি জমা হয় না (যেমন, আপনার কয়েক ডজন বা শত শত প্রক্রিয়া থাকতে পারে, যার প্রতিটি নিজস্ব 2-4 জিবি ভার্চুয়াল ঠিকানা রয়েছে) এমন একটি সিস্টেমে স্পেস যার কেবলমাত্র 512 এমবি শারীরিক মেমরি থাকে )।

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

pmapভার্চুয়াল অ্যাড্রেস স্পেস সম্পর্কে বেশিরভাগ ক্ষেত্রেই আপনাকে রিপোর্ট করে । আপনার পর্যবেক্ষণ যে topআউটপুটে "মানগুলি প্রায় মিলছে" সম্ভবত ভিআইআরটি চিত্রটিকে বোঝায়, যা আরইএস চিত্রের তুলনায় খুব আলাদা। এগুলি উপরে "ভার্চুয়ালস্" এবং "রেসিডেন্টস" (ভিআইআরটি ভার্চুয়াল জন্য, আরইএস বাসিন্দার জন্য) লেবেলযুক্ত ঠিক তার সাথে মিলে যায়।

এখন, যখন আমরা পিএমএপ-এক্স ব্যবহার করি, তখন আমি একটি অতিরিক্ত কলৌমন ডার্টি দেখি যা প্রক্রিয়াটির জন্য মেমরির তুলনায় অনেক কম দেখায়। নীচের উদাহরণে শোতে যেমন দেখা গেছে, ডার্টি কলিউম্যান 15 এম দেখায় প্রথম কলম্বনে 379 এম এর বিপরীতে। আমার প্রশ্ন হ'ল কোলমন ডার্টি এর অধীনে মানটি কী সেই প্রক্রিয়াটির দ্বারা সক্রিয়ভাবে ব্যবহৃত মেমরির 'আসল' পরিমাণ?

না, কিন্তু সাজানো। "ডার্টি" মেমরিটি ডেটা বোঝায় যা ডিস্ক থেকে লোড করা হয়েছে এবং পরবর্তীকালে পরিবর্তিত হয়েছে; যেহেতু এটি সংশোধিত হয়েছে, এটি অবশ্যই আবাসিক স্মৃতির অংশ হতে হবে কারণ এই পরিবর্তনগুলি বর্তমানে র‌্যামে সঞ্চিত রয়েছে। তবে এটি এর সমার্থক নয়।


আমি রাজী. তবে 2 থেকে 4 জিবি 32 বিট সিস্টেমের জন্য। আজকাল বেশিরভাগ সিস্টেমগুলি সম্ভবত 64 বিট bit
ctrl-alt-delor

3

ভার্চুয়াল মেমরিটি স্পিড ডায়াল সংখ্যার মতো, প্রায় 3 বিলিয়ন বা সেগুলি ব্যতীত (32 বিট সিস্টেমের জন্য, 64 বিট কার্নেলের 32 বিট অ্যাপের জন্য 4 বিলিয়ন, 64 বিট অ্যাপ্লিকেশনের জন্য আরও অনেক কিছু) এবং আপনি সরাসরি নম্বর ডায়াল করতে পারবেন না, তাদের কাছে রয়েছে স্পিড ডায়াল ম্যাপ করা।

বেশ কয়েকটি প্রক্রিয়াতে একই ঠিকানার (ফোন নম্বর) বিভিন্ন ম্যাপিং (স্পিড ডায়াল নম্বর) থাকতে পারে। উদাহরণস্বরূপ তারা বেশ কয়েকটি গ্রন্থাগার ভাগ করতে পারে, তাই পুরো লাইব্রেরির জন্য ভার্চুয়াল ঠিকানা থাকতে পারে (আপনি এটি পিএম্যাপে দেখতে পারেন)। তারা এমনকি একই নির্বাহযোগ্য যেমন বাশের 2 টি উদাহরণ ভাগ করে নিতে পারে।

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

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