मुझे सत्र फ़ाइलों को कैसे संभालना चाहिए जो बहुत अधिक हो जाती हैं?


43

मैं उन सर्वरों के एक जोड़े के लिए एक सिडाडमिन के रूप में काम कर रहा हूं जो मैगेंटो साइटों को पकड़ते हैं और कभी-कभी वे सत्र फ़ाइलों के साथ भरते हैं।

मुझे बताया गया है कि इन फ़ाइलों को प्रबंधित करना कुछ ऐसा नहीं है जो Magento के भीतर से किया जा सकता है और मैं उनके अस्थायी उपयोग का मतलब है कि वे सिर्फ बंद नहीं किया जा सकता है, लेकिन यह अजीब लगता है कि Magento के पास इन्हें हटाने का कोई तरीका नहीं है फ़ाइलें?

मेरा समाधान एक रात का कंटेस्टेंट है जो कुछ इस तरह का प्रदर्शन करता है find /path/to/magento/sessions/ -name "sess*" -type f -deleteलेकिन यह कम से कम कहने में असंगत लगता है।

इनसे निपटने का सबसे अच्छा तरीका क्या है?

जवाबों:


37

findदूसरों द्वारा बताए अनुसार एक कस्टम संशोधन समय का उपयोग करने के साथ सत्र फ़ाइलों को हटाने के अलावा , आप यह भी कर सकते हैं:

  • अपने डेटाबेस में सत्र सहेजें । बेशक यह आपके डेटाबेस पर भार डाल देगा और यह सबसे तेज़ तरीका नहीं है, लेकिन आप इस तरह से अधिक सत्रों को संभाल सकते हैं और आप कई फ्रंटएंड सर्वरों के बीच सत्र साझा कर सकते हैं। आप app/etc/local.xmlस्विच करके सेटिंग बदल सकते हैं

    <session_save><![CDATA[files]]></session_save>

    सेवा

    <session_save><![CDATA[db]]></session_save>
  • अपने सत्र भंडारण के रूप में मेमक्च्ड का उपयोग करें । Magento भी डिफ़ॉल्ट रूप से इसका समर्थन करता है। app/etc/local.xml.additionalकॉन्फ़िगरेशन के लिए एक नज़र है। मैंने इसे उत्पादन में कभी इस्तेमाल नहीं किया लेकिन सुना है कि यह थोड़ा मुश्किल हो सकता है।

  • संभाल Redis में सत्र कॉलिन Mollenhours प्रतिभाशाली एक्सटेंशन का उपयोग कर Cm_RedisSession । Redis को सेट करने में बहुत अधिक समय नहीं लगना चाहिए, इसका उपयोग कैशिंग के लिए भी किया जा सकता है ( Cm_Cache_Backend_Redis देखें ) और डिस्क पर दृढ़ता के साथ RAM कैश को जोड़ती है ( मेमेकैस्टेड , RAM डिस्क या इसके विपरीत जो आपके सर्वर में हमेशा होता है) दुर्घटनाग्रस्त।


1
डेटाबेस में सत्रों को सहेजना भी अधिक सुरक्षित है। यदि आपकी .htaccess फ़ाइल नहीं है (क्योंकि किसी ने var फ़ोल्डर को हटा दिया है), आपकी सत्र फाइलें बाहर से सुलभ नहीं होंगी।
इरफान

8
डेटाबेस में सत्र को सहेजना एक बुरा विचार है। यह उस उद्देश्य के लिए डिज़ाइन नहीं किया गया है और MySQL सत्र भंडारण के लिए एक बहुत ही खराब उपकरण के रूप में कार्य करता है, एक महत्वपूर्ण मुद्दा है - लॉकिंग के लिए कोई अंतर्निहित समर्थन का उल्लेख नहीं करना।
बेन लेसानी - सोनासी

28

फ़ाइल आधारित सत्रों के साथ, वे PHP सत्र क्लीन-अप क्रोन द्वारा स्वतः-चालित हो जाएंगे - इसलिए फ़ाइलों को सृजन के ~ 7200 सेकंड के भीतर हटा दिए जाने की संभावना है। यहां तक ​​कि एक व्यस्त साइट पर (प्रति दिन 30k uniques), आमतौर पर केवल 4,000 सत्र फ़ाइलों में ./var/session - जो एक कम अंत लिनक्स सर्वर के लिए भी कुछ नहीं है।

हालाँकि, क्लीन-अप वास्तव में क्रोन वर्किंग पर निर्भर करता है - जो आमतौर पर Magento के ./var/session निर्देशिका में नहीं दिखता है। तो आपको एक नया सिस्टम क्रोन स्थापित करना चाहिए

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1

सत्रों के लिए डिफ़ॉल्ट क्लीन अप अवधि 7200 सेकंड है, जो पर्याप्त से अधिक होनी चाहिए, हालांकि आप उपरोक्त को सूट में बदल सकते हैं।

Memcache सत्रों के साथ, TCP / IP एकमात्र ओवरहेड है - जो एकल-सर्वर परिनियोजन के लिए, इसे फ़ाइल आधारित की तुलना में धीमा बना देगा। तो, आप इसके बजाय एक यूनिक्स सॉकेट का उपयोग करेंगे, जो उस ओवरहेड को हटाता है और बेहतर सुरक्षा देता है। लेकिन फिर भी, आपके ग्राहक सत्रों को आपके द्वारा आवंटित की जा सकने वाली रैम की मात्रा के बराबर / सीमित कर दिया जाएगा। औसत Magento सत्र 4Kb है - तो आप प्रति आवंटित 256 सक्रिय सत्रों का समर्थन करने में सक्षम होंगे, जो आप आवंटित करते हैं। इसलिए बेतरतीब ढंग से गाड़ी / सत्र खोने से बचने के लिए एक उचित सीमा निर्धारित करना सुनिश्चित करें। और यह भी ध्यान में रखें, एक मेम्केचे डेमॉन पुनरारंभ सभी मौजूदा सत्रों (बीएडी!) को मिटा देगा।

Redis के साथ (देशी नहीं, बल्कि एक एक्सटेंशन के माध्यम से उपलब्ध), आपको Memcache के समान समर्थन मिलता है, लेकिन दृढ़ता के अतिरिक्त लाभों के साथ (आपको इसका उपयोग करना चाहिए)। Cm_Redis एक्सटेंशन के साथ, आप सत्र संपीड़न का लाभ भी उठा पाएंगे। हमने पाया है कि यह एक्सटेंशन सीई और ईई दोनों पर काम करता है।

DB के साथ, डिफ़ॉल्ट prune समाप्ति सेटिंग 1 सप्ताह का एक शक्तिशाली है, इसलिए एक उदाहरण के रूप में उपरोक्त स्टोर आकार के साथ (प्रति दिन 30k uniques), आप लगभग 7GB के core_cache_session के लिए DB तालिका आकार देख रहे होंगे, जो पीस जाएगा लगभग हर सत्र आधारित संचालन के लिए एक पूर्ण पड़ाव में आपका स्टोर।

दोनों बड़े (प्रति दिन 230k अद्वितीय आगंतुक) और छोटे (प्रति दिन 1k अद्वितीय आगंतुक) स्टोर की मेजबानी के अनुभव से , हमारी सिफारिश है:

एकल-सर्वर परिनियोजन - फ़ाइलें

मल्टी-सर्वर परिनियोजन - रेडिस (मुख्य Magento कैश से एक अलग डेटाबेस का उपयोग करके)

मैंने कुछ सच में पूरी तरह से उत्तर यहाँ लिखा था http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980


2
यदि क्लिन अप क्रोन को सत्रों को साफ़ करने के लिए माना जाता है, तो यह विफल क्यों हो जाता है, और एक नई क्रोन बनाने के बजाय उस समस्या को कैसे ठीक किया जा सकता है जो आसपास के काम की तरह लगता है?
हंस

12

मैंने कुछ समय पहले एक संबंधित प्रश्न पूछा है:

https://stackoverflow.com/questions/7828975/php-garbage-collection-clarification

क्या मुझे कभी पता नहीं चला (मैंने एक नए काम के लिए उस नौकरी को छोड़ दिया, और मूल समस्या किसी और की बन गई) यदि मैगेंटो के सत्र इन सेटिंग्स का सम्मान करेंगे, या यदि वे Zend (और संभवतः किसी प्रकार का zend.ini का उपयोग करके अपने सत्र को लागू करते हैं) विन्यास फाइल)।

देखने के लिए php सेटिंग्स:

session.gc_maxlifetime session.gc_probability session.gc_divisor

http://php.net/manual/en/session.configuration.php#ini.session.gc-probability


मुझे यह जानकर बहुत अच्छा लगेगा, मेरे अनुभव से ऐसा लग रहा है कि मैगनेटो इन सेटिंग्स का सम्मान नहीं करता है (मैंने विचार किया है कि मेरे पास जीबी के लायक सत्र सत्र फाइलें हैं जो यह मान लेना सुरक्षित होगा कि कुछ बिंदु पर जीसी चालू हो जाएगा)। तो मैं बस बेन द्वारा अनुशंसित स्क्रिप्ट को एक क्रॉन नौकरी के रूप में सुरक्षित करने के लिए सेट करता हूं।
जेवियर विलानुएवा

7

आमतौर पर क्रॉन जॉब पर्याप्त है, लेकिन यहां कुछ बातों का ध्यान रखना है:

1) सत्र को अब session.gc_maxlifetime( php -i | grep session.gc_maxlifetime) सेकंड से अधिक समय तक सेट करने के लिए सेट करें (यह php.ini या .htaccess द्वारा कचरा संग्रह के लिए तैयार किए गए समाप्त सत्रों की स्थापना करेगा)।

2) आप डेटाबेस में सत्रों को संग्रहीत करना चाहते हैं, यहाँ देखें कि यह कैसे करना है (यह विकल्प कस्टम मैगनेटो मॉड्यूल के माध्यम से प्रबंधित करना आसान हो सकता है)

3) विचार करने के लिए एक और विकल्प मेमेकैच डायन भी सर्वर को गति दे सकता है (हालांकि पूरी तरह से सवाल से जुड़ा नहीं है, मुझे लगता है कि इसके बारे में जानना उपयोगी है)

अधिक जानकारी के लिए यह प्रश्न देखें: https://stackoverflow.com/questions/4353875/how-long-do-the-magento-session-files-need-to-be-kept


2
बस सभी सत्र फ़ाइलों को हटाने के लिए एक क्रोनजॉब का उपयोग अस्वीकार्य है। जब कोई उपयोगकर्ता क्रोन चलाने से 10 मिनट पहले अपनी गाड़ी में सामान जोड़ता है तो क्या होता है? उनकी गाड़ी साफ हो जाती है! यदि PHP का कचरा संग्रह काम नहीं कर रहा है, तो यह पता लगाने की आवश्यकता है।
davidalger

+1 @ गुडविलगर अच्छा बिंदु, मैं (गलत) धारणा के तहत था कि केवल समाप्त सत्रों को
क्रोनजोब के

1
@davidalger - PHP का स्वयं का कचरा संग्रह क्रोन के माध्यम से संचालित होता है। यह केवल findसभी फ़ाइलों को पुराने से sess.gc_maxlifetimeहटा देता है और उन्हें हटा देता है। क्रोन के माध्यम से सत्र हटाना सामान्य, सुरक्षित और स्वीकार्य व्यवहार है।
बेन लेसानी - सोनासी

1
वास्तव में, नहीं, यह नहीं है। PHP स्क्रिप्ट निष्पादन के दौरान सत्र प्रारंभ होने पर सत्र कचरा संग्रह किया जाता है। कितनी बार कचरा संग्रहण चलाया जाता है के मूल्यों पर निर्भर करता है session.gc_probabilityऔर session.gc_divisor। यदि अलग-अलग लिपियों session.gc_maxlifetimeमें सबसे कम मान वाले व्यक्ति के लिए अलग-अलग मान हैं, तो यह निर्धारित करेगा कि सत्र भंडारण के बाद से कितना लंबा सामान लटका हुआ है और उस स्क्रिप्ट का निष्पादन अन्य लिपियों के सत्र ऑब्जेक्ट को साफ करेगा।
डेवडाइगर

5

हमारे सभी सेटअपों पर हमारे पास एक रखरखाव। Php फ़ाइल है जो लॉग्स और var निर्देशिका की सफाई का एक बार में ध्यान रखती है। चूंकि सत्रों को या तो डेटाबेस में या फाइल सिस्टम में सहेजना होता है, इसलिए यह रखरखाव फ़ाइल उन दोनों को साफ करेगी। (नीचे कोड देखें)।

लॉग्स को साफ़ करने के लिए आप निम्न कमांड को क्रॉन जॉब के रूप में चला सकते हैं:

php maintenance.php clean=log

उपरोक्त आदेश निम्न आउटपुट का उत्पादन करेगा:

catalogindex_aggregation has been truncated
catalogindex_aggregation_tag has been truncated
catalogindex_aggregation_to_tag has been truncated
catalog_compare_item has been truncated
dataflow_batch_export has been truncated
dataflow_batch_import has been truncated
log_customer has been truncated
log_quote has been truncated
log_summary has been truncated
log_summary_type has been truncated
log_url has been truncated
log_url_info has been truncated
log_visitor has been truncated
log_visitor_info has been truncated
log_visitor_online has been truncated
report_compared_product_index has been truncated
report_event has been truncated
report_viewed_product_index has been truncated

आप var फ़ोल्डर को साफ करने के लिए निम्न कमांड को क्रॉन जॉब के रूप में चला सकते हैं:

php maintenance.php clean=var

उपरोक्त आदेश निम्न आउटपुट का उत्पादन करेगा:

downloader/.cache/* has been emptied
downloader/pearlib/cache/* has been emptied
downloader/pearlib/download/* has been emptied
var/cache/ has been emptied
var/locks/ has been emptied
var/log/ has been emptied
var/report/ has been emptied
var/session/ has been emptied
var/tmp/ has been emptied

वास्तविक कोड (अपने local.xml फ़ाइल में पथ को समायोजित करने के लिए मत भूलना):

<?php
$xml = simplexml_load_file('./app/etc/local.xml', NULL, LIBXML_NOCDATA);

$db['host'] = $xml->global->resources->default_setup->connection->host;
$db['name'] = $xml->global->resources->default_setup->connection->dbname;
$db['user'] = $xml->global->resources->default_setup->connection->username;
$db['pass'] = $xml->global->resources->default_setup->connection->password;
$db['pref'] = $xml->global->resources->db->table_prefix;

if (!isset($argv[1]) || !stristr($argv[1], 'clean=')) {
    echo 'Please use one of the commands below:' . PHP_EOL;
    echo 'php maintenance.php clean=log' . PHP_EOL;
    echo 'php maintenance.php clean=var' . PHP_EOL;
    die;
}

$method = str_replace('clean=', '', $argv[1]);

switch ($method) {
case 'log':
    clean_log_tables();
    break;
case 'var':
    clean_var_directory();
    break;
default:
    echo 'Please use one of the commands below:' . PHP_EOL;
    echo 'php maintenance.php clean=log' . PHP_EOL;
    echo 'php maintenance.php clean=var' . PHP_EOL;
    break;
}

function clean_log_tables() {
    global $db;

    $tables = array(
        'catalogindex_aggregation',
        'catalogindex_aggregation_tag',
        'catalogindex_aggregation_to_tag',
        'catalog_compare_item',
        'dataflow_batch_export',
        'dataflow_batch_import',
        'log_customer',
        'log_quote',
        'log_summary',
        'log_summary_type',
        'log_url',
        'log_url_info',
        'log_visitor',
        'log_visitor_info',
        'log_visitor_online',
        'report_compared_product_index',
        'report_event',
        'report_viewed_product_index'
    );

    mysql_connect($db['host'], $db['user'], $db['pass']) or die(mysql_error());
    mysql_select_db($db['name']) or die(mysql_error());

    foreach($tables as $v => $k) {
        @mysql_query('TRUNCATE `'.$db['pref'].$k.'`');
        echo $db['pref'] . $k . ' has been truncated' . PHP_EOL;
    }
}

function clean_var_directory() {
    $dirs = array(
        'downloader/.cache/*',
        'downloader/pearlib/cache/*',
        'downloader/pearlib/download/*',
        'var/cache/',
        'var/locks/',
        'var/log/',
        'var/report/',
        'var/session/',
        'var/tmp/'
    );

    foreach($dirs as $v => $k) {
        exec('rm -rf '.$k);
        echo $k . ' has been emptied' . PHP_EOL;
    }
}

5

Magento CMS और इस तरह (जो पुराने सत्रों की सफाई नहीं कर रहे हैं) के लिए, मैं बस php.ini सेटिंग्स के आधार पर क्रोन जॉब्स का उपयोग करता हूं।

PHP5 / Ubuntu 14.04 / डेबियन

सिस्टम cron.d php5 के लिए सेटअप Magento को साफ नहीं करता है ।/var/session (या डिफ़ॉल्ट सत्र फ़ोल्डर के अलावा कुछ भी नहीं (Ubuntu के लिए / var / lib / php5 और / var / lib / php5 / सत्र या / tmp के लिए) dists)।

लेकिन आप अभी भी डिफ़ॉल्ट php5 / डेबियन सिस्टम क्रोन के अनुसार "सेशनक्लाइन" और "मैक्सलिफ़टाइम" का उपयोग कर सकते हैं:

उदाहरण आप कमांड लाइन से कोशिश कर सकते हैं:

# sudo /usr/lib/php5/sessionclean /var/www/{yoursite}/var/session $(/usr/lib/php5/maxlifetime)

तो बस एक प्रणाली / रूट crontab या सत्र फ़ाइलों के लिए अनुमति पढ़ने / लिखने की अनुमति देने वाले उपयोगकर्ता का एक crontab में शामिल करें:

$ sudo crontab -e

यह जोड़ें कि क्या आप इसे सिस्टम php क्रोन के समान देखना चाहते हैं:

20,40 * * * * [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/www/*/var/session ] && /usr/lib/php5/sessionclean /var/www/{yoursite}/var/session $(/usr/lib/php5/maxlifetime)

या - जब से हम जानते हैं कि वे फाइलें / dirs मौजूद हैं:

20,40 * * * * /usr/lib/php5/sessionclean /var/www/*/var/session $(/usr/lib/php5/maxlifetime)

अब मेरे पास सत्रों की प्रबंधनीय राशि है और इसे php.ini (cli) सेटिंग्स के माध्यम से डिफ़ॉल्ट कचरा संग्रह / जीवनकाल के दौरान साफ ​​रखा जाता है।

(आप वाइल्डकार्ड को ऊपर छोड़ सकते हैं या साइटनेम से बदल सकते हैं।)

EDIT (PHP7 / Ubuntu 16.xx / डेबियन):

'सेशनक्लीन' स्क्रिप्ट बदल गई है और अधिकतम जीवनकाल की स्क्रिप्ट को हटा दिया गया है। सिस्टम / php क्रोन जॉब के लिए यह अब एक स्क्रिप्ट है। आप वास्तव में इसका उपयोग नहीं कर सकते क्योंकि फ़ाइल कॉल अब स्क्रिप्ट के लिए स्थिर है।

यदि सिस्टम साफ नहीं कर रहा है, तो पुरानी php5 सेशन स्क्रिप्ट अभी भी आपके लिए काम कर सकती है। आप क्या कर सकते हैं पुराने डेबियन php5 पैकेज को पकड़ो और sessioncleanइसे से निकालें । या आप इसे अपने स्क्रिप्ट क्षेत्र (उचित / var / www / (साइट) अनुमतियाँ / स्वामित्व दे) को कॉपी कर सकते हैं:

#!/bin/sh

# first find all used files and touch them (hope it's not massive amount of files)
[ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" | awk -- '{ if (NR > 1) { print $9; } }' | xargs -i touch -c {}

# find all files older then maxlifetime
find "${1}" -depth -mindepth 1 -maxdepth 1 -ignore_readdir_race -type f -cmin "+${2}" -delete

मैं इसका नाम बदलने की भी सलाह देता हूं, इसलिए यह नए php 'sessionclean' cronjob के साथ भ्रमित नहीं है। फिर आप अपना "अधिकतम जीवनकाल" नंबर इस तरह से प्लग कर सकते हैं:

     20,40 * * * * /home/-username-/scripts/MySessionClean /var/www/*/var/session 61

(६१ उदाहरण उम्र (मिनटों में) और being MySessionClean ’नाम दिया गया php5 स्क्रिप्ट डाउनलोड या ऊपर से कॉपी किया जा रहा है)।

इस तरीके से हम पूरी तरह से php.ini / env कॉल से बचते हैं।

(EDIT 13DEC2016: अद्यतित DEBIAN ARCHIVE REPO LINK)


3

मैंने इन सभी पुराने सत्र फाइलों से डीबी को नियमित रूप से साफ़ कर दिया। यह परेशान करने वाला मैनुअल काम था जब मैंने मैगेंटो ऑप्टिमाइज़र स्थापित किया जो मेरे लिए यह सब नियमित काम करता है। इसके अलावा, मेरे कैश को लगातार ताज़ा किया जाता है और मैं उत्पादों और स्थिर ब्लॉकों को बदलने के बाद इसे मैन्युअल रूप से नहीं करता हूं। ओह, हां, त्रुटि रिपोर्ट और परित्यक्त गाड़ियां भी साफ की जाती हैं।


3

उपरोक्त सभी टिप्पणियों में से, मुझे लगता है कि यह आसान समाधान है और उम्मीद है कि यह लंबी स्क्रिप्ट से बेहतर है और पुराने सत्र फ़ाइलों को प्रबंधित करने और नए सत्र फ़ाइलों को रखने के लिए 3 पार्टी विस्तार स्थापित कर रहा है।

  1. अपने magentoफ़ोल्डर के तहत एक फ़ाइल नाम "clean_session.sh" बनाएं ।
  2. इन पंक्तियों को चिपकाएँ।

#!/bin/bash
# delete session files older than 14 days
find /home/DOMAIN/public_html/var/session -name 'sess_*' -type f -mtime +14 -exec rm {} \;

  1. फिर आप सफाई करने के लिए क्रोनजोब साप्ताहिक कार्यक्रम कर सकते हैं।

1 1 * * 6 /bin/sh /home/DOMAIN/public_html/clean_session.sh

  1. फ़ाइल को निष्पादन योग्य बनाना न भूलें

chmod u+x clean_session.sh

  1. और आप इसे भी चला सकते हैं

sh clean_session.sh


3

मेरे मामले के लिए, मैं magento/var/एक सप्ताह से अधिक ( -mtime +7) पुरानी सत्र फ़ाइलों को हटाने के लिए निर्देशिका में रखी गई स्क्रिप्ट चलाता हूं :

#!/bin/sh
# Place this script in magento/var/ directory

for n in `seq 0 9`
  do
    for u in `seq 0 9`
    do
      for m in `seq 0 9`
        do
          name="sess_"$n$u$m*
          echo $name
          find session/ -name $name -type f -mtime +7 -delete
          echo $name ok
      done
      for m in {a..z}
        do
          name="sess_"$n$u$m*
          echo $name
          find session/ -name $name -type f -mtime +7 -delete
          echo $name ok
      done
    done
      for u in {a..z}
      do
        for m in `seq 0 9`
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
        for m in {a..z}
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
    done
done

for n in {a..z}
  do
    for u in `seq 0 9`
      do
        for m in `seq 0 9`
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
        for m in {a..z}
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
    done
    for u in {a..z}
      do
        for m in `seq 0 9`
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
        for m in {a..z}
          do
            name="sess_"$n$u$m*
            echo $name
            find session/ -name $name -type f -mtime +7 -delete
            echo $name ok
        done
    done
done

यह मेरी पहली बैश स्क्रिप्ट (संशोधन 2) है और मुझे लगता है कि इसे कई पहलुओं में अनुकूलित किया जा सकता है। मैं किसी भी अनुकूलन सुझाव के लिए खुला हूँ।

यह लिपि पुनः प्राप्त की जा सकती है: https://gist.github.com/Nolwennig/a75dc2f8628be2864bb2


0

मैंने एक स्क्रिप्ट बनाई जो var / सत्र निर्देशिका को खाली करती है। आप इसे प्रति दिन एक बार चलाने के लिए क्रॉन जॉब में जोड़ सकते हैं जो पर्याप्त होना चाहिए और आवश्यकतानुसार समायोजित करना चाहिए। जब आप सत्र निर्देशिका भर जाते हैं तो आपको पता चल जाएगा कि cpanel या ssh के माध्यम से फ़ाइलों को हटाना असंभव है, यह स्क्रिप्ट बस Magento रूट डायरेक्टरी में जगह बनाएगी।

<?php
function adjustSessionFiles($dir, $pattern = "*")
{
    $files = glob($dir . "/$pattern");
    foreach ($files as $file) {
        if (is_dir($file) and !in_array($file, array('..', '.')))  {
            adjustSessionFiles($file, $pattern);
        }else if(is_file($file) and ($file != __FILE__)) {
            unlink($file);
        }
    }
}
$dir = __DIR__ . DIRECTORY_SEPARATOR . 'var' . DIRECTORY_SEPARATOR . 'session';
adjustSessionFiles($dir);

इस स्क्रिप्ट के साथ समस्या यह है कि यह सभी सत्रों को हटा देता है, न केवल पुराने। इसलिए किसी को एक दिन से अधिक समय तक लॉग इन नहीं किया जा सकता है (यदि आप इसे रोज चलाते हैं), और इसके चलने के बाद सभी गाड़ियां खाली हो जाएंगी (इसलिए कोई भी गाड़ी एक दिन से अधिक समय तक नहीं रुकेगी)।
सिमोथेनेसोररर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.