ฉันจะจัดการไฟล์เซสชันที่มีจำนวนมากเกินไปได้อย่างไร


43

ฉันทำหน้าที่ดูแลระบบสำหรับเซิร์ฟเวอร์สองแห่งที่มีเว็บไซต์ Magento และบางครั้งพวกเขาก็เต็มไปด้วยไฟล์เซสชัน

ฉันได้รับแจ้งว่าการจัดการไฟล์เหล่านี้ไม่ใช่สิ่งที่สามารถทำได้จากภายใน Magento และฉันคิดว่าการใช้งานชั่วคราวของพวกเขาหมายความว่าพวกเขาไม่สามารถปิดได้ แต่ดูเหมือนแปลกที่ Magento ไม่มีวิธีจัดการกับการลบเหล่านี้ ไฟล์?

วิธีแก้ปัญหาของฉันคือ crontab ทุกคืนที่ทำอะไรแบบนี้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>
  • ใช้memcachedเป็นที่เก็บข้อมูลเซสชันของคุณ วีโอไอพียังสนับสนุนสิ่งนี้ตามค่าเริ่มต้น ดูที่app/etc/local.xml.additionalการกำหนดค่า ฉันไม่เคยใช้มันในการผลิต แต่เคยได้ยินมาว่ามันอาจจะยุ่งยากเล็กน้อย

  • จัดการประชุมใน Redisใช้โคลิน Mollenhours ขยายสดใสCm_RedisSession การตั้งค่า Redis ไม่ควรใช้เวลานานเกินไปนอกจากนี้ยังสามารถใช้สำหรับการแคชได้ (ดูCm_Cache_Backend_Redis ) และรวมแคช RAM กับการคงอยู่บนดิสก์ (ตรงข้ามกับ memcached, ดิสก์ RAM หรือสิ่งที่คล้ายกัน) ซึ่งเป็นกรณีเซิร์ฟเวอร์ของคุณเสมอ crashing


1
การบันทึกเซสชันในฐานข้อมูลจะปลอดภัยยิ่งขึ้น หากไฟล์. htaccess ของคุณไม่อยู่ที่นั่น (เพราะมีคนลบโฟลเดอร์ var) ไฟล์เซสชันของคุณจะไม่สามารถเข้าถึงได้จากภายนอก
Erfan

8
การบันทึกเซสชันในฐานข้อมูลคือแนวคิดที่ไม่ดี มันไม่ได้ถูกออกแบบมาเพื่อจุดประสงค์นั้นและ MySQL ทำหน้าที่เป็นเครื่องมือที่แย่มากสำหรับการจัดเก็บเซสชั่นการล็อคเป็นปัญหาสำคัญ - ไม่พูดถึงไม่มีการสนับสนุนการกำจัดในตัว
Ben Lessani - Sonassi

28

ด้วยเซสชันที่อิงกับไฟล์พวกเขาจะถูกตัดแต่งอัตโนมัติโดย cron เซสชันการล้างข้อมูล PHP ดังนั้นไฟล์จะถูกลบภายในเวลาประมาณ 7200 วินาทีของการสร้าง ดังนั้นแม้ในเว็บไซต์ที่มีงานยุ่ง (ไม่ซ้ำกัน 30k ต่อวัน) มักจะมีไฟล์เซสชันประมาณ 4,000 ไฟล์ใน. /var/session - ซึ่งไม่มีอะไรแม้แต่สำหรับเซิร์ฟเวอร์ Linux ระดับล่าง

อย่างไรก็ตามการล้างข้อมูลนั้นขึ้นอยู่กับการทำงานของ cron ซึ่งโดยปกติจะไม่ได้ดูใน. /var/session directory ของ Magento ดังนั้นคุณควรตั้ง cron ระบบใหม่

/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 เป็นค่าใช้จ่ายเพียงอย่างเดียวซึ่งสำหรับการปรับใช้เซิร์ฟเวอร์เดียวจะทำให้ช้ากว่าไฟล์ที่ใช้ ดังนั้นคุณจะต้องใช้ซ็อกเก็ตยูนิกซ์แทนซึ่งจะลบค่าใช้จ่ายนั้นและให้ความปลอดภัยที่ดีขึ้น แต่ถึงกระนั้นเซสชันลูกค้าของคุณจะถูกตัดทอน / จำกัด ตามจำนวน RAM ที่คุณสามารถจัดสรรได้ เซสชัน Magento เฉลี่ยคือ 4Kb ดังนั้นคุณจะสามารถรองรับเซสชันที่ใช้งานได้ 256 เซสชันต่อ MB ที่คุณจัดสรร ดังนั้นให้แน่ใจว่าได้กำหนดวงเงินที่เหมาะสมเพื่อหลีกเลี่ยงการสูญเสียรถเข็น / เซสชันอย่างสุ่ม และโปรดจำไว้ว่าการรีสตาร์ท Memcache daemon จะล้างเซสชันที่มีอยู่ทั้งหมด (BAD!)

ด้วย Redis (ไม่ใช่แบบเนทีฟ แต่มีให้ผ่านทางส่วนขยาย) คุณจะได้รับการสนับสนุนในระดับใกล้เคียงกับ Memcache แต่ด้วยสิทธิประโยชน์เพิ่มเติมของการคงอยู่ (หากคุณต้องการใช้) ด้วยส่วนขยาย Cm_Redis คุณจะสามารถใช้ประโยชน์จากการบีบอัดเซสชันได้ เราพบว่าส่วนขยายนี้ทำงานได้ดีทั้งในการปรับใช้ CE และ EE

ด้วย DB การตั้งค่าการหมดอายุลูกพรุนเริ่มต้นคืออันยิ่งใหญ่ 1 สัปดาห์ดังนั้นด้วยขนาดร้านค้าข้างต้นเป็นตัวอย่าง (30k ไม่ซ้ำกันต่อวัน) คุณจะมองไปที่ขนาดตารางฐานข้อมูลสำหรับ core_cache_session ประมาณ 7GB ซึ่งจะบด ร้านค้าของคุณหยุดชะงักสมบูรณ์เกือบทุกการดำเนินการตามเซสชัน

จากประสบการณ์ในการโฮสต์ทั้งร้านค้าขนาดใหญ่ (ผู้เยี่ยมชมไม่ซ้ำ 230k ต่อวัน) และร้านค้าขนาดเล็ก (<1k ผู้เยี่ยมชมต่อวัน) คำแนะนำของเราคือ:

การปรับใช้เซิร์ฟเวอร์เดียว - ไฟล์

การปรับใช้หลายเซิร์ฟเวอร์ - Redis (ใช้ฐานข้อมูลแยกต่างหากจากแคช Magento หลัก)

ผมเขียนตอบกลับอย่างละเอียดจริงๆบางอย่างที่นี่http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980


2
หากทำความสะอาด cron ควรจะล้างเซสชันทำไมมันล้มเหลวและวิธีการแก้ไขปัญหาที่ได้รับการแก้ไขแทนการสร้าง cron ใหม่ที่รู้สึกเหมือนทำงานได้อย่างไร
ห่าน

12

ฉันได้ถามคำถามที่เกี่ยวข้องเมื่อไม่นานมานี้:

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

สิ่งที่ฉันไม่เคยค้นพบ (ฉันออกจากงานใหม่และปัญหาเดิมกลายเป็นของคนอื่น) คือถ้าเซสชันของวีโอไอพีจะให้เกียรติการตั้งค่าเหล่านี้หรือถ้าพวกเขาใช้การจัดการเซสชันโดยใช้ Zend (และอาจเป็น zend.ini บางประเภท ไฟล์ config)

การตั้งค่า php เพื่อดู:

session.gc_maxlifetime session.gc_probability session.gc_divisor

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


ฉันชอบที่จะรู้ว่าตัวเองจากประสบการณ์ของฉันดูเหมือนว่าวีโอไอพีจะไม่ให้เกียรติการตั้งค่าเหล่านี้ (เนื่องจากฉันมีไฟล์เซสชั่นที่มีมูลค่า GB มากเกินไปมันปลอดภัยที่จะคิดว่าในบางจุด GC จะเรียกใช้) ดังนั้นฉันเพิ่งตั้งค่าสคริปต์ที่แนะนำโดย Ben เป็นงาน cron เพื่อความปลอดภัย
Javier Villanueva

7

โดยปกติแล้วงาน cron นั้นเพียงพอ แต่นี่คือสิ่งที่ควรคำนึงถึง:

1) ตั้งค่าเซสชันเป็นนานไม่เกินsession.gc_maxlifetime( php -i | grep session.gc_maxlifetime) วินาที (จะเป็นการตั้งค่าเซสชันที่หมดอายุเพื่อเตรียมพร้อมสำหรับการรวบรวมขยะโดย php.ini หรือ. htaccess)

2) คุณอาจต้องการเก็บเซสชันในฐานข้อมูลดูที่นี่สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำ (ตัวเลือกนี้อาจจัดการได้ง่ายขึ้นผ่านโมดูล magento แบบกำหนดเอง)

3) ตัวเลือกอื่นที่ควรพิจารณาคือแม่มด Memcached สามารถเพิ่มความเร็วเซิร์ฟเวอร์ได้ (แม้ว่าจะไม่ได้เชื่อมต่อกับคำถามอย่างสมบูรณ์ แต่ฉันคิดว่ามันมีประโยชน์ที่จะรู้)

ดูคำถามนี้สำหรับข้อมูลเพิ่มเติม: https://stackoverflow.com/questions/4353875/how-long-do-the-magento-session-files-need-to-be-kept


2
การใช้ cronjob เพื่อลบไฟล์เซสชันทั้งหมดไม่สามารถยอมรับได้ จะเกิดอะไรขึ้นเมื่อผู้ใช้เพิ่มสิ่งของลงในรถเข็นของพวกเขา 10 นาทีก่อนที่ cron จะทำงาน รถเข็นของพวกเขาถูกเช็ดทำความสะอาด! หากการเก็บขยะของ PHP ไม่ทำงานคุณจำเป็นต้องทราบ
davidalger

+1 @davidalger จุดดีฉันอยู่ภายใต้สมมติฐาน (เข้าใจผิด) ว่ามีเพียงเซสชันที่หมดอายุเท่านั้นที่ถูกลบผ่าน cronjob
pzirkind

1
@davidalger - การรวบรวมขยะของ PHP เองทำงานผ่าน cron มันfindเป็นไฟล์ทั้งหมดที่เก่ากว่าsess.gc_maxlifetimeและลบออก การลบเซสชันผ่าน cron เป็นเรื่องปกติปลอดภัยและยอมรับได้
Ben Lessani - Sonassi

1
จริงๆแล้วไม่ใช่มันไม่ใช่ การรวบรวมขยะเซสชันจะเกิดขึ้นเมื่อการเริ่มเซสชันเกิดขึ้นระหว่างการเรียกใช้งานสคริปต์ PHP บ่อยครั้งที่การเก็บขยะจะดำเนินการขึ้นอยู่กับค่าของและsession.gc_probability session.gc_divisorหากสคริปต์ที่แตกต่างกันมีค่าต่างกันสำหรับสคริปต์ที่มีค่าsession.gc_maxlifetimeต่ำสุดจะเป็นตัวกำหนดว่าเนื้อหาจะค้างอยู่นานเท่าใดเนื่องจากหน่วยเก็บข้อมูลเซสชันเป็นส่วนกลางและการดำเนินการของสคริปต์นั้นจะเป็นการล้างวัตถุเซสชันสคริปต์อื่น ๆ
davidalger

5

ในการตั้งค่าทั้งหมดของเราเรามีไฟล์ maintenance.php ซึ่งดูแลการล้างบันทึกและไดเรกทอรี var นาน ๆ เนื่องจากเซสชันต้องถูกบันทึกในฐานข้อมูลหรือบนระบบไฟล์ไฟล์การบำรุงรักษานี้จะทำความสะอาดทั้งคู่ (ดูรหัสด้านล่าง)

คุณสามารถรันคำสั่งต่อไปนี้เป็นงาน cron เพื่อล้างบันทึก:

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

คุณสามารถรันคำสั่งต่อไปนี้เป็นงาน cron เพื่อล้างโฟลเดอร์ 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 และสิ่งที่ชอบ (ที่ไม่ได้ทำความสะอาดเซสชันเก่า) ฉันใช้ cron jobs ตามการตั้งค่า php.ini

PHP5 / Ubuntu 14.04 / Debian

การตั้งค่าระบบ cron.d สำหรับ php5 ไม่ได้ทำความสะอาด Magento ./var/session (หรือสิ่งอื่นใดนอกจากโฟลเดอร์เซสชั่นเริ่มต้น (/ var / lib / php5 สำหรับ Ubuntu และ / var / lib / php5 / เซสชันหรือ / tmp / สำหรับ Linux อื่น ๆ ส่วนใหญ่) dists)

แต่คุณยังสามารถใช้ "sessionclean" และ "maxlifetime" ตามค่าเริ่มต้น php5 / Debian ระบบ cron:

ตัวอย่างที่คุณสามารถลองจากบรรทัดคำสั่ง:

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

ดังนั้นเพียงแค่รวมสิ่งนั้นลงในระบบ / root crontab หรือ crontab ของผู้ใช้ที่ได้รับอนุญาตให้อ่าน / เขียนไฟล์เซสชั่น:

$ sudo crontab -e

เพิ่มนี่คือคุณต้องการให้มันดูคล้ายกับระบบ php cron:

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)

(คุณอาจทิ้งไวลด์การ์ดไว้ด้านบนหรือแทนที่ด้วยชื่อผู้ใช้)

แก้ไข (PHP7 / Ubuntu 16.xx / Debian):

สคริปต์ 'sessionclean' มีการเปลี่ยนแปลงและสคริปต์ maxlifetime ถูกลบแล้ว สำหรับงาน system / php cron ตอนนี้เป็นหนึ่งสคริปต์ คุณไม่สามารถใช้สิ่งนี้ได้อีกต่อไปเนื่องจากการเรียกใช้ไฟล์คงที่กับสคริปต์

สคริปต์เซสชันสะอาด php5 รุ่นเก่ายังคงสามารถทำงานให้คุณได้หากระบบไม่ได้ล้างข้อมูล สิ่งที่คุณสามารถทำได้คือคว้าDebian php5 Packageรุ่นเก่าและดึง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

ฉันยังแนะนำให้เปลี่ยนชื่อมันจึงไม่สับสนกับ phron 'sessionclean' cronjob ใหม่ จากนั้นคุณสามารถเสียบหมายเลข "maxlifetime" ของคุณเองได้ดังนี้:

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

(61 เป็นอายุตัวอย่าง (เป็นนาที) และ 'MySessionClean' เป็นสคริปต์ php5 ที่ถูกเปลี่ยนชื่อที่ดาวน์โหลดหรือคัดลอกมาจากด้านบน)

ด้วยวิธีนี้เราจะหลีกเลี่ยงการโทร php.ini / env โดยสิ้นเชิง

(แก้ไข 13DEC2016: อัปเดตลิงก์คลังข้อมูล DEBIAN ล่าสุด)


3

ฉันล้างฐานข้อมูลอย่างสม่ำเสมอจากไฟล์เซสชั่นเก่าทั้งหมดเหล่านี้ มันน่ารำคาญที่ทำงานด้วยตนเองจนกว่าฉันจะติดตั้งMagento Optimizerซึ่งทำให้งานประจำทั้งหมดนี้สำหรับฉัน นอกจากนี้แคชของฉันยังคงรีเฟรชอย่างสม่ำเสมอและฉันไม่ได้ทำด้วยตนเองหลังจากเปลี่ยนผลิตภัณฑ์และบล็อกแบบคงที่ โอ้ใช่รายงานข้อผิดพลาดและรถเข็นที่ถูกทิ้งร้างก็มีการทำความสะอาดเช่นกัน


3

จากความคิดเห็นทั้งหมดข้างต้นฉันคิดว่านี่เป็นวิธีแก้ปัญหาที่ง่ายและหวังว่าจะดีกว่าสคริปต์ที่มีความยาวและการติดตั้งส่วนขยายของบุคคลที่สามเพื่อจัดการไฟล์เซสชันเก่าและเก็บไฟล์เซสชันใหม่

  1. สร้างชื่อไฟล์ "clean_session.sh" ใต้magentoโฟลเดอร์ของคุณ
  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. จากนั้นคุณสามารถกำหนดเวลา cronjob ทุกสัปดาห์เพื่อทำความสะอาด

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 / session ว่างเปล่า คุณสามารถเพิ่มลงในงาน cron เพื่อรันวันละครั้งซึ่งควรเพียงพอและปรับได้ตามต้องการ คุณจะสังเกตเห็นว่าเมื่อคุณเติมไดเรกทอรีเซสชั่นมันเป็นไปไม่ได้ที่จะลบไฟล์ผ่าน cpanel หรือ ssh สคริปต์นี้จะทำเคล็ดลับเพียงแค่วางในไดเรกทอรีรากของวีโอไอพี

<?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);

ปัญหาของสคริปต์นี้คือมันจะลบเซสชันทั้งหมดไม่ใช่เฉพาะเซสชันเก่า ดังนั้นจึงไม่มีใครสามารถเข้าสู่ระบบได้นานกว่าหนึ่งวัน (ถ้าคุณเรียกใช้งานทุกวัน) และรถเข็นทั้งหมดจะว่างเปล่าหลังจากดำเนินการแล้ว
simonthesorcerer
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.