Memori 'terbuang' tinggi yang tidak terduga (?) Dalam memcached


18

Diperbarui, lihat bagian bawah dari pertanyaan gondrong (maaf).

Melihat statistik memcached kami, saya pikir saya telah menemukan masalah yang tidak saya sadari sebelumnya. Tampaknya kita memiliki jumlah ruang terbuang yang anehnya tinggi. Saya memeriksa dengan phpmemcacheadmin untuk perubahan, dan menemukan gambar ini menatap saya:

grafik ukuran cache memcached

Sekarang saya mendapat kesan bahwa skenario terburuk adalah bahwa ada 50% pemborosan, meskipun saya adalah orang pertama yang mengakui tidak mengetahui semua detail. Saya telah membaca - antara lain - halaman ini yang memang agak lama, tetapi begitu juga versi memcached kami. Saya pikir saya mengerti bagaimana sistem bekerja ( misalnya ) saya percaya, tapi saya kesulitan memahami bagaimana kita bisa mendapatkan ruang terbuang 76%.

Tingkat penggusuran yang ditunjukkan oleh phpmemcacheadmin adalah 2 ev/s, jadi ada beberapa masalah di sini.

  • Pertanyaan utamanya adalah: apa yang bisa saya lakukan untuk memperbaikinya . Saya bisa melempar lebih banyak memori padanya (ada beberapa tambahan yang tersedia saya pikir), mungkin saya harus mengutak-atik konfigurasi slab (apakah itu mungkin dengan versi ini?), Mungkin ada opsi lain? Memutakhirkan versi memcached bukan pilihan yang tersedia dengan cepat.

  • Pertanyaan susu kedua, karena penasaran, tentu saja jika tingkat ruang terbuang 75% (dan naik) diharapkan, dan jika demikian, mengapa.

Sistem: Saat ini bukan sesuatu yang bisa saya lakukan, saya tahu versi memcached bukan yang terbaru, tetapi ini adalah kartu yang telah saya tangani.

  • Memcached 1.4.5
  • Apache 2.2.17
  • PHP 5.3.5

Sebagai tanggapan terhadap jawaban @DavidSchwartz: berikut adalah statistik slab yang dihasilkan oleh phpmemcacheadmin: (ada lebih banyak slab daripada ini)

( Saya juga menempelkan statistik dari sedikit kemudian dalam format teks di sini )

Rincian pelat

MEMPERBARUI

Saya telah me-restart daemon dengan -f 1.5, dan itu terlihat sangat bagus. Setelah beberapa pemanasan kami menggunakan / membuang 50/50. Tapi, sama seperti sebelumnya, semakin lama kita dalam sehari (semakin sibuk di siang hari) mulai kembali seperti sekarang: 30/70, dan sia-sia masih meningkat. Selain itu, saya masih tidak tahu dari mana 'sia-sia' itu berasal. Saya melihat lempengan ini:

**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

Itu tidak penuh, tidak ada yang diusir, tetapi menghabiskan 117,3 MBytes. Perhitungan cepat yang saya lakukan (koreksi saya jika saya salah) adalah:

  • slab sebelumnya memiliki ukuran chunk 328, jadi kasus terburuk slab ini diisi dengan potongan 329 byte.
  • ini berarti ia membuang 167 byte per chunk yang digunakan = 12942834 byte = 12,3 MB

Jadi, dari mana asal 105 MB lainnya yang terbuang ? Ini kakak yang lebih besar di sebelahnya terlihat seperti ini:

**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

Masalahnya adalah bahwa ada banyak ruang yang tidak digunakan di lempengan lain, namun lempengan 3 adalah 100% penuh dan melihat penggusuran.
David Schwartz

Poin bagus, itu akan menjelaskan penggusuran, meskipun saya tidak begitu yakin bagaimana angka 'terbuang' dihitung. Jika slab 8 hanya memiliki 13,9% yang digunakan, pasti ada ruang "bebas" yang tersisa?
Nanne

Ya, ada ruang kosong di lempengan itu. Tapi itu tidak membantu jika benda yang digusur tidak masuk dalam lempengan itu.
David Schwartz

Itulah yang saya perkirakan dari jawaban Anda, tetapi mengapa tidak ada ruang kosong yang terdaftar? Seharusnya ada beberapa bagian dari pie-chart putih (seperti yang ada pada instalasi tes saya) jika masih ada ruang yang tersisa, setidaknya, itulah yang saya pikir
Nanne

Jawaban:


10

Sudah setahun sejak pertanyaan ini dan saya tidak tahu apakah Anda menemukan jawaban Anda, tetapi saya akan mengatakan persepsi Anda tentang "sia-sia" salah.

Memori terbuang dialokasikan dalam memori sehingga tidak dapat digunakan oleh aplikasi lain, tetapi masih tersedia untuk memcached.

Untuk menyederhanakan penjelasan, anggap Anda memiliki memcache dengan ram 3MB dengan 3 Slab:

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

Jalankan "set" tunggal dengan ukuran 10k. Anda akan melihat dalam statistik (secara kasar) yang Anda miliki:

0.03% used
66.6% free
33% wasted

Ini karena memcached mengalokasikan satu potongan dari "slab class 1" dan 99% memori untuk slab itu "terbuang" dan 1% "digunakan" Ini tidak berarti bahwa slab dan memori yang dialokasikan untuk slab itu hilang.

Jalankan single lain "set" dengan ukuran 10k. Kali ini Anda akan melihat:

0.06% used
66.6% free
32.7% wasted

jadi sekarang Anda menggunakan 2 dari 100 potongan yang dialokasikan di slab 1, statistik "terbuang" turun, dan statistik yang digunakan meningkat.

Tidak ada yang salah untuk% bekas +% terbuang sama dengan 100%. Itu tidak berarti Anda tidak memiliki memori lagi, itu hanya berarti Anda mengalokasikan setidaknya satu potongan dari masing-masing dan setiap lempengan.

Untuk melihat masalah ini, "set" dengan ukuran 100k dan yang lain dengan ukuran 1000k

Sekarang kamu akan lihat

36.6% used
   0% free
63.3% wasted

Boleh juga! Apakah Anda memiliki tautan untuk mendukung ini? Jika demikian itu berarti server memcache saya berkinerja lebih baik maka kami pikir :). Jika saya mengerti Anda dengan benar adalah bahwa yang terbuang berarti telah dialokasikan, tetapi masih tersedia untuk digunakan. Ini berarti bahwa jika tidak ada yang gratis, Anda tidak dapat mengalokasikan lebih banyak pelat, tetapi bukankah seharusnya Anda memiliki masalah sendiri?
Nanne

1
Saya tidak memiliki tautan di atas kepala saya tetapi sangat mudah untuk menguji diri sendiri. Tekan baris perintah Anda dan buat sampel server kecil untuk menguji cara kerjanya. Anda dapat menggunakan opsi -vv untuk pesan debug verbal, yang akan menunjukkan kepada Anda slab awal yang dibuat yaitu: "memcached -vv -p 11500 -m 3 -n 10000 -f 10" akan membuat Anda 3 slab dengan ukuran chunk 10k 100k dan 1000k. Dan terus menerbitkan "set" dan melihat statistik Anda yang terbuang / digunakan berubah persis seperti yang saya jelaskan di atas.
kali

Poin yang bagus. sekarang untuk mencari tahu bagaimana saya bisa mendapatkan perhatian ekstra untuk jawaban ini untuk Anda :)
Nanne

6

Anda mungkin memiliki sejumlah besar benda yang sangat kecil. Biasanya, slab terkecil menampung 104 byte entri. Jika Anda memiliki banyak entri yang hanya memetakan satu bilangan bulat ke yang lain, Anda bisa mendapatkan limbah hingga 85%.

Anda dapat menemukan informasi tentang cara menyetel ini dalam artikel Memcached untuk objek kecil .


Jika saya membaca halaman statistik dengan benar, ini bukan masalahnya. Sebagian besar limbah ada di slab dengan 480,0 Byte-chunks. Biarkan saya memeriksa Jika saya dapat menunjukkan beberapa statistik ...
Nanne

Oh, maka ini baik dan normal, tidak ada yang perlu dikhawatirkan. Hanya ada sedikit data di sana sekarang. (Perhatikan, misalnya, bahwa lempengan itu hanya digunakan 14%.)
David Schwartz

Tapi bagaimana 75% terbuang normal? Apakah nomor ini termasuk ruang yang tidak digunakan? Saya berharap itu dihitung sebagai "gratis". Selain itu, kami melihat peningkatan pemborosan // penurunan memori yang digunakan seiring berjalannya waktu, sementara situs menjadi lebih sibuk. Itu, dan fakta bahwa kami memang punya penggusuran, membuat saya bertanya-tanya apa yang bisa dilakukan.
Nanne

Memiliki lebih sedikit pelat dapat membantu menghindari masalah terlalu banyak memori yang tersangkut di lempengan yang salah. Misalnya, -f 1.5 -I 2800dapat membantu.
David Schwartz

Halaman manualnya tidak terlalu jelas: the -I 2800, itu berarti 2800K, berbeda dengan standar 1M?
Nanne

-1

Saya mengalami masalah ini dan pindah dari memcached ke redis (tanpa penyimpanan berbasis disk). Saya tahu ini mungkin tidak mungkin tetapi Anda bisa mencobanya sebagai pilihan dan mengawasi fragmentasi memori. Anda bahkan dapat mengaktifkan kegigihan untuk memperbaiki masalah "cache lama" saat restart.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.