`drush cc all` কমান্ডটি খুব দীর্ঘ সময় নেয়, আমি কী করতে পারি?


12

আমার একটি সাইটে drush cc allচালাতে 4 মিনিটেরও বেশি সময় লাগে। সাইট ডিবি কয়েক জিবি। তবে কেন এটি খুব বেশি সময় নেয় তার স্পষ্ট কারণ আমি দেখতে পাচ্ছি না। বোতল ঘাড় সনাক্ত করতে আমি কি করতে পারি?



আপনার কি ক্রোন চলছে?
এমপিডোনাদিও

হ্যাঁ আমার ক্রোন চলছে have সাইটটি সাধারণভাবে ধীরে ধীরে। এতগুলি লিগ্যাসি কোড যা পুনরায় ফ্যাক্টরিংয়ের পক্ষে মূল্য নয়।
এএমএম

আমি এখানে @ এমপিডি এর সাথে একমত, আমার মনে হয় না এটি মেমরি সম্পর্কিত। মাইএসকিউএলও সম্ভাব্য কারণগুলির মধ্যে একটি। এটির উপায় খুঁজে বের করার একটি মাত্র উপায় রয়েছে। এটি করার সহজতম উপায় হ'ল এক্সএইচপিআরএফ এক্সটেনশন এবং ডেভেল ব্যবহার করা, এটি ড্রাশের সাথেও কাজ করে (রিপোর্টের লিঙ্কটি দেখতে -d ব্যবহার করুন)। আমার অনুমান যে এখানে বেশ কয়েকটি সমস্যা রয়েছে, একটি সাধারণ সমস্যা যদি সাইটটিতে সমস্ত অনুরোধের জন্য মডিউলগুলি অনুপস্থিত থাকে তবে Drupal.stackexchange.com/questions/724/why-is-drupal-7-so-slow দেখুনভিউতে ক্যাশেগুলির সাথে কিছু বড় পারফরম্যান্স সমস্যা রয়েছে, দেখুন drupal.org/node/1944674
বারদির

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

উত্তর:


6

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

আপনি সর্বদা নির্দিষ্ট drush cc theme-registryবা অন্য কোনও নির্দিষ্ট করে ক্যাশে সাফ করতে পারেন ।

প্রসেসিংয়ে গতি বাড়ানোর জন্য আপনি পিএইচপি ক্যাচিং মেকানিজম (যেমন ওপিসিচ, এক্সক্যাস ইত্যাদি) ব্যবহার করার পরামর্শ দেওয়া হচ্ছে। এবং এসকিউএল টেবিলগুলিতে ভারী ব্যবহারের প্রতিস্থাপনের জন্য মেমরি-বেস ক্যাশে (উদাহরণস্বরূপ মেমক্যাচড বা রেডিস), সুতরাং ক্যাশে ক্লিয়ারিংয়ের কোনও সময় লাগবে না, কেবল ক্যাশে ফ্লাশ করে (যেমন echo flush_all > /dev/tcp/127.0.0.1/11211বাশে)।

বিকল্পভাবে আপনি সর্বদা ম্যানুয়ালি ক্যাশে সাফ করতে পারেন , উদাহরণস্বরূপ:

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

ডিবাগ

বিশেষত সর্বাধিক সময় কী নিচ্ছে তা যাচাই করার জন্য আপনাকে এটি ডিবাগ / প্রোফাইল করতে হবে (যেমন এক্সডিবেগ, এক্সএইচপিপ্রফ, পিএইচপিডিবিজি, ডিট্রেস)।

ওএস এক্স / ইউনিক্সে এটি dtrace(চলার পরে drush) দ্বারা অর্জন করা যায় :

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

লিনাক্সে strace, যেমন , ব্যবহার করুন

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

কিছু নির্দিষ্ট জিনিস সন্ধান করতে, উদাহরণস্বরূপ: যুক্ত করার চেষ্টা করুন strace ... 2>&1 | grep -C5 UPDATE


5

আপনার যদি সত্যিই বড় ডেটাবেস থাকে এবং আপনি যখন ক্যাশে সাফ না করেন তখন আপনার সিস্টেমটি ঠিকঠাক চলতে থাকে, সম্ভবত আপনার সেটআপটিকে পুরোপুরি সমর্থন করার মতো পর্যাপ্ত মেমরি আপনার কাছে নেই।

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

একবার, আমি একটি বাক্সে মাঝারি ট্রাফিক ড্রুপাল সাইট চালাচ্ছিলাম W / আউট-যথেষ্ট- সেটআপটি সমর্থন করার জন্য পর্যাপ্ত মেমরি। আমি যখন কোনও অপ্রাসঙ্গিক লো ট্রাফিক সাইটটিতে একটি ক্যাশে-ক্লিয়ার চালিয়েছি তখন ক্যাশে পুনর্নির্মাণটি সিস্টেমটিকে তার সীমা ছাড়িয়ে যায় এবং সমস্ত কিছুই লক-আপ হয়ে যায়। সুতরাং, মোট সিস্টেমের আচরণ এখানে গুরুত্বপূর্ণ; এই কারণেই 'শীর্ষ' এর মতো সাধারণ সরঞ্জামগুলি শুরু করার জন্য একটি সুবিধাজনক জায়গা।


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

আমার মেশিনে এটি আছে এবং এটিও ধীর গতির। আমি মেমরিটি দ্বিগুণ করেছি, 1 জিবি অবধি এবং এটি টাইমড ড্রশ সিসি অলআউট ` খুব বেশি ভাল নয় কেবল 4 এস দ্রুত পেয়েছে।
এএমএম

1
হ্যাঁ, পুরো স্মৃতি যদি প্রচুর স্মৃতি সহ সমস্ত সময় ধীরে ধীরে হয় তবে সিসি সমস্যা নয়; আপনাকে আরও সাধারণ প্রোফাইলিং করতে হবে।
গ্রেগ_এন্ডারসন

এছাড়াও, যদি সাইটটি সত্যই পুরানো এবং একটি রিফ্রেশের প্রয়োজন হয় তবে তাজা মডিউলগুলি দিয়ে স্ক্র্যাচ থেকে পুনর্নির্মাণের বিষয়টি বিবেচনা করুন এবং আপনার সামগ্রীকে সরিয়ে নেওয়ার জন্য ড্রুপাল-টু-ড্রুপাল মাইগ্রেশন ( drupal.org/project/migrate_d2d ) ব্যবহার করুন।
গ্রেগ_এন্ডারসন

2

আমি এখানে @ গ্রেগ_1_অ্যান্ডারসনের সাথে (কিছুটা) একমত হতে যাচ্ছি না।

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

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


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

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

1

এটি আপনার ওয়েব হোস্টিং পরিবেশ হতে পারে। আপনি কি কোনও স্থানীয় সেটআপ, বা ভাগ করা হোস্টিং বা ভিপিএস / সার্ভারে হোস্টিংয়ের বিষয়ে উল্লেখ করছেন?

  • হোস্টিং পরিবেশ - আপনি যদি শেয়ার্ড ওয়েব হোস্টিং এ থাকেন তবে ড্রুপাল / ড্রশ ব্যবহার করতে পারবেন এমন মেমরির পরিমাণ সীমিত হবে দেখুন: https://drupal.org/node/207036
  • সর্বোচ্চ প্রয়োগের সময় - বাড়ানো দরকার

সাধারণত ড্রাশ দ্বারা সীমাবদ্ধ নয় max_execution_timedrush php-eval "print ini_get('max_execution_time');"যদিও আপনি ডাবল চেক করতে পারেন ।
mpdonadio

1

এটি সম্পূর্ণ সমাধান নয়, আপনার বিলম্বের উত্স সনাক্ত করতে আরও একটি সরঞ্জাম।

topপ্রক্রিয়াগুলি নিরীক্ষণের জন্য ব্যবহার করার পাশাপাশি আপনি mytopতথ্যমূলক ফলাফল খুঁজে পেতে পারেন । (উপরের অন্যান্য উত্তরগুলি মাইএসকিউএল অনুমান করে তবে আপনি যদি অন্য ডিবি ব্যাকএন্ড ব্যবহার করেন তবে আপনাকে একটি সমতুল্য সরঞ্জামের জন্য মাইটোপ অদলবদল করতে হবে))

mytopকেবলমাত্র SHOW FULL PROCESSLISTএকটি লুপে মাইএসকিউএল সম্পাদন করে এবং আপনাকে দেখায় যে কোয়েরিগুলি কার্যকর করা হচ্ছে (যাতে এতে অনেক সময় লাগে)। যদি ক্যাশে ক্লিয়ারটি এই বা সেই টেবিলটি পরিষ্কার করতে দীর্ঘ সময় নিচ্ছে, আপনি এখানে জিনিসগুলি ঠিক কীভাবে ধরে আছেন তা দেখতে পাবেন। আপনার যদি ইনস্টল করার অ্যাক্সেস না থাকে তবে mytopকেবল আপনার শেলটিতে একটি অশোধিত সংস্করণ করুন -

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

যদি দেরিটি মাইএসকিউএল কোয়েরিগুলি থেকে উদ্ভূত হয় না, তবে এই সরঞ্জামটি আপনার পক্ষে অন্তত তা নিশ্চিত করতে পারে।


1

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

প্রক্রিয়াটির মাধ্যমে কাজ করতে কিছুটা সময় লাগে, তবে এটি ক্যাশে ক্লিয়ারগুলি একাধিক মিনিট থেকে এক মিনিটের মধ্যে হ্রাস করতে আমাকে সহায়তা করেছে।

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