Magento extremadamente lento cuando el caché está "lleno"

Estamos ejecutando Magento 1.9.2.1 con Lesti_Fpc en un servidor administrado de tamaño adecuado. Inicialmente, utilizamos el caché de archivos predeterminado, que estaba bien. Pero después de que el catálogo creció (aunque creo que ~ 8000 productos no es tan malo) y los rastreadores se volvieron más agresivos, el sitio se volvió lento tan pronto como el caché se hizo un poco más grande. Cuando se borró el caché, todo volvía a funcionar rápidamente.

Intentamos cambiar a APC como backend de caché a través de la siguiente entrada en local.xml:

<global>
    <cache>
        <backend>apc</backend>
        <prefix>MYSHOP_</prefix>
    </cache>
</global>

Pero esto empeoró aún más los problemas. Luego leí que Cm_Cache_Backend_File está hecho para este problema y lo integré a través de:

<global>
    <cache>
        <backend>Cm_Cache_Backend_File</backend>
    </cache>
</global>

Esto se siente un poco mejor, pero el problema sigue siendo el mismo. Para mantener el caché pequeño y ordenado, también integré Aoe_CacheCleaner , pero esto tampoco ayuda. Aún así, tan pronto como se borra el caché, todo vuelve a funcionar rápidamente.

EDITAR:
según la respuesta de infabo, también activé Cm_Cache_Backend_Filepara el FPC con el archivo app/etc/fpc.xmly el siguiente contenido:

<?xml version="1.0"?>
<config>
    <global>
        <fpc>
            <lifetime>86400</lifetime>
            <backend>Cm_Cache_Backend_File</backend>
        </fpc>
    </global>
</config>

Estoy seguro de que esto tiene sentido, pero tampoco resuelve el problema.

Sé que la solución general a este problema parece ser Redis (o tal vez, alternativamente, Memcached) como un backend de caché, pero desafortunadamente, no está disponible en nuestro servidor administrado. Cambiar a otra empresa de alojamiento no es (todavía) una opción.

Investigué mucho ahora, pero no tengo más idea. ¿Quizás alguien más pueda ayudar?

Investigué aún más y creo que finalmente resolví el problema. Entonces, ¿qué puedes hacer para analizar tal problema?

1. Para tener una buena idea cuando el caché se vuelve demasiado grande y si el problema es realmente el tamaño del caché, agregue un cronjob que llame al siguiente script, por ejemplo, cada 15 minutos:

   #!/bin/bash
   
   # this script is an attempt to check if the full cache is the real performance problem
   # it should be called regularly as a cronjob
   
   cache_dir="/html/shop/var/cache/"
   log_file="/html/cache_log"
   
   line=$(date)
   line="$line Size of cache directory: $(du -hs $cache_dir)"
   echo "$line" >> $log_file
   
   line=$(date)
   line="$line Total cache tags: $(find $cache_dir'cm-tags/' -type f | wc -l)"
   echo "$line" >> $log_file
   

   Luego puede analizar el contenido de /html/cache_logpara ver cómo se desarrolla el tamaño del caché, cuándo su página se vuelve demasiado lenta y si la causa raíz es realmente el caché.

2. Analiza tus archivos de caché. Por lo tanto, es bastante útil escribir todos los archivos de caché en un archivo de registro con, por ejemplo:

   ls -R /html/shop/var/cache > /html/cachefiles

   Eche un vistazo a este archivo y sus nombres. ¿Qué tipo de archivos de caché hay? ¿Hay algo sospechoso? En mi caso, había una gran cantidad de archivos de caché que contenían AMSHOPBYsu nombre de archivo, una referencia a la extensión Amasty Improved Navigation ( Amasty_Shopby). Estaba creando una gran cantidad de archivos de caché. Algunos de ellos me parecieron bastante extraños. Deshabilitar la caché de navegación mejorada de Amasty resolvió el problema al instante. Me puse en contacto con su soporte con una descripción detallada y el soporte fue realmente bueno. La estrategia de almacenamiento en caché se revisó rápidamente por completo y ahora es mucho mejor. Prometieron integrar el parche en la próxima versión de la extensión, por lo que cada versión> 2.8.3 debería estar bien.

¡Buena suerte en encontrar la causa raíz de tu gran caché!

¿Has probado también Cm_Cache_Backend_File como backend en fpc.xml? Quizás intentarlo. También le daría una oportunidad a Aoe_Profiler. Si puede reproducir las "ralentizaciones" en una copia provisional, vaya y perfile allí sus solicitudes lentas. De lo contrario, puede hacerlo en producción ( estrictamente no lo recomiendo , pero si se atreve, puede configurar el generador de perfiles para que solo se habilite cuando se configure el parámetro GET y continúe)