Strategie di svuotamento della cache per il salvataggio della memoria per siti di grandi dimensioni?


30

Uno dei miei siti Drupal 7 ha migliaia di campi, un mucchio di tipi di contenuto, più di 25 visualizzazioni e centinaia (che presto saranno migliaia) di tipi di profilo. Per questo motivo, sto usando una patch di base che memorizza meglio nella cache le informazioni sul campo dell'entità (http://drupal.org/node/1040790) e la versione -dev di Views che memorizza meglio nella cache le visualizzazioni per display (invece di avere un ENORME riga della cache delle viste con tutti i dati delle viste al suo interno).

Ciò ha aiutato la maggior parte delle pagine del sito a caricarsi con 20-30 MB di RAM utilizzati, anziché 160 MB + (invece di recuperare le righe della tabella cache_ * per campi e viste che erano 10 MB +, le patch aiutano a mantenere i dati cache_ * molto più efficienti).

Ciò introduce un problema, tuttavia, in quanto la ricostruzione della cache richiede molto tempo . Di solito più di un minuto o due. E durante questo periodo, Drupal semplicemente non caricherà alcuna pagina (poiché le cache che sta cercando di leggere non sono ancora state costruite, altre richieste devono attendere).

Durante i cicli a basso traffico, questo non è un grosso problema; un centinaio di utenti dovranno semplicemente attendere un minuto prima che la pagina venga caricata. Ma durante i cicli ad alto traffico, il server Apache inizia a impazzire, con oltre 40 carichi di CPU, e la memoria si riempie rapidamente perché tutti i thread di lavoro rimangono in attesa e massimizzano la memoria, causando lo scambio. È una specie di spirale della morte. Un riavvio di httpd chiarirà le cose, ma ci vogliono 5-10 minuti perché le cose tornino alla normalità.

Il mio obiettivo è farlo in modo che la pulizia della cache non metta in ginocchio il sito. Per uno, se uso le singole funzioni di svuotamento della cache di admin_menu (come "CSS e JS", quindi "Menu", quindi "Registro temi", ecc.), Le cose procedono senza intoppi finché non premo l'opzione "Pagina e altro". Questo è quando la cache delle viste viene ripristinata (un'operazione molto intensa della CPU e del database con il numero di viste che devono essere memorizzate nella cache), e quando viene ripristinata la cache delle informazioni sul campo (che è anche intensiva della CPU e del database su questo sito).

Quindi ... le mie domande / idee:

  • Utilizzando drush e / o altri script di shell, è possibile per me cancellare le cache in un modo più intelligente di "distruggere tutte le cache contemporaneamente e sperare in una ricostruzione pulita"?
  • Posso bloccare le richieste http mentre si sta verificando la cancellazione della cache in modo che apache non venga ostruito da un sacco di richieste di timbratura della cache?
  • Se riesco a cancellare le cache al di fuori della richiesta httpd di Drupal / normale, potrei presumibilmente impostare un memory_limit PHP più elevato per l'operazione di cancellazione della cache e ripristinare il mio memory_limit universale (ora impostato su 256 MB, nel caso in cui un singolo thread httpd debba cancellare le cache ...).

Fondamentalmente: esiste un modo intelligente e grazioso per cancellare tutte le cache con Drupal oltre a fare semplicemente clic sul pulsante nell'interfaccia utente o utilizzare drush cc all?

[ Modifica per chiarimenti : il problema principale che ho sono le ricostruzioni della cache , che (a) richiedono un po 'di tempo e (b) bloccano tutte le altre richieste fino al completamento delle ricostruzioni. Vorrei trovare un modo per farlo in modo che le ricostruzioni non siano altrettanto mortali durante i periodi di traffico intenso.]


2
Domanda interessante. Se disabiliti la memorizzazione nella cache, le prestazioni del tuo sito sono adeguate? IOW, hai ottimizzato Apache / PHP / MySQL per funzionare così come è possibile abilitare la cache? Ovviamente, non ho visto il tuo sistema, ma impostare apc.stat = 0 e assicurarmi di avere memoria sufficiente per APC contribuirà a ridurre l'utilizzo del disco. L'uso di mysqltuner.pl ti darà anche un'indicazione se MySQL è il collo di bottiglia. Quindi puoi attivare la memorizzazione nella cache e modificare (aumenterà l'utilizzo del DB, quindi potrebbe essere necessario regolare i parametri MySQL).
mpdonadio

Uso Redis (simile a memcache) per mantenere in memoria le tabelle della cache delle viste. Ciò ha migliorato drasticamente i tempi di caricamento. Non vedo l'ora di avere la funzione "view cache by display" in una versione stabile, che ha molto senso.
Uwe

@MPD - La disabilitazione della memorizzazione nella cache ucciderebbe rapidamente l'intero sito; in genere 100-500 utenti autenticati e alcune sezioni del sito sono piuttosto pesanti. Il problema più grande per me non sono le letture della cache (per questo ho sperimentato Memcached, Redis e la cache degli utenti APC), ma con la ricostruzione della cache, che è molto intensa per la CPU.
geerlingguy,

Idealmente, si desidera utilizzare i vecchi dati della cache durante la ricostruzione della nuova cache. È corretto?
mikeytown2,

@ mikeytown2 - corretto - sarebbe l'ideale.
geerlingguy,

Risposte:


9

Esiste un modo intelligente e grazioso per cancellare tutte le cache con Drupal oltre a fare semplicemente clic sul pulsante nell'interfaccia utente o utilizzare drush cc all?

Il modulo di azioni della cache lo fa. Dipende dalla regola. Ad esempio, è possibile impostare una regola per cancellare una vista specifica quando un nodo di tipo "x" è stato aggiunto o aggiornato. Consulta i documenti per maggiori dettagli.

Dai anche un'occhiata al grazioso modulo cache : non l'ho ancora provato ma sembra interessante.


Sto già utilizzando drush cc [type]per lo svuotamento della cache specifico (simile alle azioni della cache), ma sono più interessato a trovare modi per svuotare la cache con maggiore grazia e assicurarmi che altri thread httpd non stiano uccidendo il server Apache.
geerlingguy,

1
sembra che drush cc cancellerà tutte le cache delle viste. Con le azioni della cache puoi semplicemente cancellare una vista o una visualizzazione specifica. Probabilmente c'è un bug nella versione dev delle viste, altrimenti non ci vorrebbe un minuto o due per ricostruire le cache. Hai lo stesso problema con le visualizzazioni 7.x-3.5? Anche dare un'occhiata al drupal.org/project/cache_graceful - non hanno ancora provato, ma sembra interessante
Uwe

Lo sviluppatore di visualizzazioni suddivide le visualizzazioni di visualizzazione nelle proprie righe della cache, per aiutare le prestazioni di lettura della cache. Ciò significa che le viste impiegano probabilmente 5 volte di più a costruire la cache (ma ciò aiuta a ridurre l'utilizzo della memoria durante la lettura di cache molto!).
geerlingguy,

Potresti aggiungere le informazioni su Cache Graceful nella tua risposta originale? Lo accetterò, poiché quel particolare modulo aiuta un po '(ma non risolve completamente il problema per me). Penso che dovrò fare un po 'di ricerca nel sito per usare meno campi e tipi di entità per risolvere veramente il mio problema.
geerlingguy,

ok. Sarei interessato a conoscere la tua esperienza con cache_graceful. Quale parte non è stata riparata?
Uwe

2

Il problema principale è che stai usando MySQL per archiviare i dati della cache - per i siti a carico elevato questa è una soluzione molto inefficace.

Consiglio invece di usare Memcache . Ciò aumenterà notevolmente le prestazioni del sistema cache e offrirà 2 grandi vantaggi:

  1. Memcache è molto più veloce per le operazioni di lettura e scrittura che MySQL - tutte le operazioni della cache (e la ricostruzione completa della cache) funzioneranno più velocemente.
  2. Poiché i dati della cache non sono più memorizzati nel DB, la cancellazione della cache non bloccherà altre query MySQL.

Ecco un esempio di configurazione di Memcache per Drupal 7.


Ho usato memcached e APC entrambi, in vari modi, e mentre aiutano molto con le letture della cache, il problema principale che ho è la ricostruzione effettiva; il database non sta facendo quasi nulla mentre il web server sta stampando la cache durante il processo di ricostruzione (molto lento / lungo).
geerlingguy,

APC e Memcached fanno cose diverse. Penso che la corretta configurazione di Memcached ti aiuterà. A proposito, se il tuo sito è visitato principalmente da utenti anonimi, puoi usare Varnish. In questo caso Varnish utilizzerà il proprio sistema di cache e Apache non verrà eseguito per richieste anonime.
Eugene Fidelin,

Il sito ha quasi il 100% di traffico autenticato, altrimenti prenderei in considerazione l'utilizzo di Varnish. Potrei esaminare il modulo Cache Graceful a questo punto.
geerlingguy,

0

Utilizzando drush e / o altri script di shell, è possibile per me cancellare le cache in un modo più intelligente di "distruggere tutte le cache contemporaneamente e sperare in una ricostruzione pulita"?

Se non vuoi distruggere tutte le cache, usa: drush cc type_of_cacheper cancellarne una specifica o definirne una tua.

In alternativa, cancellare manualmente tutte le tabelle simili a cache, ad es

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v 

Se stai usando memcached (sintassi di Bash), prova:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Posso bloccare le richieste http mentre si sta verificando la cancellazione della cache in modo che apache non venga ostruito da un sacco di richieste di timbratura della cache?

Abilita la modalità di manutenzione ( drush -y vset maintenance_mode 1) per impedire alle persone di accedere al sito. Oppure configura il front-end per reindirizzare altrove (ad esempio in Vernice, reindirizzare in Apache o in modifica .htaccess).

Se riesco a cancellare le cache al di fuori della richiesta httpd di Drupal / normale, potrei presumibilmente impostare un PHP più elevato memory_limitper l'operazione di cancellazione della cache e ripristinare il mio universale memory_limit(ora impostato su 256 MB, nel caso in cui un singolo thread httpd debba cancellare le cache. .).

La cancellazione della cache non richiede più memoria, ma la ricostruzione della cache dopo la cancellazione richiederà più tempo. Puoi sempre riscaldare le cache eseguendo cron o aprendo qualsiasi pagina, ad es

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

Specifica -ndi ignorare l' php.inielaborazione che può inoltre velocizzare il processo di svuotamento della cache.


-1

C'è potenzialmente un costo monetario, ma potresti usare una configurazione del server di cache come Varnish. Il lato positivo è che Varnish servirà il tuo sito mentre la cache viene svuotata sul server di produzione, senza che l'utente sia più saggio.

Il rovescio della medaglia: a seconda di quanti secondi / minuti di inattività del server di produzione rispetto alle impostazioni di timeout VCL, Varnish potrebbe aggiornarsi durante quel periodo e vedrai una schermata di errore Varnish 503.

Ma questo approccio insieme a Redis o Memcache può aiutare.


Questa domanda riguarda solo le cache Drupal interne; la ricostruzione delle cache di Drupal ha richiesto un'eternità e ulteriori livelli di cache all'esterno / davanti a Drupal non avrebbero fatto molto per aiutare la ricostruzione dei dati della cache effettiva (oltre a scaricare un po 'di traffico che il server web avrebbe altrimenti dovuto trattenere per un po' mentre le cache sono ricostruiti).
geerlingguy,

In quel caso, ho scoperto che Zend OpCache funzionava bene. :-)
mulderjoe,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.