পিএইচপি সেশনগুলির জন্য উবুন্টুর আবর্জনা সংগ্রহের ক্রোন জবটি চালাতে 25 মিনিট সময় নেয় কেন?

Question

উবুন্টুর একটি ক্রোন জব রয়েছে যা পুরাতন পিএইচপি সেশনগুলি সন্ধান করে এবং মুছে ফেলে:

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] \
   && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir \
   fuser -s {} 2> /dev/null \; -delete

আমার সমস্যাটি হ'ল প্রচুর ডিস্ক আইও সহ এই প্রক্রিয়াটি চালাতে খুব দীর্ঘ সময় নিচ্ছে। আমার সিপিইউ ব্যবহারের গ্রাফটি এখানে:

ক্লিনআপ চলমান টি স্পাইক দ্বারা প্রতিনিধিত্ব করা হয়। পিরিয়ডের শুরুতে, পিএইচপি-র ক্লিনআপ কাজগুলি পূর্বনির্ধারিত সময়ে 09 এবং 39 মিনিটের সময় নির্ধারিত হয়েছিল। 15:00 এ আমি ক্রোন থেকে 39 মিনিটের সময় সরিয়ে ফেলেছি, তাই দ্বিগুণ আকারের একটি ক্লিনআপ কাজ প্রায় অর্ধেকের মতো চলে (

আইও সময়ের সাথে সম্পর্কিত গ্রাফগুলি এখানে রয়েছে:

এবং ডিস্ক অপারেশন:

প্রায় শীর্ষে যেখানে প্রায় 14,000 সেশন ছিল, সেখানে পরিষ্কারের পুরো 25 মিনিটের জন্য চালানো যেতে পারে, স্পষ্টতই সিপিইউর একটি কোরের 100% ব্যবহার করে এবং পুরো সময়ের জন্য ডিস্ক আইওয়ের 100% বলে মনে হয়। কেন এটি এত নিবিড় সংস্থান? একটি lsঅধিবেশন ডিরেক্টরি /var/lib/php5এক সেকেন্ডের মাত্র একটি ভগ্নাংশ সময় লাগে। তাহলে কেন পুরানো সেশনগুলি ছাঁটাতে পুরো 25 মিনিট সময় লাগে? এই গতি বাড়ানোর জন্য আমি কি কিছু করতে পারি?

এই ডিভাইসের ফাইল সিস্টেমটি বর্তমানে এক্সট 4, উবুন্টু যথার্থ 12.04 64-বিটে চলছে।

সম্পাদনা: আমি সন্দেহ করি যে বোঝাটি অস্বাভাবিক প্রক্রিয়া "ফুসার" এর কারণে হয়েছে (যেহেতু আমি যে rmপারফরম্যান্সটি দেখছি তার চেয়ে সাধারণ কোনও দ্রুত অভিশাপ হিসাবে প্রত্যাশা করব)। আমি ফুজারের ব্যবহার সরাতে যাচ্ছি এবং কী ঘটবে তা দেখতে যাচ্ছি।

Comments

আপনার ওয়েব সাইটটি এতগুলি সেশন তৈরি করতে ঠিক কতটা ট্র্যাফিক পায়?

— মাইকেল হ্যাম্পটন

Answer 1

অপসারণ fuserসাহায্য করা উচিত। এই কাজটি fuserপাওয়া প্রতিটি সেশনের ফাইলের জন্য একটি কমান্ড চালায় (কোনও ফাইল বর্তমানে চালু আছে কিনা তা পরীক্ষা করুন) যা 14k সেশন সহ ব্যস্ত সিস্টেমে সহজেই কয়েক মিনিট সময় নিতে পারে। এটি একটি ডেবিয়ান বাগ ছিল (উবুন্টু দেবিয়ান ভিত্তিক)

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

Comments

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

— অতঃপর

এটি অন্য বাগ। আপনার হাজার হাজার fuserপ্রক্রিয়া শুরু করার একটি সাধারণ সমস্যা রয়েছে , যা সমস্তকে অবশ্যই /proc/খোলা ফাইলগুলির জন্য অনুসন্ধান করতে হবে ।

— টমেটজকি

Answer 2

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

আপনি কি সত্যিই দৈনিক দুই মিলিয়ন পৃষ্ঠাদর্শন মধ্যে টেনে করছি, তাহলে আপনি ফাইল সিস্টেম এ পিএইচপি সেশন অনেকটা আপ গাদা করতে যাচ্ছেন, এবং তারা কোন ব্যাপার কিনা আপনি ব্যবহার মুছে ফেলতে একটি দীর্ঘ সময় নিতে যাচ্ছেন fuserবা rmবা ভ্যাকুয়াম ক্লিনার.

এই মুহুর্তে আমি আপনাকে আপনার সেশনগুলি সংরক্ষণের বিকল্প উপায়গুলি অনুসন্ধান করার পরামর্শ দিচ্ছি:

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

Comments

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

— অতঃপর 3 ই

আপনার সামগ্রিক আর্কিটেকচার সম্পর্কে আরও না জেনে আমি একে অপরের উপরে সুপারিশ করতে দ্বিধা বোধ করি।

— মাইকেল হ্যাম্পটন

আপনি memcache.session_redundancy = 2 সেট করে রিডান্ডেন্সির জন্য মেমক্যাচ করা সার্ভারগুলিকে পুল করতে পারেন। সার্ভারফল্ট / প্রশ্ন / ১64৪৩৫০/২ দেখুন । আপনি যদি অধ্যবসায়ের বিষয়ে উদ্বিগ্ন হন এবং এসকিউএল ডেটাবেস স্টোরগুলির চেয়ে অনেক দ্রুত হয় তবে রেডিস একটি ভাল বিকল্প।

— জেফাউন্ট

Answer 3

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

তবে পারফরম্যান্স পরীক্ষার মাধ্যমে আমি জানতে পেরেছি যে এই অধিবেশন রক্ষণাবেক্ষণের বিশাল পারফরম্যান্স fuserব্যয়টি ক্রোন জবটিতে প্রায় পুরোপুরি ডাউন । পুরানো সেশনগুলি ছাঁটাইয়ের rmপরিবর্তে ব্যবহার করা নেট / ওয়ানিরিক ক্রোন কাজের কাছে ফিরে যাওয়ার পরে এখানে পারফরম্যান্সের গ্রাফগুলি রয়েছে fuser, স্যুইচওভারটি 2:30:30 এ ঘটে।

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

(কোনও সম্পর্কযুক্ত IO কাজটি 05:00 এ চলে এবং সিপিইউ কাজ 7:40 এ চলে যা উভয়ই এই গ্রাফগুলিতে তাদের নিজস্ব স্পাইক তৈরি করে)

আমি এখন যে সংশোধিত ক্রোন জবটি চালাচ্ছি তা হ'ল:

09 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && \
   [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
   | xargs -n 200 -r -0 rm

Comments

-print0 | xargs ...প্রয়োজনীয় নয় - আপনি কেবল -deleteসেখানে চলে যেতে পারেন । তবে এটি তুলনামূলক গতির সাথে দুটি উপায়েই কাজ করবে।

— টমেটজকি

Answer 4

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

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

অপারেশনটির প্রচুর ব্যয় (ফিউজারে কল সরিয়ে দেওয়ার পরে) ফাইলগুলি দেখা থেকে উত্পন্ন হয় যা এখনও বাসি হয় নি। (উদাহরণস্বরূপ) একক স্তরের উপ-ডিরেক্টরিগুলি এবং প্রতিটি উপ ডিরেক্টরিতে (0 /, 1 /, ... d /, e /, f /) সন্ধানকারী 16 ক্রোন জব উদ্দীপনাজনিত চাপকে সহজ করবে।

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

Answer 5

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

http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

এটি এত দিন নিরূপণের কারণটি হ'ল ফাইলগুলির বিশাল আকারের কারণে এটি কোনটি মুছে ফেলা যায় তা দেখতে বাছাই করতে হয়। মেমক্যাসগুলি আপনার কোডটিতে সেট করা আপনার সেশনের দৈর্ঘ্য প্রদত্ত এগুলি স্বয়ংক্রিয়ভাবে মেয়াদ শেষ করতে পারে।