লাইভ সাইটটি ফ্রন্টএন্ডে ফাঁকা বা লোড করা চালিয়ে যান এবং কখনই লোড হয় না


23

আমি ম্যাজেন্টোতে কখনও স্ট্রঞ্জস্ট সমস্যার মুখোমুখি। আমরা 1.9.0 সংস্করণ ব্যবহার করছি।

গত 2 মাস থেকে, আমাদের লাইভ সাইটটি ব্যবহার করা ব্রাউজারগুলির জন্য "ফাঁকা" বা "লোড করা চালিয়ে যান"। এই ব্রাউজারটির অর্থ আমরা অনেকবার সাইটটি পরিদর্শন করেছি।

কিছু ব্রাউজারে এটির কাজ ঠিক আছে। কিছু ফাঁকা দেখাচ্ছে।

তবে ব্যাকএন্ড সব ব্রাউজারে কাজ করছে।

আমরা ক্রোম, মজিলা, অপেরা এবং অন্যান্য সমস্ত ব্রাউজারে সমস্যায় পড়ছি

1) যদি আমরা ব্রাউজারের ইতিহাস [ক্যাশে এবং কুকিজ] এর কাজ বাদ দিয়ে সাফ করি।

2) যদি আমরা একই সাইটটি বেসরকারী উইন্ডোতে খুলি, এটির কাজ।

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

৪) আমরা যদি ভেরি / সেশন ফোল্ডারটি সাফ করি তবে এটি কিছু সময়ের জন্য সমস্ত ব্রাউজারের জন্য কাজ শুরু করবে। আবার সাইট ফাঁকা।

5) কখনও কখনও, সাইট লোড করা রাখা হবে এবং এটি কখনও লোড হবে না ....

আমি system.log এবং ব্যতিক্রম.লগ পরীক্ষা করেছি । তবে মনে হচ্ছে এটি সম্পর্কিত কোনও ত্রুটি নেই। সুরক্ষিত পৃষ্ঠাগুলির জন্য আমরা https ব্যবহার করছি । এমনকি আমাদের কাছে এই সাইটের জন্য লাইভ Andriod অ্যাপ রয়েছে । কখনও কখনও আমরা মারাত্মক ত্রুটিগুলি পেয়ে যাব:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

আমরা php.ini এ মেমরি_লিট = 1512 এমবি সেট করি

মধ্যে .htaccess আমরা ফাইল নিম্নলিখিত হয়েছে।

পিএইচপি_ভ্যালু মেমোরি_মিলিট 1512 এমএইচপি_ভ্যালু সর্বাধিক_অ্যাক্সিউশন_টাইম 18000

আমরা এটিকে নিঃশর্ত করলাম:

ini_set('display_errors', 1);

কিন্তু সম্মুখভাগে প্রদর্শিত কোনও ত্রুটি নেই। এটি হ'ল এপাচি ত্রুটি লগ:

চাইল্ড পিড 23845 প্রস্থান সিগন্যাল সেগমেন্টেশন ফল্ট (11), / ইত্যাদি / অ্যাপাচি 2 তে সম্ভাব্য কোরেডাম্প

এই সমস্যাটি সমাধানের জন্য সত্যই লড়াই করা। এই সমস্যাটি কি আমাদের কোডের সাথে সম্পর্কিত নাকি এই সমস্যাটি সার্ভারের সাথে সম্পর্কিত?

ব্রাউজার কুকি কি প্রধান সমস্যা? যদি তাই হয় তবে সমস্ত ব্রাউজারগুলির জন্য এই কুকি সমস্যাটি সমাধান করার জন্য কী করা দরকার। আমরা একবার সেশন ফোল্ডার সাফ করার পরে এটি কেন কাজ শুরু করল?

আমাদের সাইট ব্রাউজ করার সময় আমরা এই সমস্যার মুখোমুখি হই। এখানে চিত্র বর্ণনা লিখুন এখানে চিত্র বর্ণনা লিখুন এখানে চিত্র বর্ণনা লিখুন


এটা কি সম্ভব যে এটির কুকি ইস্যু? stackoverflow.com/questions/15491819/...
pzirkind

আমি যে লিঙ্কটি আটকেছি তা ব্যাকএন্ডের জন্য তবে
সীমান্তটিতে কুকির সমস্যাও

আমাদের ক্ষেত্রে পিজিরকিন্ড সমস্ত ব্রাউজারের জন্য ঠিক আছে। কোডের মাধ্যমে কি কুকির জীবনকাল বাড়াতে হবে? এবং আমি পাইনি সার্ভারটির টাইমস্ট্যাম্প বন্ধ। আমাদের কি তা চালু করতে হবে?
ম্যাজেন্টো

@ ব্যাগি ম্যাজেন্টোতে কখনও কখনও যদি সার্ভারের সঠিক টাইমস্ট্যাম্প না থাকে তবে এটি একটি কুকি তৈরি করে যা বর্তমান তারিখের আগেই শেষ হয়ে যায়, তাই যখন গ্রাহক সাইটটি পুনরায় লোড করে এবং ম্যাজেন্টো কুকিটিকে তার অবৈধ পরীক্ষা করে তখন
pzirPoint

@ পিজিরকিন্ডের কোনও প্রশ্ন বা টাইমস্ট্যাম্পে পোস্ট হওয়া অ্যাপাচি ত্রুটি এই ফাঁকা পৃষ্ঠার কারণ হতে পারে?
ম্যাজেন্টো

উত্তর:


10

প্রথমে আপনার .htaccessফাইলে বিকাশকারী মোড সক্ষম করুন, ফাইলের শেষে নিম্নলিখিতটি যুক্ত করুন:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

index.phpপরবর্তীটি সম্পাদনা করুন এবং লাইনটি আপত্তিহীন করুন:

#ini_set('display_errors', 1);

রেখাটি উল্লেখ করা হয়েছে:

পরবর্তী এসএসএইচ এর মাধ্যমে লগইন করুন এবং /tmpসেগমেন্ট ফল্ট ত্রুটির উল্লেখ হিসাবে একটি মূল ডাম্প ফাইল সন্ধান করুন । কখনও কখনও এটি এছাড়াও রুট হতে পারে /বা উদাহরণস্বরূপ সাইট নিজেই রুট ডিরেক্টরিটি মধ্যে: /var/www/html/videomergerapp/

আপনি যদি কোনও মূল ডাম্প ফাইল সনাক্ত করতে অক্ষম হন তবে আপনি পিএইচপি / অ্যাপাচিতে কিছু অতিরিক্ত নির্দেশ যুক্ত করতে চাইতে পারেন।

এখানে একবার দেখুন:

আপনার কাছে একবার কোর ডাম্প ফাইল (গুলি ) হয়ে গেলে, পিএইচপি কনফিগার করার সময় আপনি gdb(যদি --enable-debug) ব্যবহার করতে পারেন । কমান্ড লাইন থেকে নিম্নলিখিত জারি করে আপনি এই সংকল্পটি করতে পারেন:

php -i | grep debugঅথবা কেবলমাত্র আপনার ওয়েবসারভার মূলটিতে পিএইচপি স্ক্রিপ্ট ফাইল তৈরি করুন: <?php phpinfo(); ?>এর সামগ্রীতে এবং পিএইচপি কনফিগারেশন মানগুলি দেখতে ওয়েব ব্রাউজারের মাধ্যমে ফাইলটি দেখুন।

যদি এটি সক্ষম না করা থাকে তবে আপনি পিএইচপি নিজেই একটি পূর্ণ ব্যাকট্রেস পেতে সক্ষম হবেন না তবে কেবলমাত্র উচ্চ স্তরের সিস্টেম কল এবং / অথবা অ্যাপাচি ব্যাকট্রেস:

আপনার যদি নীচের মতো কিছু জারি করে কোর ডাম্প ফাইলটিতে অ্যাক্সেস থাকে তবে ব্যর্থতার পয়েন্টটি খুঁজে পেতে আপনাকে ব্যাকট্রেস দেবে:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027


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

তারপরে গিয়ে app/etc/local.xmlঅক্ষম স্থানীয় মডিউলগুলিকে সত্য করে সেট করুন।

<disable_local_modules>true</disable_local_modules>

এটি কোনও মডিউল লোড করা থেকে অটো লোডারকে অক্ষম করবে app/code/local

সম্প্রদায় মডিউলগুলি অক্ষম করতে আপনার প্রতিটি মডিউল সংজ্ঞা ফাইল পাওয়া যায় app/etc/modulesএবং সক্রিয় নোডটিকে মিথ্যা হিসাবে সেট করে অক্ষম করে ফেলা খুব সহজ:

<active>false</active>

এইভাবে আপনি যদি কোনও তৃতীয় পক্ষের মডিউলটি বিলোপের প্রক্রিয়া দ্বারা সমস্যার উত্স সৃষ্টি করে তবে আপনি তা অস্বীকার করতে সহায়তা করতে পারেন। দ্রষ্টব্য: আপনি পারবেন না disable_local_modulesএবং আপনার সমস্ত নন-কোর মডিউলগুলি দিয়ে যেতে পারেন (যা কিছু Mage_ * উপেক্ষা করুন!)।

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

আমি যে প্রচুর টেম্পলেট নিয়েছি সেগুলি Mage::getModel()->load()ফোরচ লুপের মধ্যে ব্যবহার করা খারাপ as কারণ এটি খারাপ অনুশীলন এবং শেষ পর্যন্ত প্রচুর পরিমাণে সার্ভার মেমরি এবং সংস্থান গ্রহণ করতে পারে।

ম্যাজেন্টোতে কোড বিশ্লেষণ সরঞ্জাম রয়েছে যা আপনার টেম্পলেট ফাইলগুলি স্ক্যান করতে সহায়তা করতে পারে যদি এই খারাপ কোডগুলির কোনও অংশ থাকে:

আরও পড়া:

এছাড়াও, আপনি যে ক্যাশে এবং সেশন স্টোরেজটি ব্যবহার করছেন তা সংজ্ঞায়িত করে তা সবার পক্ষে সহায়ক হতে পারে app/etc/local.xml

আশাকরি এটা সাহায্য করবে!


আমি এই ন্যাডটি চেষ্টা করব আপনাকে জানাতে ....
বেবি ইন ম্যাজেন্টো

আমরা ভেরি / সেশন ফোল্ডারটি সাফ করে দিয়েছি। আজ অবধি এটি আমাদের সমস্যার সমাধান করেছে। কিন্তু আজ আবার এই সমস্যা দেখা দিল। htaccess এ যোগ করার চেয়ে: সেট MEVIIS MDEIS_DEVELOPER_MODE "সত্য" এবং অসুবিধা ইনআই_সেট ('ডিসপ্লে_ররিজস', 1); এই লাইন এবং <ডিজেবল_লোকাল_মডিউলস> সত্য </ ডিসজেবল_লোকাল_মডিউল>। আমি টিজিস ত্রুটিটি পেয়েছি তার চেয়ে বেশি: magento.stackexchange.com/questions/94559/…
ম্যাজেন্টো

আমি কিছু chnges করার পরে আমি কোনও সেলিন সাফ করছি না, যদি আমি সেশনটি স্বয়ংক্রিয়ভাবে পরিষ্কার করি তবে এটি সমস্ত সমস্যার সমাধান করবে। আপনি কি এর সাথে সম্পর্কিত কোনও কুকিজ বা সেশন মনে করেন না? এটি সমাধান করার কোন উপায় আছে?
ম্যাজেন্টো

@ বাবাইনিজেন্তো আপনি কি প্রদত্ত তথ্যের ভিত্তিতে সমস্যার সমাধান করতে পেরেছিলেন? যদি তাই হয় তবে অন্যদের অনুরূপ সমস্যাটির জন্য সমস্যাটি কী ছিল? ধন্যবাদ।
B00MER

1
সমর্থনের জন্য তোমাকে অশেষ ধন্যবাদ। আমরা সেশন ফোল্ডারটি সাফ করেছি এবং কুকি সম্পর্কিত জিনিসগুলি ভেরেন.এফপি-তে লুকিয়ে রেখেছি। তবে তবুও আমাদের স্থায়ী সমাধান পেয়েছি কিনা তা পরীক্ষা করার জন্য আমাদের আরও কিছু সময়ের জন্য অপেক্ষা করতে হবে। ঠিক আছে আমরা সেশন ফোল্ডার সাফ করার সাথে সাথে সমাধান পেয়েছি।
22:25

3

আমার অনুমান আপনার কোডটিতে একটি পুনরাবৃত্তি আছে। ফাইলটি সম্পাদনা করুন lib/Varien/Db/Adapter/Pdo/Mysql.phpএবং সেট করুন $_debugএবং $_logCallStackসত্য করুন। var/debug/pdo_mysql.logএটিতে কল স্ট্যাকটি ফাইলে লগ হওয়া উচিত যা আপনার কোডটিতে কোনও পুনরাবৃত্তি যদি লোড হতে সর্বদা লাগে তখন আপনাকে ধারণা দেওয়া উচিত। নোট করুন যে এই ফাইলটি খুব দ্রুত বাড়তে থাকবে তাই আপনি যখন মনে করেন যে সাইটে সমস্যাটি শুরু হয়েছে।

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


আমি "$ _debug" এবং "log _logCallStack" এর মানকে সত্যে পরিবর্তন করেছি, এখন আমি pdo_mysql.log ফাইলটির জন্য অপেক্ষা করছি। এবং আমাদের লগ ফোল্ডারগুলি খুব বেশি পূরণ করছে, এটি প্রায় 90 গিগাবাইট লগ রয়েছে। আমি 2 সপ্তাহের আগে সাধারণ কনফিগারযোগ্য এক্সটেনশনটি ইনস্টল করেছি, 2 মাস থেকেই এই সমস্যা ছিল। তবে এখনও অন্যান্য বগি মডিউলগুলি দেখতে হবে।
শিশু

আমি এখনও অবধি এই ফাইলটি var / debug / pdo_mysql.log খুঁজে পাইনি, তবে সিস্টেম এবং ব্যতিক্রম লগগুলি তৈরি হয়েছে। আমি এই লগটি মূলত দেখতে পাচ্ছি: "লাইব / ভারিইন / সিম্প্লেক্সিমিল / কনফিগারেশন। পিপি 510 লাইনে"
ম্যাজেন্টো-

90 জিবি লগ? কি দারুন! তাদের অন্য কোনও জায়গায় ব্যাকআপ করুন এবং ফাইলগুলি খালি করুন। এটি কমপক্ষে আপনার সাইটের গতি উন্নত করতে সহায়তা করবে।
কল্পেশ

হ্যাঁ তুমিই ঠিক. আমরা কিছু সময়ের পরে মুছতে থাকি। এই সমস্যা কারণ এই লগ হয়? আর এ পর্য্যন্ত আমি didt কোনো pdo_mysql.log পাওয়া
Magento মধ্যে Baby

$_debugFileমাইএসকিএল.এফপি ফাইলের মান পরীক্ষা করে দেখুন এবং নিশ্চিত করুন যে আপনার varডিরেক্টরিতে কোনও ফোল্ডার এবং ফাইল তৈরি করার জন্য প্রয়োজনীয় অনুমতি রয়েছে।
কল্পেশ

2

গ্রাহকের ওয়েবসাইটে আমার একই সমস্যা ছিল। ম্যালওয়ারের জন্য আপনার ম্যাজেন্টো পরীক্ষা করুন।

এটি একটি সুপরিচিত দৃশ্য, সাধারণত এটি হ'ল একটি ওয়্যারওয়্যার যা ব্যবহারকারীর পোস্টের বিষয়বস্তু একটি বাহ্যিক ওয়েবসাইটে পুনঃনির্দেশ করে।

Index.php পরীক্ষা করা শুরু করুন, তারা সাধারণত এটি হ্যাক করে। কোডটি শেষ অবধি স্ক্রোল করুন, লাইসেন্স শিরোনামে ডানদিকে এবং মন্তব্য করা লাইনের মধ্যেও চেক করুন। হ্যাকারগুলি এভাবে কোড লুকানোর জন্য ব্যবহৃত হয়।

আপনার আইএসপি ব্লক করা ওয়েবসাইটগুলির সাথে যোগাযোগের চেষ্টা করার কারণে আপনার কাছে "চিরকালের জন্য লোডিং" রয়েছে।

ম্যালওয়্যারটি খুঁজে পাওয়া, "বেস 64", "ইভাল", "এমক্রিপ্ট" স্ট্রিংগুলির সন্ধান করা বেশ সহজ হওয়া উচিত।


এই আমাদের index.php => হল pastebin.com/N8xnWMa7
Magento মধ্যে Baby

আমাদের সাইটটি 3 মাসের আগে হ্যাক হয়েছিল, তার পরে কেবল এই সমস্যাটি এসেছিল। তবে পরে আমরা সার্ভার দিক থেকে প্রচুর সুরক্ষা ব্যবস্থা নিয়েছি। তবে আপনি কি মনে করেন যে হ্যাকড কোডটি এখনও সাইটে উপস্থিত রয়েছে এবং সমস্যা তৈরি করছে ?.
বেবি

ঠিক আছে, আপনার ইনডেক্স.এফপি ঠিক আছে, তবে আপনার লক্ষণগুলি হ'ল কিছু গ্রাহক হ্যাক ওয়েবসাইটে দেখেছি তার মতোই। আমি আপনাকে নীচের নিদর্শনগুলির জন্য সন্ধানের জন্য একটি সম্পূর্ণ অনুসন্ধান করার পরামর্শ দিচ্ছি: "বেস 64", "ইভাল", "এমক্রিপট", "_P _POST"। তারা আপনাকে অনেকগুলি মিথ্যা ধনাত্মক দেবে যাতে আপনার সেগুলি পরীক্ষা করা দরকার। যদি আপনার কোনও ভুল না পাওয়া যায় আমি আপনাকে ক্যাশেগ্রিন্ড বিশ্লেষণ বা এক্সডিবেগ ধাপে ধাপে বিশ্লেষণের পরামর্শ দিই।
ফিনিক্স 128_ রিকার্ডোটি

আমি আমাদের সাইটের ফাইলগুলিতে সেই শব্দগুলি অনুসন্ধান করব।
ম্যাজেন্টো

........ "করুন Base64-" সঙ্কেতাক্ষরে লিখা এবং ডিকোড গ্রন্থে আমি সীমাহীন সময়ের খোঁজার করছি
Magento মধ্যে Baby

2

আমি একটি ম্যাজেন্টোতে দুটি ওয়েবসাইট ছিল এমন একটি আচরণের অভিজ্ঞতা পেয়েছি। সাইটটি কয়েকটি পৃষ্ঠার জন্য ভাল লোড হচ্ছে এবং তারপরে চিরকালের জন্য লোড হচ্ছে।

বেস ইউআরএলগুলির কনফিগারেশনটি ভুল ছিল। সুরক্ষিত বেস ইউআরএল সেটিংসটি ভুল ওয়েবসাইটে সেট করা হয়েছিল যখন অনিরাপদ বেস URL টি সঠিকভাবে সেট করা হয়েছিল।

সুতরাং এটি ঠিক করতে যদি অ্যাডমিন এমনকি সঠিকভাবে কাজ না করে তবে সঠিক ওয়েবসাইটের জন্য মূল_কেনফিগ_ডেটা টেবিলের মানগুলি পরিবর্তন করা দরকার অর্থাত্ "http: //" দিয়ে সঠিক URL টি সেট করুন এবং মান ক্ষেত্রের সাথে একটি অনুসরণযোগ্য স্ল্যাশ সেট করুন ওয়েবসাইট আইডির প্রতিনিধিত্ব করে সঠিক স্কোপ_আইডির জন্য "ওয়েব / অনিরাপদ / বেস_আরল" এবং "ওয়েব / সুরক্ষিত / বেস_আরল" পথ।

এখানে চিত্র বর্ণনা লিখুন

মনে রাখবেন যে সুরক্ষিত ইউআরএলটি কেবলমাত্র http এ কারণেই এটি একটি ডেমো ওয়েবসাইট ছিল।

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