Здравствуйте, Михаил!
Wednesday, July 25, 2007, 2:46:09 PM, you wrote:
GM>> некоторые особенности работы:
ММ> Тут старая информация. memcached уже несколько иначе работает.
какие есть отличия между этим описанием и работой memcached 1.2.2 ?
avva> У каждого класса отдельно есть своя LRU queue всех записей в этом классе ?
avva> каждый раз, когда кто-то просит прочесть какую-то запись, она перемещается
avva> в начало списка своего класса. Таким образом, в конце списка находятся те
записи,
avva> которых давно никто не просил ? их куски освобождаются, когда нужно место
для новой
avva> записи в этом классе, и нельзя больше согласно конфигурации попросить
памяти у системы."
PS в версии 1.2.0 были проведены улучшения связанные с более эффективным
использованием оперативной памяти. но алгоритмы работы остались теми же.
[...]
Memory consumption
------------------
The slab allocator's powers-of-2 size strategy is now a powers-of-N
strategy, where N may be specified on the command line using the new
"-f" option. The default is 1.25. For a large memcached instance, where
there are enough items of enough different sizes that the increased
number of slab classes isn't itself a waste of memory, this is a
significant win: items are placed in chunks whose sizes are much closer
to the item size, wasting less memory.
One consequence of this is that slabs are no longer fixed-size; by
default they are no bigger than 1MB each, but are only as big as they
need to be to hold a whole number of chunks. That causes the "slabs
reassign" command to be unavailable; it can be reenabled by compiling
with -DALLOW_SLABS_REASSIGN at the expense of some wasted memory (all
slabs will be 1MB).
The minimum amount of space for data in chunks of the smallest slab
class may be adjusted on the command line using the new "-s" option.
Each chunk is that many bytes plus the size of the fixed-size item
header. If you have a lot of items with small fixed-size keys and
values, you can use this option to maximize the number of items per slab
in the smallest slab class; experiment with your particular data to find
the optimal value.
Item expiration times and access times are now stored as 32-bit integers
(number of seconds relative to server start) rather than time_t, which
is 64 bits on some platforms. This saves 8 bytes per item when compiled
in 64-bit mode, and is harmless otherwise.
[...]
--
Best regards,
Gena mailto:makhomed@xxxxxxxxxxxxxx
