¿Cómo debo manejar los archivos de sesión que se vuelven demasiado numerosos?

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

  •  16-10-2019
  •  | 
  •  

Pregunta

estoy actuando como administrador de sistemas para un par de servidores que contienen sitios de Magento y ocasionalmente se llenan de archivos de sesión.

Me han dicho que la gestión de estos archivos no es algo que puede hacerse desde dentro de Magento y presumir de sus posibilidades de uso temporal no pueden simplemente ser apagados, pero parece raro que Magento tiene ninguna manera de manejar la eliminación de estos archivos?

Mi solución es un crontab nocturno que lleva a cabo algo como esto find /path/to/magento/sessions/ -name "sess*" -type f -delete pero se siente poco elegante para decir lo menos.

¿Cuál es la mejor manera de manejar esto?

¿Fue útil?

Solución

Además de la eliminación de archivos de sesión con find utilizando un tiempo de modificación personalizada como han mencionado otros, también puede:

  • Guardar sesiones en la base de datos . Por supuesto, esto hará que la carga en su base de datos y no es la forma más rápida, pero se puede manejar de forma más sesiones de esa manera y se puede compartir sesiones entre varios servidores de frontend. Puede cambiar la configuración en app/etc/local.xml cambiando 

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

    a 

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

  • Uso memcached como su almacenamiento de sesión. Magento también soporta esto por defecto. Echar un vistazo a app/etc/local.xml.additional para la configuración. Nunca había usado en la producción, pero he oído que esto puede ser un poco complicado.

  • Maneje los sesiones en Redis utilizando Colin Mollenhours brillante extensión Cm_RedisSession . Configuración de Redis no deben tomar demasiado tiempo, también se puede utilizar para almacenar en caché (ver Cm_Cache_Backend_Redis ) y combina una caché de memoria RAM con la persistencia en el disco (en oposición a memcached, discos RAM o similares), que está siempre en caso de que su servidor está fallando.

Otros consejos

Con sesiones basadas en archivos, que se auto-podado por la sesión de PHP cron limpieza - por lo que los archivos son susceptibles de ser eliminados dentro de ~ 7200 segundos de la creación. Por lo que incluso en un sitio ocupado (30k visitantes únicos por día), por lo general sólo alrededor de 4.000 archivos de sesión en ./var/session -. Que no es nada, incluso para un servidor Linux de gama baja

Sin embargo, la limpieza en realidad se basa en el trabajo de cron - que normalmente no busca en el directorio ./var/session de Magento. Por lo que debe establecer un nuevo sistema 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

El período de la limpieza predeterminada para las sesiones es de 7200 segundos, lo que debería ser más que suficiente, aunque se puede cambiar el anterior para el ejemplo.

Con sesiones de Memcache, TCP / IP es el único cabeza - que por una implementación de un solo servidor, haría más lento que el archivo de base. Así pues, se utilizaría un socket Unix lugar, que elimina los gastos generales y que da una mayor seguridad. Pero aún así, sus sesiones de los clientes serán truncados / limitado en cuanto a la cantidad de RAM que puede asignar. La media sesión Magento es 4KB - por lo que será capaz de soportar 256 sesiones activas, por MB asignar. Así que asegúrese de establecer un límite apropiado para evitar la pérdida de clientes al azar compra / sesión. Y también tener en cuenta, un demonio de Memcache reinicio borrará todas las sesiones existentes (MALO!).

Con Redis (no nativa, pero está disponible a través de una extensión), se obtiene un nivel similar de apoyo como Memcache, pero con los beneficios añadidos de persistencia (caso de que desee utilizarlo). Con la extensión Cm_Redis, también será capaz de tomar ventaja de la compresión sesión. Hemos encontrado esta extensión funciona muy bien en ambos despliegues CE y EE.

La base de datos con el parámetro de caducidad de ciruela pasa por defecto es un poderoso de 1 semana, por lo que con el tamaño del almacén anterior como ejemplo (30k visitantes únicos por día), se le busca en una tabla de tamaño DB para core_cache_session de alrededor de 7 GB - que será moler su tienda a un alto completo, para un funcionamiento basado en casi todas las sesiones.

A partir de la experiencia de acoger los dos grandes (230 mil visitantes únicos por día) y pequeñas (<1k visitantes únicos por día) almacena, nuestra recomendación es:

implementación de un solo servidor - archivos

despliegue de varios servidores - Redis (utilizando una base de datos separada de la principal caché Magento)

Me escribió algunas respuestas muy completas aquí http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

He hecho una pregunta relacionada Hace algún tiempo:

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

Lo que nunca descubrí (I dejó ese trabajo por una nueva, y el problema original se hizo de otra persona) es si las sesiones de Magento se cumplan estos parámetros, o si la aplicación de su manejo utilizando Zend sesión (y, presumiblemente, una especie de zend.ini archivo de configuración).

La configuración de PHP para tener en cuenta:

session.gc_maxlifetime session.gc_probability session.gc_divisor

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

Por lo general, una tarea programada es suficiente, pero aquí es algunas cosas a tener en cuenta:

1) Establecer la sesión ya que session.gc_maxlifetime (php -i | grep session.gc_maxlifetime) segundos (esto pondrá en marcha sesiones expiradas para estar preparados para la recolección de basura por el php.ini o .htaccess)

2) Es posible que desee almacenar las sesiones en la base de datos, véase aquí para obtener más información sobre cómo hacer esto (esta opción podría ser más fácil de manejar a través del módulo de Magento personalizado)

3) Otra opción a considerar es Memcached bruja también puede acelerar los servidores (aunque no completamente conectado a la pregunta, creo que es útil conocer)

Ver esta cuestión para más información: https://stackoverflow.com/questions/4353875/how-long-do-the-magento-session-files-need-to-be-kept

En todas nuestras configuraciones que tiene un archivo maintenance.php que se encarga de la limpieza de los registros y el directorio var vez en cuando. Dado que las sesiones tienen que ser bien guardado en la base de datos o en el sistema de archivos, este archivo de mantenimiento limpiarlos ambos. (Véase el código de abajo).

Puede ejecutar el siguiente comando como una tarea programada para limpiar los registros: 

php maintenance.php clean=log

El comando anterior producirá el siguiente resultado: 

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

Puede ejecutar el siguiente comando como una tarea programada para limpiar la carpeta var: 

php maintenance.php clean=var

El comando anterior producirá el siguiente resultado: 

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

El código real (no se olvide de ajustar la ruta de acceso al archivo de 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;
    }
}

Para Magento CMS y similares (que no están limpiando las sesiones de edad hacia arriba), sólo tiene que utilizar cron puestos de trabajo basado en la configuración de php.ini.

PHP5 / Ubuntu 14.04 / Debian

La configuración del sistema para cron.d php5 hace ./var/session no limpia Magento (o nada, además de carpeta de sesión predeterminado (/ var / lib / php5 para Ubuntu y / var / lib / php5 / o sesiones / tmp / a la mayoría de los demás dists Linux).

Sin embargo, todavía se puede utilizar "sessionclean" y "maxlifetime" según el php5 default / cron Debian sistema:

Ejemplo puede probar desde la línea de comandos: 

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

Así que incorporar eso en un sistema / crontab raíz o un crontab del usuario que haya leído / permiso de escritura para los archivos de sesión: 

$ sudo crontab -e

Añadir esto es que usted quiere que se vea similar a php sistema de 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)

o - ya que sabemos esos archivos / directorios existen: 

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

Ahora tengo una cantidad manejable de sesiones y se mantiene limpia a través de la colección / vida útil de basura por defecto a través de la configuración de php.ini (CLI).

(Usted puede dejar el comodín por encima o reemplazar con nombre del sitio.)

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

El script 'sessionclean' ha cambiado y la escritura maxlifetime se ha eliminado. Para el sistema de trabajo de cron / php ahora es una secuencia de comandos. realmente no se puede usar esto más como las llamadas de archivo son ahora estática a la escritura.

La mayor php5 sessionclean script puede todavía trabajo por usted si el sistema no es la limpieza. Lo que puede hacer es agarrar el mayor Debian php5 paquete y el extracto de sessionclean de ella. O puede simplemente copiar esto a su área de guiones (dando adecuada / var / www / (sitio) permisos / propiedad): 

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

También recomiendo el cambio de nombre, así que no es confundida con la nueva tarea programada php 'sessionclean'. A continuación, puede conectar su propio número de "maxlifetime" de esta manera: 

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

(61 siendo la edad ejemplo (en minutos) y 'MySessionClean' siendo la secuencia de comandos php5 renombrado descargado o copiado desde arriba).

De esta manera evitamos php.ini / env llama por completo.

(EDIT 13DEC2016: Actualización DEBIAN ARCHIVO REPO LINK)

Me aclaró el DB regualarly de todos estos viejos archivos de sesión. Fue irritante trabajo manual hasta que me instalé Magento Optimizer que hace todo este trabajo de rutina para mí. Además, mi caché se actualiza constantemente y no hacerlo de forma manual después de cambiar los productos y bloques estáticos. Oh, sí, avisos de error y carros abandonados se limpian también.

De todos los comentarios anteriores, creo que esta es la solución fácil y espero que es mejor que los guiones largos y la instalación de la extensión tercera parte para gestionar archivos antiguos sesiones y mantener nuevos archivos de sesión.

  1. Crear un nombre de archivo "clean_session.sh" en su carpeta de magento.
  2. Pegar estas líneas.

#!/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. A continuación, se puede programar tarea programada semanalmente para realizar la limpieza.

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

  1. No se olvide de hacer que el archivo ejecutable como

chmod u+x clean_session.sh

  1. Y también se puede ejecutar como

sh clean_session.sh

En mi caso, ejecutar este script se coloca en el directorio de archivos de sesión magento/var/ eliminar más de una semana (-mtime +7) de edad: 

#!/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 mi primera escritura del golpe (revisión 2) y creo que puede ser optimizada en varios aspectos. Estoy abierto a cualquier sugerencia de optimización.

Este script puede ser recuperar en: https://gist.github.com/Nolwennig/a75dc2f8628be2864bb2

He creado un script que se vacía el directorio var / sesión. Puede añadirlo a una tarea programada para ejecutarse una vez por día que debería ser suficiente y ajustar según sea necesario. Se dará cuenta cuando se llena directorio de sesión, es imposible borrar archivos a través de cpanel o ssh, este script hará el truco solo lugar en el directorio raíz 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);
Licenciado bajo: CC-BY-SA con atribución
No afiliado a magento.stackexchange
scroll top