Скачать sharedhashfile - sharedhashfile SourceD Code Скачать

sharedhashfile

Исходный код С#

1.0.0

Скачать

Sharedhashfile: Общие хэш -таблицы со стабильными ключами, хранящимися в файлах отображения памяти между произвольными процессами

SharedHashFile-это легкий, встроенный встроенный клавиш nosql Store Store / Hash Table со стабильными подсказками ключей, очередью IPC с нулевой копией и мультиплексной библиотекой журнала IPC, записанной в C для Linux. Данные доступны непосредственно в общей памяти; Глевы не используются между Sharedhashfile и прикладной программой; Нет серверного процесса. API для C & C ++.

Цели проекта

Более высокая скорость.
Проще и меньше.
Более низкое использование памяти.
Одновременно, в доступе к памяти.

Технология

Хранилище данных

Данные хранятся в общей памяти по умолчанию, делая все данные доступными для любых процессов. До 4 миллиардов ключей можно хранить в одной таблице хэш -хеш -фон ShareDhashFile, которая ограничена по размеру только доступной оперативной памятью.

Например, допустим, у вас есть коробка с 128 ГБ, из которой 96 ГБ используется хэш -таблицами Sharedhashfile. Коробка имеет 24 ядра, и существует 24 процесса (например, раздвоенные процессы Nginx или что -то еще) одновременно доступа к 96 ГБ хэш -таблиц. Каждый процесс разделяет точно одинаковые 96 ГБ общей памяти.

Прямой доступ к памяти

Поскольку ключ, пара значений проводится в общей памяти в процессах N, общая память может измениться и/или перемещаться в любое время. Следовательно, получение значения всегда приводит к получению локальной копии потока значения.

Кодирование данных

Ключи и значения в настоящее время представляют собой двоичные строки, с комбинированной максимальной длиной 2^32 байтов.

Распределение и коллекция мусора

Обычный Malloc () не функционирует в общей памяти, поскольку мы должны использовать смещения вместо обычных указателей. Следовательно, Sharedhashfile использует свою собственную реализацию Malloc () для общей памяти.

Чтобы избежать отверстий памяти, сбором мусора происходит время от времени после ключа, вставка значений. Количество клавиш, пары значений, осуществляемые во время сбора мусора, намеренно ограничено алгоритмом максимум 8 192 пар независимо от того, сколько ключей было вставлено в хэш -таблицу. Это означает, что хэш -таблица всегда кажется очень отзывчивой.

Хэш -расширение таблицы

Sharedhashfile предназначен для изящного расширения как более ключевых, вставленных пар стоимости. Нет внезапного увеличения памяти или удвоения памяти. И нет больших пауз из -за перефразирования клавиш.

Блокировка

Чтобы уменьшить конфликт, нет единого глобального хеш -таблицы по дизайну. Вместо этого клавиши нарушаются по 256 замкам, чтобы уменьшить конфликт с замком.

Необязательные ключи и значения с фиксированной длиной

Для вариантов использования с высоким уровнем письма, тогда производительность может пострадать из -за слишком большого количества вызовов MMAP () из -за переработки / сокращения областей отображения памяти при удалении отверстий памяти из -за удаленных ключей.

Чтобы повысить производительность для вариантов использования Write Heavy, клавиши и значения могут быть зафиксированы по размеру по всей таблице хэш, что означает, что удаленные клавиши могут быть легко использованы без создания отверстий памяти, и никаких дорогих системных вызовов MMAP () не требуется.

Использование клавиш и значения с фиксированной длиной также уменьшает количество используемой оперативной памяти, поскольку размеры ключей и значения больше не хранятся, например, 100 миллионов ключей и значений сэкономит 100 миллионов * 8 байт = 800 миллионов байт.

Постоянное хранение

Хэш -таблицы хранятся в отображенных файлах памяти в /dev/shm что означает, что данные сохраняются, даже если никакие процессы не используют хэш -таблицы. Тем не менее, хэш -таблицы не выживут перезагрузки.

Уникальные идентификаторы, известные как стабильные ключевые подсказки

В отличие от других хэш -таблиц, каждому ключ, хранящемуся в Sharedhashfile, назначается свой собственный UID, например shf_make_hash("key", 3); uint32_t uid = shf_put_key_val(shf, "val", 3) . Чтобы получить тот же ключ в будущем, выберите между доступом к клавишу через его ключ или через его UID, например shf_make_hash("key", 3); shf_get_key_val_copy(shf) или shf_get_uid_val_copy(shf, uid) .

Для чего полезно UIDS? UIDS не принимают дополнительных ресурсов и могут рассматриваться как ресурс «бесплатно». Доступ к клавишу с помощью его UID быстрее, чем доступ к ключу через свой ключ. Поскольку UID составляет всего 32 млрд. В размере, его можно легко хранить в качестве ссылки на ключ в вашей программе или встроен в значения ключа, пары значений или даже встроенные в другие ключи.

Пример использования: если UID1 указывает на ключ "user-id-<xyz>" , а UID2 указывает на ключ "facebook.com" , то еще один ключ «MASH UP может быть "<uid1><uid2>" . Хотите узнать, имеет ли "user-id-<xyz>" "facebook.com" в своем личном белом списке URL-адреса? Просто посмотрите, существует ли ключ "<uid1><uid2>" .

Что означает «стабильная» в «стабильном ключе»? Это означает, что UID остается таким же, даже если байты ключа и/или значения перемещаются в памяти.

Очерки IPC с нулевой копией

Как это работает? Создайте x фиксированные элементы очереди и очереди y, чтобы подтолкнуть и вытащить эти элементы очереди в/от.

Пример: представьте, что два процесса Process A & Process B . Process A создает 100 000 элементов очереди и 3 очереди; queue-free , queue-a2b и queue-b2a . Впоследствии, все элементы очереди наносят на queue-free . Process A затем порождает Process B , который прикрепляется к Sharedhashfile, чтобы вытащить из queue-a2b . Чтобы выполнить IPC с нулевой копией, Process A Can Cune Ofeue из queue-free , манипулируйте фиксированным размером, общими элементами очередей памяти и вставьте элементы очереди в queue-a2b . Process B делает наоборот; Потягивает элементы очереди из queue-a2b , манипулирует фиксированным размером, общие элементы очереди памяти и вкладывает элементы очереди в queue-b2a . Process A также может вытащить элементы очереди из queue-b2a , чтобы переварить результаты Process B

Итак, сколько элементов очереди в секунду можно перемещать взад -вперед Processes A & Process B ? На ноутбуке Lenovo W530 тогда около 90 миллионов в секунду, если оба Process A & Process B написаны на C.

ПРИМЕЧАНИЕ. Когда элемент очереди перемещается из одной очереди в другую, он не копируется, обновляется только ссылка.

Мультиплексированный журнал IPC

Как это работает? Process A вызовы shf_log_thread_new (), который создает буфер журнала общей памяти и поток вывода журнала, который периодически контролирует новые строки журнала. Process B вызывает shf_log_attach_existing (), чтобы начать журнал в том же общем журнале. Журнал с использованием c macros shf_plain () и shf_debug (). Если SHF_LOG_THREAD_NEW () не был вызван, то вывод автоматически переходит к STDOUT, в противном случае журнал мультиплексируется потоком вывода журнала.

Пример вывода:

 sharedhashfile$ cat debug/test.q.shf.t.tout
1..10
=0.000000 23056 pid 23056 started; mode is 'c2c'
=0.000013 23056 - SHF_SNPRINTF() // 'test-23056-ipc-queue'
ok 1 -    c2*: shf_attach()          works for non-existing file as expected
=0.000002 23060 shf.monitor: monitoring pid 23056 to delete /dev/shm/test-23056-ipc-queue.shf
1..7
=0.000001 23064 pid 23064 started; mode is '4c'
=0.000010 23064 - SHF_SNPRINTF() // 'test-23064-ipc-queue'
ok 1 -     4c: shf_attach_existing() works for existing file as expected
#0.003948 1 --> auto mapped to thread id 23061
#0.003948 1 shf_log_thread(shf=?){}
ok 2 -    c2*: put lock in value as expected
ok 3 -    c2*: shf_q_new() returned as expected
ok 4 -    c2*: moved   expected number of new queue items // estimate 51,044,225 q items per second without contention
#0.131327 2 --> auto mapped to thread id 23064
#0.131327 2 '4c' mode; behaving as client
ok 2 -     4c: shf_q_get_name('qid-free') returned qid as expected
ok 3 -     4c: shf_q_get_name('qid-a2b' ) returned qid as expected
ok 4 -     4c: shf_q_get_name('qid-b2a' ) returned qid as expected
#0.158467 2 shf_race_start() // 2 horses started after 0.000001 seconds
#0.158474 2 testing process b IPC queue a2b --> b2a speed
#0.158467 3 --> auto mapped to thread id 23056
#0.158467 3 shf_race_start() // 2 horses started after 0.027820 seconds
#0.158484 3 testing process a IPC queue b2a --> a2b speed
ok 5 -     4c: moved   expected number of new queue items // estimate 53,106,512 q items per second with contention
#0.179207 2 testing process b IPC lock speed
ok 6 -     4c: got lock value address as expected
ok 5 -    c2*: moved   expected number of new queue items // estimate 52,951,698 q items per second with contention
#0.180467 3 testing process a IPC lock speed
ok 6 -    c2*: got lock value address as expected
#0.180475 3 shf_race_start() // 2 horses started after 0.000000 seconds
#0.180475 2 shf_race_start() // 2 horses started after 0.001165 seconds
ok 7 -    c2*: rw lock expected number of times           // estimate 4,422,109 locks per second; with contention
ok 7 -     4c: rw lock expected number of times           // estimate 4,411,319 locks per second; with contention
#0.633875 2 ending child
ok 8 -    c2*: rw lock expected number of times           // estimate 51,144,435 locks per second; without contention
ok 9 -    c2*: rw lock expected number of times           // estimate 381,821,029 locks per second; without lock, just loop
ok 10 -    c2*: test still alive
#0.677166 3 ending parent
#0.677177 3 shf_del(shf=?)
#0.677180 3 - SHF_SNPRINTF() // 'du -h -d 0 /dev/shm/test-23056-ipc-queue.shf ; rm -rf /dev/shm/test-23056-ipc-queue.shf/'
#0.677181 3 shf_detach(shf=?)
#0.677183 3 shf_log_thread_del(shf=?) // waiting for log thread to end
=0.686385 3 shf_backticks('du -h -d 0 /dev/shm/test-23056-ipc-queue.shf ; rm -rf /dev/shm/test-23056-ipc-queue.shf/')
=0.724220 3 - read 39 bytes from the pipe
test: shf size before deletion: 394M /dev/shm/test-23056-ipc-queue.shf

Примечания:

Приведенный выше пример показывает выход из 4 различных идентификаторов потока:
- 29912 является идентификатором потока основного потока программы тестовой программы; АКА '3'.
- 29916 - это идентификатор потока основного потока программы SHF.Monitor; Никогда не участвуйте в мультиплексированном журнале.
- 29917 - идентификатор потока потока вывода журнала тестовой программы; ака '1'.
- 29920 является идентификатором потока основного потока программы тестовой программы; рекурсивно породится с 29912; АКА '2'.
Строки, начиная с '=':
- Были выводом в Stdout; IE LINES, зарегистрированные до или после того, как существует поток вывода журнала.
- Покажите марку времени относительно начала журнала процесса.
- Показать 5 -значный идентификатор потока.
Линии, начиная с '#':
- Были выводились в stdout с помощью потока вывода журнала.
- Покажите марку Time по сравнению с началом потока вывода журнала.
- Показать идентификатор потока, нанесенный на карту с уникальным коротким целым числом; 1 Обычно означает сам поток вывода журнала.
Другие линии - например, линии «ОК» - автоматически станут мультиплексированными линиями журнала, если существует поток вывода журнала.

Здание

Создайте код выпуска, используя make , и код отладки, используя make debug . Тесты запускаются автоматически.

 root@16vcpu:/# make clean ; make
rm -rf release debug
make: variable: PROD_SRCS=murmurhash3.c shf.c tap.c
make: variable: PROD_OBJS=release/murmurhash3.o release/shf.o release/tap.o
make: variable: TEST_SRCS=test.1.tap.c test.9.shf.c
make: variable: TEST_OBJS=release/test.1.tap.o release/test.9.shf.o
make: variable: TEST_EXES=release/test.1.tap.t release/test.9.shf.t
make: compling: release/test.1.tap.o
make: compling: release/murmurhash3.o
make: compling: release/shf.o
make: compling: release/tap.o
make: linking: release/test.1.tap.t
make: running: release/test.1.tap.t
1..1
ok 1 - All passed
make: compling: release/test.9.shf.o
make: linking: release/test.9.shf.t
make: running: release/test.9.shf.t
1..10
ok 1 - shf_attach_existing() fails for non-existing file as expected
ok 2 - shf_attach()          works for non-existing file as expected
ok 3 - shf_get_copy_via_key() could not find unput key as expected
ok 4 - shf_get_copy_via_key() could     find   put key as expected
ok 5 - put expected number of              keys // 2293581 keys per second
ok 6 - got expected number of non-existing keys // 3812667 keys per second
ok 7 - got expected number of     existing keys // 3021523 keys per second
ok 8 - graceful growth cleans up after itself as expected
ok 9 - del expected number of     existing keys // 3109056 keys per second
ok 10 - del does not   clean  up after itself as expected
running tests on: via command: 'cat /proc/cpuinfo | egrep 'model name' | head -n 1'
running tests on: `model name   : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz`
-OP MMAP REMAP SHRK PART TOTAL ------PERCENT OPERATIONS PER PROCESS PER SECOND -OPS
--- -k/s --k/s --/s --/s M-OPS 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 -M/s
PUT  3.4  16.9 1298  626   0.0 10 10  8  5  3  2  8  9  9  6  2  8  4  7  8  4  0.0
PUT 51.4 363.7 1410 1200   5.4  7  6  7  6  7  5  6  7  6  6  6  7  7  6  5  6  5.4 -------
PUT 65.2 336.9 2036 2036  10.1  7  5  7  6  7  6  7  7  6  6  6  7  7  6  5  6  4.6 ------
PUT 56.8 331.7 1888 1888  14.9  6  5  6  7  6  7  7  7  6  6  6  7  7  6  5  6  4.9 ------
PUT 73.8 286.8 2200 2200  18.8  7  5  5  7  7  7  7  7  6  7  6  6  6  5  5  7  3.9 -----
PUT 21.2 412.9  726  726  25.1  6  5  5  7  7  8  7  7  6  6  6  6  6  5  5  7  6.3 --------
PUT 77.9 312.0 2554 2557  29.3  6  6  6  6  6  7  6  6  6  6  6  7  6  6  6  7  4.2 -----
PUT 96.7 272.2 3044 3041  32.5  7  6  6  6  6  7  6  6  6  7  6  7  6  6  6  7  3.1 ----
PUT 63.3 303.3 1804 1804  36.6  7  6  6  5  5  7  6  7  5  6  5  7  7  6  6  7  4.2 -----
PUT 11.5 380.9  349  349  43.2  7  6  6  5  5  7  6  6  6  5  6  7  7  6  6  6  6.6 --------
PUT 26.3 444.5  895  898  49.1  7  6  6  5  5  7  6  7  6  6  6  7  7  6  6  7  5.9 -------
PUT 55.0 283.9 1862 1860  53.8  5  6  6  6  6  6  5  7  6  6  7  7  7  6  6  7  4.7 ------
PUT 75.0 312.1 2480 2480  57.4  7  7  6  5  6  5  7  7  6  6  7  7  6  7  5  6  3.6 ----
PUT 88.5 191.2 2859 2858  60.6  7  7  6  6  7  6  7  5  7  5  7  7  6  7  6  5  3.2 ----
PUT 90.6 244.9 2853 2854  63.5  7  7  5  7  7  5  7  5  7  5  7  7  6  7  7  5  2.9 ---
PUT 82.6 258.8 2455 2455  66.4  7  7  5  7  7  6  7  5  6  5  7  7  5  7  6  5  3.0 ---
PUT 69.7 185.9 1970 1970  70.3  7  7  6  5  7  6  7  6  5  5  7  7  6  7  7  5  3.9 -----
PUT 28.8 409.6  761  760  75.6  6  7  6  6  6  5  6  6  7  5  7  7  5  7  7  6  5.2 ------
PUT  7.2 490.9  230  230  82.0  6  8  5  6  6  5  5  6  5  5  7  8  6  8  7  6  6.4 --------
PUT 11.1 414.9  391  391  88.4  6  7  7  6  6  5  5  6  6  5  6  7  5  7  7  6  6.4 --------
PUT 22.3 323.4  810  810  94.5  7  8  8  7  6  6  5  7  6  5  7  2  6  8  7  7  6.1 --------
PUT 26.1 302.4 1124 1124  99.3  2  5  8  9  7  8 10  1  9  9  6  0  8  4  9  6  4.8 ------
PUT  1.6   6.8  239  239 100.0  0  0  0  0  0  0  0  0 14 58  0  0  5  0 23  0  0.7
MIX  0.0   0.0    0    0 100.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
MIX 21.8 103.9    0    0 105.3  5  6  6  7  7  7  7  5  8  6  6  3  7  6  7  7  5.3 -------
MIX  0.5   8.2    0    0 114.0  6  6  5  6  7  5  6  7  7  6  7  6  7  7  6  6  8.7 -----------
MIX  0.0   8.5    0    0 122.8  6  6  5  6  7  5  6  7  7  6  7  6  7  7  6  6  8.7 -----------
MIX  0.0   9.6    0    0 131.7  6  6  6  6  7  6  6  7  6  6  7  6  7  7  6  6  8.9 -----------
MIX  0.0  11.1    0    0 140.8  6  6  7  6  7  6  5  7  6  6  7  5  7  7  5  6  9.1 ------------
MIX  0.0  12.0    0    0 149.6  6  6  7  7  6  6  6  6  7  6  6  6  6  6  6  7  8.8 -----------
MIX  0.0  12.7    0    0 158.3  7  6  6  7  6  6  7  6  7  6  6  6  6  6  7  7  8.7 -----------
MIX  0.0  14.0    0    0 167.1  7  6  6  7  6  6  7  6  7  6  6  6  6  6  7  7  8.8 -----------
MIX  0.0  14.7    0    0 176.2  7  6  6  5  6  6  7  6  7  6  6  5  6  6  7  7  9.1 ------------
MIX  0.0  16.3    0    0 185.1  6  7  7  7  7  7  6  6  6  5  6  7  6  5  6  6  8.9 -----------
MIX  0.0  17.0    0    0 194.3  6  7  7  7  7  6  6  6  6  5  6  7  6  5  6  6  9.2 ------------
MIX  0.0   7.1    0    0 200.0  9  9  7  2  3 10  9  5  0 11  4 14  3  7  6  1  5.7 -------
GET  0.0   0.0    0    0 200.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
GET  0.0   2.1    0    0 200.3  3  6  7  6  7  6  6  6  7  7  7  3  7  7  7  7  0.3
GET  0.0   2.4    0    0 208.5  6  6  6  6  7  6  6  6  7  6  7  6  6  7  6  7  8.2 ----------
GET  0.0   0.0    0    0 217.4  6  7  7  6  7  5  6  6  7  6  7  6  6  7  6  6  8.9 -----------
GET  0.0   0.0    0    0 226.3  6  7  8  6  7  5  6  6  7  5  7  5  6  7  6  5  9.0 -----------
GET  0.0   0.0    0    0 235.3  6  7  7  6  8  5  6  6  8  5  7  5  5  7  6  6  9.0 -----------
GET  0.0   0.0    0    0 244.2  6  7  6  8  7  5  6  6  7  6  7  6  6  5  6  6  8.9 -----------
GET  0.0   0.0    0    0 253.5  5  8  5  8  6  6  7  8  7  5  8  5  5  5  7  5  9.3 ------------
GET  0.0   0.0    0    0 263.1  4  8  5  9  5  5  8  9  5  5  8  5  5  5  8  5  9.6 ------------
GET  0.0   0.0    0    0 272.9  4  8  5  7  5  7  8  9  5  5  8  5  5  5  8  5  9.8 -------------
GET  0.0   0.0    0    0 282.3  5  7  5  6  8  7  7  8  5  5  7  5  5  6  7  5  9.4 ------------
GET  0.0   0.0    0    0 291.0  6  2  6  6  9 10  8  4  6  6  2  6  6  6  8  6  8.7 -----------
GET  0.0   0.0    0    0 298.7 12  0 10  3  0  9  0  0  4 12  0 12 13  9  0 15  7.7 ----------
GET  0.0   0.0    0    0 300.0 32  0  0  0  0  0  0  0  0 23  0 27 18  0  0  0  1.3 -
* MIX is 2% (2000000) del/put, 98% (12100654) get
make: built and tested release version

Примечания:

Вышеуказанные цифры были сгенерированы на облачном сервере Rackspace с 16 VCPU и 60 ГБ оперативной памяти.
Линия статистики выводится каждую секунду во время теста.
Во время фазы «пут» 16 параллельных процессов вкладывают 100 миллионов уникальных ключей в хэш -таблицу.
Затем во время фазы «микс» 16 одновременных процессов получают 98% из 100 миллионов уникальных ключей при обновлении (del/put) остальных 2%.
Затем во время фазы «получить» 16 одновременных процессов получают 100 миллионов уникальных ключей из хэш -таблицы; В этом случае до 9,8 млн. Получают операции в секунду в 16 параллельных процессах.
В общей сложности выполняются 300 миллионов хэш -таблиц.
Почему производительность так сильно различается? Это связано с картированием памяти ядра; «Top» показывает более широкое использование процессора системы.

Производительность

Вот пример на 8 -основном ноутбуке Lenovo W530, показывающем хэш -таблицу с 100 миллионами ключей, а затем выполнение 2% Delete/INSERT и 98% считывается по ставке более 10 миллионов операций в секунду:

 $ make clean ; make release
$ PATH=release:$PATH SHF_PERFORMANCE_TEST_ENABLE=1 test.f.shf.t
...
perf testing: SharedHashFile
running tests on: via command: 'cat /proc/cpuinfo | egrep 'model name' | head -n 1'
running tests on: `model name   : Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz`
-OP MMAP REMAP SHRK PART TOTAL ------PERCENT OPERATIONS PER PROCESS PER SECOND -OPS
--- -k/s --k/s --/s --/s M-OPS 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 -M/s
PUT  0.2   0.0    0    0   0.0 32 30  0  0  0  0  0 38  0  0  0  0  0  0  0  0  0.0
PUT 30.0  89.4 1767 1767   4.5 13 13 13 12 13 12 12 13  0  0  0  0  0  0  0  0  4.5 -----
PUT 30.6  70.8 1925 1925   8.6 13 12 13 13 13 12 13 12  0  0  0  0  0  0  0  0  4.1 -----
PUT 17.1 103.3 1090 1090  13.7 12 12 13 13 13 12 13 13  0  0  0  0  0  0  0  0  5.1 ------
PUT 37.2  47.6 2334 2334  16.4 13 12 13 13 13 12 12 13  0  0  0  0  0  0  0  0  2.6 ---
PUT 15.7  88.1  944  944  21.4 13 12 13 12 12 12 13 12  0  0  0  0  0  0  0  0  5.0 ------
PUT 15.6 105.9 1035 1035  26.1 13 12 13 12 13 12 13 13  0  0  0  0  0  0  0  0  4.7 ------
PUT 34.3  63.6 2180 2181  29.3 13 12 13 12 12 13 12 13  0  0  0  0  0  0  0  0  3.1 ----
PUT 39.7  48.8 2478 2478  31.9 13 12 13 12 13 13 13 12  0  0  0  0  0  0  0  0  2.7 ---
PUT 32.1  47.3 1950 1949  35.0 12 12 12 12 13 13 12 12  0  0  0  0  0  0  0  0  3.0 ----
PUT  9.2 108.6  542  542  40.6 13 13 13 12 13 12 13 13  0  0  0  0  0  0  0  0  5.7 -------
PUT  8.4 132.2  552  552  46.4 13 12 13 12 12 12 13 12  0  0  0  0  0  0  0  0  5.8 -------
PUT 18.1  44.8 1184 1184  51.0 12 12 13 12 12 13 12 13  0  0  0  0  0  0  0  0  4.6 ------
PUT 25.3  98.8 1622 1622  54.4 13 12 13 12 13 12 13 13  0  0  0  0  0  0  0  0  3.4 ----
PUT 27.0  52.5 1730 1730  56.9 12 13 12 13 13 12 12 13  0  0  0  0  0  0  0  0  2.5 ---
PUT 35.4  67.9 2260 2260  59.4 13 13 13 13 13 13 12 12  0  0  0  0  0  0  0  0  2.5 ---
PUT 38.1  52.3 2382 2383  61.9 13 12 12 13 13 13 13 12  0  0  0  0  0  0  0  0  2.5 ---
PUT 37.2  18.8 2306 2306  64.4 13 13 12 13 13 13 12 12  0  0  0  0  0  0  0  0  2.5 ---
PUT 33.7  25.1 2059 2059  67.1 13 12 12 13 12 13 13 12  0  0  0  0  0  0  0  0  2.8 ---
PUT 23.8  75.4 1427 1426  70.1 13 12 12 13 13 13 13 12  0  0  0  0  0  0  0  0  3.0 ---
PUT 12.2 191.3  705  706  73.9 12 13 13 13 13 13 12 12  0  0  0  0  0  0  0  0  3.8 -----
PUT  4.5  15.7  270  269  80.8 12 12 13 13 13 13 12 12  0  0  0  0  0  0  0  0  6.9 ---------
PUT  5.2 129.8  347  347  87.0 13 12 13 12 13 13 12 12  0  0  0  0  0  0  0  0  6.2 --------
PUT  8.4 133.8  557  557  92.4 13 13 12 13 12 13 12 13  0  0  0  0  0  0  0  0  5.4 -------
PUT 14.3   6.2  933  933  97.3 13 12 12 13 12 13 13 12  0  0  0  0  0  0  0  0  4.9 ------
PUT 11.5  16.5  777  777 100.0 11 15 10 13 11 12 13 15  0  0  0  0  0  0  0  0  2.7 ---
MIX  0.0   0.0    0    0 100.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
MIX  2.3   5.6    0    0 101.2 12 14 11 12 12 12 13 13  0  0  0  0  0  0  0  0  1.2 -
MIX  0.3   3.9    0    0 110.4 12 13 13 13 12 13 12 13  0  0  0  0  0  0  0  0  9.2 ------------
MIX  0.0   4.1    0    0 119.7 13 13 13 12 12 13 13 13  0  0  0  0  0  0  0  0  9.3 ------------
MIX  0.0   5.3    0    0 129.4 13 13 12 13 12 13 12 13  0  0  0  0  0  0  0  0  9.8 -------------
MIX  0.0   5.6    0    0 139.0 13 13 12 12 12 13 13 12  0  0  0  0  0  0  0  0  9.6 ------------
MIX  0.0   6.3    0    0 148.5 13 13 13 12 12 12 13 12  0  0  0  0  0  0  0  0  9.5 ------------
MIX  0.0   7.0    0    0 158.4 13 13 13 12 12 13 12 13  0  0  0  0  0  0  0  0  9.9 -------------
MIX  0.0   7.0    0    0 167.7 12 13 13 12 12 13 12 13  0  0  0  0  0  0  0  0  9.3 ------------
MIX  0.0   7.9    0    0 176.7 13 13 13 13 12 13 12 13  0  0  0  0  0  0  0  0  9.1 ------------
MIX  0.0   8.7    0    0 186.5 13 12 13 13 12 13 12 13  0  0  0  0  0  0  0  0  9.8 -------------
MIX  0.0   8.7    0    0 196.0 13 13 13 12 12 12 12 13  0  0  0  0  0  0  0  0  9.5 ------------
MIX  0.0   3.5    0    0 200.0 10  8 12 15 17 11 15 11  0  0  0  0  0  0  0  0  4.0 -----
GET  0.0   0.0    0    0 200.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
GET  0.0   0.6    0    0 206.5 13 13 13 12 10 13 13 13  0  0  0  0  0  0  0  0  6.5 --------
GET  0.0   0.0    0    0 217.9 13 12 13 13 12 12 12 13  0  0  0  0  0  0  0  0 11.4 ---------------
GET  0.0   0.0    0    0 229.3 13 12 13 13 13 11 12 13  0  0  0  0  0  0  0  0 11.4 ---------------
GET  0.0   0.0    0    0 240.6 13 13 13 13 13 12 12 13  0  0  0  0  0  0  0  0 11.3 ---------------
GET  0.0   0.0    0    0 251.9 13 13 13 12 13 13 10 13  0  0  0  0  0  0  0  0 11.3 ---------------
GET  0.0   0.0    0    0 263.2 12 12 13 12 13 13 12 13  0  0  0  0  0  0  0  0 11.3 ---------------
GET  0.0   0.0    0    0 274.4 13 13 13 13 12 13 13 11  0  0  0  0  0  0  0  0 11.2 --------------
GET  0.0   0.0    0    0 285.9 12 13 13 13 12 12 13 13  0  0  0  0  0  0  0  0 11.5 ---------------
GET  0.0   0.0    0    0 297.3 12 13 13 13 12 12 13 12  0  0  0  0  0  0  0  0 11.4 ---------------
GET  0.0   0.0    0    0 300.0  6  9  0 11 22 21 24  6  0  0  0  0  0  0  0  0  2.7 ---
* MIX is 2% (2000000) del/put, 98% (12100654) get
DB size: 3.9G   /dev/shm/test-shf-19973.shf

Сравнение производительности с LMDB AKA Lightning MDB

Вот тот же тест, что и выше, но используя LMDB вместо ShareDhashfile:

Примечания:

Выясните, почему производительность сократилась вдвое, даже если код не изменился :-(
Чтобы сделать тест более яблоки с яблоками с хеш -таблицами:
mdb_get () & mdb_put () используются (вместо более быстрых функций курсора) для тестирования LMDB в качестве хэш -таблицы.
Файл LMDB DB хранится в /DEV /SHM, так что производительность диска не влияет на результаты.
Отказ от ответственности Put & Mix: LMDB разработан, чтобы быстро читать, а не писать.
Поместить выполняется с использованием транзакций LMDBS (читать: глобальная блокировка?)
Pro: Без транзакций, а затем поставьте только около 0,1 м в секунду, но все потоки присоединяются.
CON: С транзакциями, как правило, только один поток.
CON: Блокировка транзакций не кажется справедливой, и поэтому, хотя все процессы пытаются написать транзакцию, один поток имеет тенденцию всегда побеждать.
CON: Запись пут начинается с здорового 1,1 м в секунду, но медленно снижается до 0,2 м в секунду.
Смешайте только 50% процессора. Предположительно, из -за тяжелого глобального замка?
GET работает очень быстро на уровне 5.xm в секунду, но примерно вдвое меньше скорости ShareDhashFile.
LMDB использовал только 2,6 г против 3,9 г для Sharedhashfile.

 $ perl perf-test-lmdb.pl
...
perf testing: LMDB aka Lightning MDB
running tests on: via command: 'cat /proc/cpuinfo | egrep 'model name' | head -n 1'
running tests on: `model name   : Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz`
-OP MMAP REMAP SHRK PART TOTAL ------PERCENT OPERATIONS PER PROCESS PER SECOND -OPS
--- -k/s --k/s --/s --/s M-OPS 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 -M/s
PUT  0.0   0.0    0    0   0.0  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
PUT  0.0   0.0    0    0   1.1  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1.1 -
PUT  0.0   0.0    0    0   1.9  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.8 -
PUT  0.0   0.0    0    0   2.6  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.7
PUT  0.0   0.0    0    0   3.3  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.7
PUT  0.0   0.0    0    0   3.9  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.6
PUT  0.0   0.0    0    0   4.4  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.6
PUT  0.0   0.0    0    0   5.0  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.5
PUT  0.0   0.0    0    0   5.4  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.5
PUT  0.0   0.0    0    0   5.9  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.5
PUT  0.0   0.0    0    0   6.3  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.4
PUT  0.0   0.0    0    0   6.8  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.4
PUT  0.0   0.0    0    0   7.2  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.4
PUT  0.0   0.0    0    0   7.6  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.4
PUT  0.0   0.0    0    0   7.9  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.4
PUT  0.0   0.0    0    0   8.3  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.3
PUT  0.0   0.0    0    0   8.6  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.3
...
PUT  0.0   0.0    0    0  72.1  0  0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0.3
PUT  0.0   0.0    0    0  72.3  5  0 93  2  0  0  0  0  0  0  0  0  0  0  0  0  0.2
...
PUT  0.0   0.0    0    0 100.0100  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.2
MIX  0.0   0.0    0    0 100.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
MIX  0.0   0.0    0    0 100.3 13 12 12 13 13 12 12 13  0  0  0  0  0  0  0  0  0.3
MIX  0.0   0.0    0    0 101.3 12 12 12 13 12 12 13 13  0  0  0  0  0  0  0  0  1.0 -
MIX  0.0   0.0    0    0 102.3 13 12 13 13 12 13 12 12  0  0  0  0  0  0  0  0  1.0 -
...
MIX  0.0   0.0    0    0 198.3 13 13 12 13 13 12 12 12  0  0  0  0  0  0  0  0  1.0 -
MIX  0.0   0.0    0    0 199.4 12 12 12 12 13 13 13 13  0  0  0  0  0  0  0  0  1.1 -
MIX  0.0   0.0    0    0 200.0 13 27 10  3 17  8 11 11  0  0  0  0  0  0  0  0  0.6
GET  0.0   0.0    0    0 200.0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0.0
GET  0.0   0.0    0    0 203.0 13 13 12 13 11 13 12 13  0  0  0  0  0  0  0  0  3.0 ---
GET  0.0   0.0    0    0 208.1 13 12 13 13 12 13 11 13  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 213.4 12 11 14 12 13 13 13 11  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 218.6 13 11 14 12 13 12 13 12  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 223.8 13 11 13 13 13 13 12 12  0  0  0  0  0  0  0  0  5.3 -------
GET  0.0   0.0    0    0 229.2 12 12 12 13 14 14 12 12  0  0  0  0  0  0  0  0  5.4 -------
GET  0.0   0.0    0    0 234.3 12 13 12 12 11 13 13 13  0  0  0  0  0  0  0  0  5.1 ------
GET  0.0   0.0    0    0 239.6 11 12 14 12 12 13 14 12  0  0  0  0  0  0  0  0  5.3 -------
GET  0.0   0.0    0    0 244.9 12 12 14 10 13 13 14 13  0  0  0  0  0  0  0  0  5.3 -------
GET  0.0   0.0    0    0 250.1 11 11 13 13 13 13 14 13  0  0  0  0  0  0  0  0  5.3 -------
GET  0.0   0.0    0    0 255.3 13 12 12 12 13 12 13 12  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 260.5 13 12 11 13 12 14 13 11  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 265.8 13 12 12 11 13 13 14 11  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 270.8 14 12 12 12 13 13 13 12  0  0  0  0  0  0  0  0  5.1 ------
GET  0.0   0.0    0    0 275.9 12 14 13 13 13 12 14 10  0  0  0  0  0  0  0  0  5.1 ------
GET  0.0   0.0    0    0 281.3 12 14 13 12 12 13 14 10  0  0  0  0  0  0  0  0  5.4 -------
GET  0.0   0.0    0    0 286.4 14 13 12 13 12 13 13 12  0  0  0  0  0  0  0  0  5.2 ------
GET  0.0   0.0    0    0 291.7 13 12 11 11 13 13 13 13  0  0  0  0  0  0  0  0  5.3 -------
GET  0.0   0.0    0    0 296.7 12 13 12 13 13 14 11 13  0  0  0  0  0  0  0  0  5.0 ------
GET  0.0   0.0    0    0 300.0 12 22 11 19 10  0  0 25  0  0  0  0  0  0  0  0  3.2 ----
GET  0.0   0.0    0    0 300.0  0  0  0  0  0  0  0100  0  0  0  0  0  0  0  0  0.0
* MIX is 2% (2000000) del/put, 98% (12100654) get
DB size: 2.6G   /dev/shm/test-lmdb-20848

Тодо

Добавьте высокопроизводительный механизм уведомления об уведомлении об очереди МПК и на основе EventFD.
При использовании частного отсека очередей для производительности добавьте механизм восстановления удара элемента.
Добавьте тест на производительность для мультиплексного журнала и сравните с EG Log4CXX.
Позволить значениям больше, чем 4 КБ быть их собственным MMAP (); Так что IPC queue & log Addrs никогда не меняется.
Автомарт -дамп остается журнал общей памяти Atexit.
Расширить shf_log () на беспрепятственное войти в файл вместо stdout.
Преобразовать shf.log для работы с shf_log () вместо более медленного fopen ().
Добавьте документацию API через Doxygen для журнала.
Добавьте документацию API через Doxygen для операций с ключевой стоимостью.
Добавьте документацию API с помощью грамотного программирования.
Добавьте больше тестов и применяйте 100% покрытие кода.
Ключ поддержки, типы данных значения, кроме двоичных строк с длиной 32 бит.
Поддержка настойчивости в памяти прошлой перезагрузки.
Поддержите ходьбу всех ключевых паров в хэш -таблице.
Поддержка ключей стека, например, push, pop, shift, unshift.
Добавить сетевой слой для распределенной хэш -таблицы.
Добавить инструменты утилиты командной строки.
Убедитесь, что клиент может сбой в любое время без повреждения хэш -таблицы.
Порт к Linux-подобному OSS, который не поддерживает MREMAP ().
Порт в Windows.
Проверка тестирования на флэш -накопителях.
Отзыв по электронной почте [@] sharedhashfile [.] Com с большим количеством пожеланий!