Redis + phpredis теряют ключи — переполнение памяти?

Новичок в Redis, тестирование его с php на небольшом устройстве с оперативной памятью всего 512 МБ с использованием клиента phpredis.

В набор вставлено 3 млн целочисленных значений. Но метод sCard() для этого набора возвращает только около 270 тыс. счетчиков.

Это предел памяти, с которым я столкнулся? Как проверить ошибки при вставке?

Приложение: есть два двоичных файла, в которых хранятся последовательности четырехбайтовых целых чисел без знака, которые я хочу загрузить в Redis для быстрого сравнения в памяти. Вот мой метод вставки (пропущены строки проверки ошибок):

function loadToRedis( $id, $filename){
    $length = filesize( $filename) / 4; // how many ids are there? Each is 4 bytes.
    $divisor = 100; // how many ids to insert in a single batch

    printf( "Length of %s: %d 4-byte numbers\n", $filename, $length);
    $FP = fopen($filename, 'r');
    for( $b=0; $b<=floor( $length/ $divisor); $b++){
        $set = array( $id);
        for( $i=$b*$divisor; $i < min(( $b+1)*$divisor, $length); $i++) {
            $bytes = unpack( "L", fread( $FP, 4));
            array_push( $set, array_shift( $bytes));
        }

        call_user_func_array( array( $this->redis, 'sAdd'), $set);
    }
    fclose($FP);
    printf( "%d items in the list named %s\n", $this->redis->sCard( $id), $id);
}

Итак, после чтения первого из двух файлов с 3m-значениями размер первого набора составляет всего около 270 КБ, а во втором файле Redis полностью отсутствует:

Length of /var/www/.../dat/OLD_26750264: 3123758 4-byte numbers
270457 items in the list named OLD_26750264
Length of /var/www/.../dat/NEW_26750264: 3125000 4-byte numbers
0 items in the list named NEW_26750264

Вывод Redis INFO сразу после этого:

redis_version:2.4.10
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.6
process_id:8416
uptime_in_seconds:1471232
uptime_in_days:17
lru_clock:1618016
used_cpu_sys:387.21
used_cpu_user:414.13
used_cpu_sys_children:0.03
used_cpu_user_children:0.32
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:19997864
used_memory_human:19.07M
used_memory_rss:22544384
used_memory_peak:27022288
used_memory_peak_human:25.77M
mem_fragmentation_ratio:1.13
mem_allocator:jemalloc-2.2.5
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1379328354
bgrewriteaof_in_progress:0
total_connections_received:153
total_commands_processed:16073
expired_keys:0
evicted_keys:0
keyspace_hits:99
keyspace_misses:83
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:835
vm_enabled:0
role:master
db0:keys=2,expires=0

person Serge    schedule 16.09.2013    source источник
comment
попробуйте также запустить монитор во время ваших действий   -  person Itay Moav -Malimovka    schedule 16.09.2013
comment
@ ItayMoav-Malimovka, монитор показывает только два SCARD, без SADD: redis 127.0.0.1:6379> MONITOR OK 1379329526.917235 "MONITOR" 1379329541.819809 "SCARD" "OLD_26750264" 1379329549.606102 "SCARD" "NEW_26750264"   -  person Serge    schedule 16.09.2013
comment
Повторный тот же тест с пропуском чтения чисел из файлов: простой цикл с вставкой увеличивающегося значения. Тот же лимит 270500. На этот раз МОНИТОР отображает каждый SADD, то есть: 1379330597.646626 "SADD" "test" "2657601" "2657602" ... "2657698" "2657699" "2657700" И записи, пойманные МОНИТОРОМ, заканчиваются на ~270000, за которыми следует SCARD.   -  person Serge    schedule 16.09.2013
comment
Я понял: максимальная память была достигнута намного быстрее, чем я мог ожидать. В дальнейших тестах с maxmemory=40mb в набор могло поместиться только 1048600 целочисленных значений. В среднем это 44,62 байта на целое число. Не очень эффективно.   -  person Serge    schedule 16.09.2013


Ответы (1)


Я понял: maxmemory было достигнуто намного быстрее, чем я мог ожидать. В дальнейших тестах с maxmemory = 40mb в набор могло поместиться только 1048600 целочисленных значений. В среднем это 44,62 байта на целое число. Не очень эффективно.

person Serge    schedule 16.09.2013