Wie soll ich mit Sitzungsdateien umgehen, die zu zahlreich werden?

magento.stackexchange https://magento.stackexchange.com/questions/41

  •  16-10-2019
  •  | 
  •  

Frage

Ich fungiere als Sysadminaler für ein paar Server, die Magento -Websites aufnehmen, und gelegentlich füllen sie sich mit Sitzungsdateien aus.

Mir wurde gesagt, dass das Verwalten dieser Dateien nicht aus Magento geschehen kann, und ich nehme an, dass ihre vorübergehende Verwendung bedeutet, dass sie nicht einfach ausgeschaltet werden können, aber es scheint seltsam, dass Magento keine Möglichkeit hat, die Entfernung dieser zu bewältigen Dateien?

Meine Lösung ist ein nächtliches Crontab, das so etwas ausführt find /path/to/magento/sessions/ -name "sess*" -type f -delete Aber es fühlt sich gelinde gesagt unelegant an.

Was ist der beste Weg, um damit umzugehen?

War es hilfreich?

Lösung

Abgesehen vom Löschen von Sitzungsdateien mit find Mit einer benutzerdefinierten Änderungszeit, wie von anderen erwähnt, können Sie auch:

  • Speichern Sie die Sitzungen in Ihrer Datenbank. Natürlich wird Ihre Datenbank geladen und es ist nicht der schnellste Weg, aber Sie können viel mehr Sitzungen auf diese Weise und Sie können Sitzungen zwischen mehreren Frontend -Servern teilen. Sie können die Einstellung in der Einstellung ändern app/etc/local.xml durch Wechseln

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

    zu

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

  • Verwenden memcached Als Sitzungspeicher. Magento unterstützt dies auch standardmäßig. Sich ansehen app/etc/local.xml.additional Für die Konfiguration. Ich habe es nie in der Produktion verwendet, habe aber gehört, dass dies ein bisschen schwierig sein kann.

  • Umgehen Sitzungen in Redis Mit Colin Mollenhours brillante Erweiterung CM_REDISSession. Das Einrichten von Redis sollte nicht zu lange dauern, kann auch zum Zwischenspeichern verwendet werden (siehe Cm_cache_backend_redis) und kombiniert einen RAM -Cache mit Persistenz auf der Festplatte (im Gegensatz zu Memcached, RAM -Scheiben oder dergleichen), was immer für den Fall ist, dass Ihr Server abstürzt.

Andere Tipps

Mit filzbasierten Sitzungen werden sie von dem PHP-Sitzungsreinigungscron automatisch gepriesen. Daher werden die Dateien wahrscheinlich innerhalb von ~ 7200 Sekunden nach der Erstellung gelöscht. Selbst auf einer geschäftigen Site (30.000 Uniques pro Tag) gibt es normalerweise nur rund 4.000 Sitzungsdateien in ./var/session-was selbst für einen Low-End-Linux-Server nichts ist.

Die Aufräumarbeiten hängen jedoch tatsächlich auf den Cron -Arbeiten ab - was normalerweise nicht im Verzeichnis von Magento ./Var/session aussieht. Sie sollten also einen neuen System Cron einrichten

/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

Die Standardreinigungszeit für Sitzungen beträgt 7200 Sekunden, was mehr als ausreichend sein sollte, obwohl Sie die oben genannten angemessen ändern können.

Mit Memcache-Sitzungen ist TCP/IP der einzige Overhead-was für eine Einsatz von Einzelgern es langsamer als die filzbasierte Einsatz machen würde. Sie würden also stattdessen eine Unix -Socket verwenden, die diesen Overhead entfernt und eine bessere Sicherheit bietet. Aber trotzdem werden Ihre Kundensitzungen in Bezug auf die Menge an RAM verkürzt, die Sie zuweisen können. Die durchschnittliche Magento -Sitzung beträgt 4 KB. Sie können also 256 aktive Sitzungen pro MB unterstützen, die Sie zuweisen. Stellen Sie also sicher, dass Sie eine geeignete Grenze festlegen, um Kunden zu vermeiden, dass Kunden nach dem Zufallsprinzip einen Wagen/eine Sitzung verlieren. Und auch denken, ein Neustart von Memcache -Daemon wird alle vorhandenen Sitzungen (schlecht!) Auslöschen.

Mit Redis (nicht nativ, aber über eine Erweiterung erhältlich) erhalten Sie ein ähnliches Unterstützungsniveau wie Memcache, aber mit den zusätzlichen Vorteilen der Persistenz (falls Sie es verwenden möchten). Mit der CM_REDIS -Erweiterung können Sie auch die Sitzungskomprimierung nutzen. Wir haben festgestellt, dass diese Erweiterung sowohl für CE- als auch für EE -Bereitstellungen sehr gut funktioniert.

Die With DB, die Standardeinstellung für die Vergleichsablauf von Stand der Prise ist eine mächtige 1 Woche. Mit der oben genannten Speichergröße als Beispiel (30.000 Einheitlichkeiten pro Tag) werden Sie eine DB -Tabellengröße für core_cache_session von ca. 7 GB betrachten - was mahlt wird Ihr Geschäft zum Stillstand für fast jeden Sitzungsbasis.

Aus Erfahrung des Hosting Sowohl große (230.000 einzigartige Besucher pro Tag) als auch kleine (<1k einzigartige Besucher pro Tag) Geschäfte. Unsere Empfehlung lautet:

Single -Server -Bereitstellung - Dateien

Multi -Server -Bereitstellung - Redis (Verwendung einer separaten Datenbank aus dem Haupt -Magento -Cache)

Ich habe hier einige wirklich gründliche Antworten geschrieben http://magebase.com/magento-tutorials/magento-Session-storage-whos-to-choose-and-why/comment-page-1/#comment-1980

Ich habe vor einiger Zeit eine verwandte Frage gestellt:

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

Was ich nie herausgefunden habe (ich habe diesen Job für einen neuen gelassen, und das ursprüngliche Problem wurde zu jemand anderem), ob Magentos Sitzungen diese Einstellungen ehren werden oder ob sie ihre Sitzungsbearbeitung mit Zend implementieren (und vermutlich eine Art Zend.ini Konfigurationsdatei).

Die PHP -Einstellungen zu betrachten:

session.gc_maxlifetime session.gc_probability session.gc_divisor

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

Normalerweise ist ein Cron -Job ausreichend, aber hier sind einige Dinge zu beachten:

1) Stellen Sie die Sitzung auf nicht länger als dauern als session.gc_maxlifetime (php -i | grep session.gc_maxlifetime) Sekunden (so wird abgelaufene Sitzungen eingerichtet, die für die Müllsammlung durch die Php.ini oder .htaccess vorbereitet werden sollen)

2) Möglicherweise möchten Sie die Sitzungen in der Datenbank speichern hier Für weitere Informationen dazu (diese Option ist möglicherweise einfacher zu verwalten über das benutzerdefinierte Magento -Modul).

3) Eine andere Option, die Memcached Hexe zu berücksichtigen ist, kann auch die Server beschleunigen (obwohl es nicht vollständig mit der Frage verbunden ist, denke ich, dass es nützlich ist, darüber zu wissen)

Weitere Informationen finden Sie in dieser Frage: https://stackoverflow.com/questions/4353875/how-long-do-the-magento-session-files-need-t-be-tept

Bei all unseren Setups verfügen wir über eine Wartung.php -Datei, die die Reinigung der Protokolle und VAR -Verzeichnis ab und zu betreut. Da die Sitzungen entweder in der Datenbank oder im Dateisystem gespeichert werden müssen, werden diese Wartungsdatei beides bereinigt. (Siehe Code unten).

Sie können den folgenden Befehl als Cron -Job ausführen, um die Protokolle zu bereinigen:

php maintenance.php clean=log

Der obige Befehl erzeugt die folgende Ausgabe:

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

Sie können den folgenden Befehl als Cron -Job ausführen, um den VAR -Ordner aufzuräumen:

php maintenance.php clean=var

Der obige Befehl erzeugt die folgende Ausgabe:

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

Der tatsächliche Code (vergessen Sie nicht, den Pfad an Ihre lokale.xml -Datei anzupassen):

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

Für Magento CMS und dergleichen (die alte Sitzungen nicht aufräumen) verwende ich nur Cron -Jobs, die auf PHP.ini -Einstellungen basieren.

Php5/Ubuntu 14.04/Debian

Das System cron.d -Setup für PHP5 reinigt Magento ./var/session nicht (oder irgendetwas als Standard -Sitzungsordner (/var/lib/php5 für Ubuntu und/var/lib/PHP5/Sitzungen oder/TMP/für die meisten anderen Linux distiert).

Sie können jedoch immer noch "SessionClean" und "MaxLifetime" gemäß dem Standard -PHP5/Debian -System Cron verwenden:

Beispiel können Sie aus der Befehlszeile versuchen:

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

Integrieren Sie dies also in ein System/Root Crontab oder einen Crontab von Benutzer, der die Sitzungsdateien gelesen/schriftlich für die Sitzungsdateien hat:

$ sudo crontab -e

Fügen Sie hinzu, dass Sie dies ähnlich aussehen wie das System 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)

oder - da wir wissen, dass diese Dateien/Diren existieren:

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

Jetzt habe ich eine überschaubare Menge an Sitzungen und es wird über die standardmäßige Müllsammlung/Lebensdauer über Php.ini (CLI) -Inalation sauber gehalten.

(Sie können die Wildcard oben über oder durch SiteName ersetzen.)

Edit (php7 / ubuntu 16.xx / debian):

Das Skript "SessionClean" hat sich geändert und das MaxLifetime -Skript wurde entfernt. Für das System/PHP -Cron -Job ist es jetzt ein Skript. Sie können dies nicht mehr wirklich verwenden, da die Dateiaufrufe jetzt statisch für das Skript sind.

Der ältere PHP5 Sessionclean Das Skript kann immer noch für Sie funktionieren, wenn das System nicht aufräumt. Was Sie tun können, ist älter zu greifen Debian PHP5 -Paket und Extrakt sessionclean davon. Oder Sie können dies einfach in Ihren Skriptebereich kopieren (geben Sie die Berechtigungen/Eigentümerschaft/var/www/(seiten-) Berechtigungen):

#!/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

Ich empfehle es auch, es umzubenennen, daher ist es nicht mit dem neuen PHP -SessionClean -Cronjob verwechselt. Sie können dann Ihre eigene "maxlifetime" -Nummer wie SO einschließen:

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

(61 Das Beispielalter (in Minuten) und 'MySessionclean' ist das umbenannte PHP5 -Skript, das oben heruntergeladen oder kopiert wurde).

Auf diese Weise vermeiden wir php.ini/env -Anrufe vollständig.

(Bearbeiten 13DEC2016: Aktualisiertes Debian -Archiv -Repo -Link)

Ich habe das DB von all diesen alten Sitzungsdateien registriert geklärt. Es war irritierende manuelle Arbeit, bis ich installierte Magento Optimierer Was all diese Routine für mich funktioniert. Außerdem wird mein Cache ständig aktualisiert und ich nicht manuell, nachdem ich Produkte und statische Blöcke geändert habe. Oh ja, Fehlerberichte und verlassene Karren werden ebenfalls gereinigt.

Ich denke, dies ist die einfache Lösung und hoffe, dass es besser ist als lange Skripte und die Installation der Erweiterung der Drittanbieter, um alte Sitzungsdateien zu verwalten und neue Sitzungsdateien zu führen.

  1. Erstellen Sie einen Dateinamen "Clean_Session.sh" unter Ihrem magento Mappe.
  2. Fügen Sie diese Zeilen ein.

#!/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. Dann können Sie Cronjob wöchentlich planen, um die Reinigung durchzuführen.

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

  1. Vergessen Sie nicht, die Datei als ausführbar zu machen

chmod u+x clean_session.sh

  1. Und Sie können es auch als ausführen als

sh clean_session.sh

Für meinen Fall führe ich dieses Skript aus magento/var/ Verzeichnis zum Löschen von Sitzungsdateien mehr als eine Woche (-mtime +7) alt:

#!/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

Es ist mein erstes Bash -Skript (Revision 2) und ich denke, es kann in mehreren Aspekten optimiert werden. Ich bin offen für einen Optimierungsvorschlag.

Dieses Skript kann abrufen unter: https://gist.github.com/nolwennig/a75dc2f8628be2864bb2

Ich habe ein Skript erstellt, das das VAR/Session -Verzeichnis entleert. Sie können es zu einem Cron -Job hinzufügen, um einmal am Tag zu laufen, was ausreichend sein sollte, und bei Bedarf anpassen. Wenn Ihr Sitzungsverzeichnis gefüllt wird, ist es unmöglich, Dateien über CPANEL oder SSH zu löschen. Dieses Skript wird den Trick nur im Magento -Root -Verzeichnis erledigt.

<?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);
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit magento.stackexchange
scroll top