Comment dois-je gérer les fichiers de session qui deviennent trop nombreux?

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

  •  16-10-2019
  •  | 
  •  

Question

J'agit en tant que sysadmin pour un couple de serveurs qui contiennent des sites Magento et de temps en temps, ils se remplissent de fichiers de session.

On m'a dit que la gestion de ces fichiers ne sont pas quelque chose qui peut être fait à partir de Magento et je présume que leurs moyens d'utilisation temporaire, ils ne peuvent pas être tourné juste à côté, mais il semble étrange que Magento n'a aucun moyen de gérer la suppression de ces fichiers?

Ma solution est un crontab nocturne qui exécute quelque chose comme ça find /path/to/magento/sessions/ -name "sess*" -type f -delete mais il se sent inélégante pour le moins.

Quelle est la meilleure façon de gérer ces?

Était-ce utile?

La solution

En dehors de la suppression des fichiers de session avec find en utilisant un temps de modification personnalisé comme mentionné par d'autres, vous pouvez également:

  • Enregistrer les sessions dans votre base de données . Bien sûr, cela va mettre la charge sur votre base de données et ce n'est pas la plus rapide, mais vous pouvez gérer plusieurs sessions façon de cette façon et vous pouvez partager des sessions entre plusieurs serveurs frontend. Vous pouvez modifier le réglage en app/etc/local.xml par commutation 

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

    à 

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

  • Utilisez memcached que votre stockage de session. Magento prend également en charge cette fonction par défaut. Jetez un oeil à app/etc/local.xml.additional pour la configuration. Je ne ai jamais utilisé dans la production, mais ai entendu dire que cela peut être un peu délicat.

  • Handle sessions Redis avec Colin Mollenhours brillante l'extension Cm_RedisSession . La mise en place Redis ne devrait pas prendre trop longtemps, peut également être utilisé pour la mise en cache (voir Cm_Cache_Backend_Redis ) et combine un cache de RAM avec persistance sur le disque (en opposition à memcached, les disques de RAM ou similaire) qui est toujours au cas où votre serveur se bloque.

Autres conseils

Avec des séances à base de fichiers, ils seront automatiquement élagué par la session PHP Cron nettoyage - de sorte que les fichiers sont susceptibles d'être supprimés dans les ~ 7200 secondes de la création. Ainsi, même sur un site occupé (30k par jour de visiteurs uniques), il généralement seulement environ 4000 fichiers de session dans ./var/session -. Qui est rien, même pour un serveur Linux à faible fin

Cependant, le nettoyage repose en fait sur le travail cron - qui ne regarde pas normalement dans le répertoire ./var/session de Magento. Donc, vous devez définir Cron un nouveau système 

/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

La période de nettoyage par défaut pour les sessions est 7200 secondes, qui devrait être plus que suffisant, mais vous pouvez changer ci-dessus pour emboîter le pas.

Avec des sessions Memcache, TCP / IP est le seul en tête - qui, pour un déploiement sur un seul serveur, rendrait plus lent que le fichier basé. Alors, vous devez utiliser un socket unix à la place, ce qui supprime que les frais généraux et donne une meilleure sécurité. Mais même encore, vos sessions de clients seront tronqués / limitée à la quantité de RAM que vous pouvez allouer. La session Magento moyenne est 4Ko - donc vous serez en mesure de soutenir 256 sessions actives, par Mo vous allouez. Assurez-vous donc de fixer une limite appropriée aux clients d'éviter de perdre au hasard panier / session. Et aussi garder à l'esprit, un démon Memcache restart effacera toutes les sessions existantes (BAD!).

Avec Redis (non native, mais disponible via une extension), vous obtenez un niveau de soutien que Memcache, mais avec les avantages supplémentaires de la persistance (si vous souhaitez l'utiliser). Avec l'extension Cm_Redis, vous serez également en mesure de tirer parti de la compression de la session. Nous avons trouvé cette extension fonctionne très bien sur les déploiements CE et EE.

Le DB, le réglage d'expiration de pruneau par défaut est un puissant 1 semaine, donc avec la taille du magasin ci-dessus comme un exemple (30k visiteurs uniques par jour), vous regarderez à une taille de la table DB pour core_cache_session d'environ 7 Go - qui va moudre votre magasin à un arrêt complet, pour un fonctionnement basé presque tous de la session.

De l'expérience de l'accueil les deux grands (230k visiteurs uniques par jour) et de petite taille (<1K visiteurs uniques par jour) magasins, notre recommandation est:

déploiement serveur unique - fichiers

Déploiement multiserveurs - Redis (en utilisant une base de données séparée de la principale cache Magento)

J'ai écrit des réponses vraiment approfondies ici http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

J'ai posé une question connexe il y a quelque temps:

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

Ce que je ne trouve (je quitté cet emploi pour un nouveau, et le problème d'origine est devenu quelqu'un d'autre) est si les séances de Magento honorera ces paramètres, ou si elles mettent en œuvre leur session de manipulation en utilisant Zend (et probablement une sorte de fichier de configuration zend.ini).

Les paramètres php à regarder:

session.gc_maxlifetime session.gc_probability session.gc_divisor

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

En général, une tâche cron est suffisante, mais voici quelques petites choses à garder à l'esprit:

1) Régler la session pour durer plus longtemps que session.gc_maxlifetime (php -i | grep session.gc_maxlifetime) secondes (ce qui sera mis en place des sessions expirées à préparer pour la collecte des ordures par le php.ini ou .htaccess)

2) Vous pouvez stocker les sessions dans la base de données, voir ici pour plus d'informations sur la façon de le faire (cette option pourrait être plus facile à gérer via le module magento personnalisé)

3) Une autre option à considérer est sorcière Memcached peut également accélérer les serveurs (mais pas complètement connecté à la question, je pense qu'il est utile de savoir)

Voir cette question pour plus d'informations: https://stackoverflow.com/questions/4353875/how-long-do-the-magento-session-files-need-to-be-kept

Sur toutes nos configurations nous avons un fichier maintenance.php qui prend en charge le nettoyage des journaux et le répertoire var une fois dans un certain temps. Étant donné que les séances doivent être soit enregistrées dans la base de données ou sur le système de fichiers, ce fichier de maintenance les nettoyer à la fois. (Le code ci-dessous).

Vous pouvez exécuter la commande suivante en tant que tâche cron pour nettoyer les journaux: 

php maintenance.php clean=log

La commande ci-dessus va produire la sortie suivante: 

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

Vous pouvez exécuter la commande suivante en tant que tâche cron pour nettoyer le dossier var: 

php maintenance.php clean=var

La commande ci-dessus va produire la sortie suivante: 

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

Le code actuel (Ne pas oublier de régler le chemin de votre fichier 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;
    }
}

Pour Magento CMS et similaires (qui ne sont pas le nettoyage de vieilles séances de suivi), j'utiliser simplement les tâches cron en fonction des paramètres php.ini.

PHP5 / Ubuntu 14.04 / Debian

Le système cron.d configuration pour php5 ne nettoie pas Magento ./var/session (ou autre chose que le dossier de session par défaut (/ var / lib / php5 pour Ubuntu et / var / lib / php5 / sessions ou / tmp / pour la plupart des autres Linux dists).

Mais vous pouvez toujours utiliser "sessionclean" et "maxlifetime" selon le système php5 par défaut / Debian Cron:

Exemple, vous pouvez essayer de la ligne de commande: 

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

Il suffit donc incorporer dans un système / crontab racine ou un crontab de l'utilisateur qui a autorisation de lecture / écriture pour les fichiers de session: 

$ sudo crontab -e

Ajouter ceci est que vous voulez regarder similaire à Cron système 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)

ou - puisque nous savons que ces fichiers / répertoires existent: 

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

Maintenant, j'ai une quantité raisonnable de séances et il est maintenu propre par la collecte / durée de vie des déchets par défaut via les paramètres de php.ini (cli).

(Vous pouvez laisser le caractère générique ci-dessus ou remplacez-les par sitename.)

EDIT (PHP7 / Ubuntu 16.xx / Debian):

Le script 'sessionclean' a changé et script maxlifetime a été supprimé. Pour la tâche cron système / php il est maintenant un script. Vous ne pouvez pas vraiment utiliser ce plus que les appels de fichiers sont maintenant statique script.

Les plus php5 sessionclean script peut encore travailler pour vous si le système ne nettoie pas. Ce que vous pouvez faire est de récupérer l'ancienne Debian package php5 et sessionclean extrait de celui-ci. Ou vous pouvez simplement copier dans votre zone de scripts (ce qui donne une bonne / var / www / (site) autorisations / propriété): 

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

Je recommande également le renommer, il est donc pas confondre avec le nouveau php « sessionclean » cronjob. Vous pouvez ensuite brancher votre propre numéro de « maxlifetime » dans comme ceci: 

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

(61 étant l'âge exemple (en minutes) et 'MySessionClean' étant le script php5 renommé téléchargé ou copié ci-dessus).

De cette manière nous évitons php.ini / env appelle tout à fait.

(EDIT 13DEC2016: Mise à jour DEBIAN ARCHIVES REPO LINK)

Je le DB effacé regualarly de tous ces anciens fichiers de session. Il était agaçant travail manuel jusqu'à ce que j'ai installé Magento Optimizer qui fait tout ce travail de routine pour moi. En outre, mon cache est constamment rafraîchi et je ne le font pas manuellement après avoir changé des produits et des blocs statiques. Oh, oui, les rapports d'erreur et des chariots abandonnés sont nettoyés aussi bien.

De tous les commentaires ci-dessus, je pense que c'est la solution facile et espère que son meilleur que de longs scripts et l'installation de l'extension 3e partie pour gérer les anciens fichiers de sessions et de garder les nouveaux fichiers de session.

  1. Créer un nom de fichier "clean_session.sh" sous votre dossier magento.
  2. Coller ces lignes.
  

#!/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. Ensuite, vous pouvez programmer toutes les semaines cronjob pour effectuer le nettoyage.
  

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

  1. Ne pas oublier de rendre le fichier exécutable comme
  

chmod u+x clean_session.sh

  1. Et vous pouvez également exécuter comme
  

sh clean_session.sh

Pour mon cas, je lance ce script placé dans le répertoire magento/var/ pour les fichiers de session supprimer plus d'une semaine (-mtime +7) ancien: 

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

Il est mon premier script bash (révision 2) et je pense qu'il peut être optimisé dans plusieurs aspects. Je suis ouvert à toute suggestion d'optimisation.

Ce script peut être récupérer à: https://gist.github.com/Nolwennig/a75dc2f8628be2864bb2

Je créé un script qui vide le répertoire var / session. Vous pouvez l'ajouter à une tâche cron pour exécuter une fois par jour, ce qui devrait être suffisant et ajuster au besoin. Vous remarquerez quand répertoire de la session est rempli, il est impossible de supprimer des fichiers via cPanel ou ssh, ce script fera l'affaire juste place dans le répertoire racine de 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);
Licencié sous: CC-BY-SA avec attribution
Non affilié à magento.stackexchange
scroll top