Memoria "sprecata" inattesa (?) Elevata in memcached


18

Aggiornato, vedi in fondo alla domanda (scusa) longish.

Guardando le nostre statistiche memcached penso di aver trovato un problema di cui non ero a conoscenza prima. Sembra che abbiamo una quantità stranamente elevata di spazio sprecato. Ho controllato con phpmemcacheadmin una modifica e ho trovato questa immagine che mi fissava:

immagine dimensione cache memorizzata

Ora avevo l'impressione che lo scenario peggiore sarebbe stato il 50% di rifiuti, anche se sono il primo ad ammettere di non conoscere tutti i dettagli. Ho letto - tra l'altro - questa pagina che in effetti è piuttosto vecchia, ma lo è anche la nostra versione di memcached. Penso di capire come funziona il sistema ( ad esempio ), ma ho difficoltà a capire come potremmo arrivare al 76% di spazio sprecato.

Il tasso di sfratto che mostra phpmemcacheadmin è 2 ev/s, quindi qui c'è qualche problema.

  • La domanda principale è: cosa posso fare per risolvere questo problema . Potrei lanciarci più memoria (penso che ci siano alcuni extra disponibili), forse dovrei giocherellare con la configurazione slab (è possibile anche con questa versione?), Forse ci sono altre opzioni? L'aggiornamento della versione memcached non è un'opzione rapidamente disponibile.

  • La domanda secondaria, per curiosità, è ovviamente se ci si aspetta un tasso di spreco di spazio del 75% (e in aumento) e, in caso affermativo, perché.

Sistema: al momento non è qualcosa su cui posso fare nulla, so che la versione memcached non è la più recente, ma queste sono le carte che mi sono state distribuite.

  • Memcached 1.4.5
  • Apache 2.2.17
  • PHP 5.3.5

In risposta alla risposta di @DavidSchwartz: ecco le statistiche sulle lastre prodotte da phpmemcacheadmin: (ci sono più lastre tra queste)

( Ho anche incollato le statistiche un po 'più tardi in formato testo qui )

Dettagli della lastra

AGGIORNARE

Ho riavviato il demone con -f 1.5 e sembrava davvero buono. Dopo un po 'di riscaldamento abbiamo usato / sprecato di 50/50. Ma, come in precedenza, più tempo abbiamo avuto durante il giorno (diventa più affollato durante il giorno) ha iniziato a ricadere su quello che è attualmente: 30/70, e lo spreco è ancora in aumento. A parte questo, non so ancora da dove provenga lo "spreco". Vedo questa lastra:

**Slab 5 Stats**
Chunk Size  496.0 Bytes
Used Chunk  77502 [24.6 %]
Total Chunk 314986
Total Page  149
Wasted      117.3 MBytes
Hits        30.9 Request/sec
Evicted     0

Non è pieno, non è stato sfrattato, ma sta sprecando 117,3 MByte. Il rapido calcolo che ho fatto (correggimi se sbaglio) era:

  • la lastra precedente ha una dimensione di blocco di 328, quindi nel caso peggiore questa lastra è riempita con blocchi di 329 byte.
  • questo significa che sta sprecando 167 byte per blocco usato = 12942834 byte = 12,3 MB

Quindi da dove venivano gli altri 105 MB sprecati ? È il fratello maggiore proprio accanto a questo assomiglia a questo:

**Slab 6 Stats** 
Chunk Size  744.0 Bytes
Used Chunk  17488 [31.0 %]
Total Chunk 56360
Total Page  40
Wasted      31.1 MBytes
Hits        107.7 Request/sec
Evicted     1109

Il problema è che ci sono tonnellate di spazio inutilizzato nelle altre lastre, ma la lastra 3 è piena al 100% e vede sfratti.
David Schwartz,

Bene, questo spiegherebbe gli sfratti, anche se non sono davvero sicuro di come venga calcolato il numero "sprecato". Se la lastra 8 utilizza solo il 13,9%, ci deve sicuramente essere dello spazio "libero" lasciato lì?
Nanne,

Sì, c'è spazio libero in quella lastra. Ma questo non aiuta se gli oggetti che vengono sfrattati non vanno in quella lastra.
David Schwartz,

È quello che ho capito dalla tua risposta, ma perché non c'è spazio libero elencato? Dovrebbe esserci una parte di quel grafico a torta bianco (com'è nella mia installazione di prova) se rimane ancora spazio, almeno, è quello che ho immaginato
Nanne,

Risposte:


10

È passato un anno da questa domanda e non so se hai trovato la tua risposta, ma sto per dire che la tua percezione di "spreco" è sbagliata.

La memoria sprecata viene allocata in memoria, quindi non può essere utilizzata da un'altra applicazione, ma è ancora disponibile per memcached.

Per semplificare la spiegazione, supponi di avere un memcache con 3 MB di RAM con 3 lastre:

slab class  1: chunk size     10485 perslab      100
slab class  2: chunk size    104857 perslab       10
slab class  3: chunk size   1048576 perslab        1

Esegui un singolo "set" con una dimensione di 10k. Vedrai nelle tue statistiche (approssimativamente) che hai:

0.03% used
66.6% free
33% wasted

Questo perché memcached ha allocato un singolo blocco da "slab class 1" e il 99% della memoria per quella lastra è "sprecato" e l'1% è "usato" Ciò non significa che la lastra e la memoria allocata per quella lastra siano sparite.

Esegui un altro "set" singolo con dimensioni di 10k. Questa volta vedrai:

0.06% used
66.6% free
32.7% wasted

quindi ora stai usando 2 blocchi su 100 allocati nella soletta 1, le statistiche "sprecate" sono state eliminate e le statistiche utilizzate sono state aumentate.

Non c'è nulla di sbagliato nel fatto che% + sprecato usato sia uguale al 100%. Ciò non significa che non hai più memoria, significa semplicemente che hai allocato almeno un pezzo da ogni lastra.

Per vedere questo problema, un "set" con dimensioni di 100k e un altro con dimensioni di 1000k

Adesso vedrai

36.6% used
   0% free
63.3% wasted

Suona bene! Hai qualche link per eseguire il backup? In tal caso ciò significa che il mio server memcache stava (sta) andando meglio allora pensiamo :). Se ho capito bene è che lo spreco significa che è stato allocato, ma è ancora disponibile per l'uso. Ciò significa che se nulla è gratuito non è possibile allocare più lastre, ma non dovrebbe significare che hai problemi di per sé?
Nanne,

1
Non ho un link in cima alla mia testa ma è molto facile mettersi alla prova. Premi la tua riga di comando e crea un piccolo server di esempio per testare come funziona. Puoi usare l'opzione -vv per i messaggi di debug dettagliati, che ti mostreranno le lastre create inizialmente, ad esempio: "memcached -vv -p 11500 -m 3 -n 10000 -f 10" ti creerà 3 lastre con blocchi di dimensioni 10k 100k e 1000k. E continua a pubblicare "set" e guarda le tue statistiche sprecate / usate cambiare esattamente come ho descritto sopra.
kali,

buon punto. ora per scoprire come posso ottenere qualche attenzione in più per questa risposta per te :)
Nanne,

6

Probabilmente hai un numero molto grande di oggetti molto piccoli. In genere, il solaio più piccolo contiene voci da 104 byte. Se hai molte voci che mappano solo un numero intero all'altro, puoi ottenere uno spreco dell'85%.

Puoi trovare informazioni su come sintonizzarti nell'articolo Memcached per piccoli oggetti .


Se leggo correttamente la pagina delle statistiche non è così. La maggior parte dei rifiuti è in una lastra con 480,0 byte byte. Fammi controllare se posso mostrare alcune statistiche ...
Nanne,

Oh, allora va bene e è normale, niente di cui preoccuparsi. Adesso ci sono solo meno dati. (Si noti, ad esempio, che quella lastra viene utilizzata solo per il 14%.)
David Schwartz,

Ma come è normale sprecare il 75%? Questo numero include spazio inutilizzato? Mi aspetto che sia considerato "gratuito". Inoltre, vediamo un aumento dello spreco // una diminuzione della memoria usata con il passare del giorno, mentre il sito diventa più occupato. Questo e il fatto che abbiamo degli sfratti, mi chiedo cosa si possa fare.
Nanne,

Avere un minor numero di lastre può aiutare a evitare il problema di troppa memoria che si blocca nella lastra sbagliata. Ad esempio, -f 1.5 -I 2800può aiutare.
David Schwartz,

La pagina di -I 2800manuale non è troppo chiara: il che significa 2800K, al contrario del default di 1M?
Nanne,

-1

Ho avuto questo problema e sono passato da memcached a redis (senza salvataggio su disco). So che potrebbe non essere possibile, ma potresti provarlo come opzione e tenere d'occhio la frammentazione della memoria. È anche possibile attivare la persistenza per correggere i problemi di "vecchia cache" al riavvio.

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.