memory leak in hmget?

[iammutex]

It seems that the "hmget" cmd have some kind of memory leak problem?

examle:

1.set 10000 fields to one hash key
for($i=0; $i<10000; $i++) redis->hset('test', $i, $i);

2.then I use hmget to get all the fields
for($i=0; $i<10000; $i++)$fs[] = $i;
$redis->hmget('test', $fs);

After that, use "info" cmd you can see that the used memory rised.

Every time you exec the "hmget" cmd like this, the used memory rised
for some kbytes, and seems never goes down.

On the other hand, if I use the "hgetall" cmd, then everything workes
fine.

[iammutex]

BTW, I tested on the latest stable version.

[Didier Spezia]

Confirmed.
I can reproduced this with Redis 2.4.10 with a simple client

Regards,

Didier.

[Arek Bochinski]

Pastebin of info command output: http://pastebin.com/TEJST2We

I couldn't reproduce it using redis-cli and vanilla stable server.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/1elf6jEyEVcJ.

To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[iammutex]

yes, I also cant reproduce it while hmget fields number was to small,
for example less than 10000.

So I think using the redis-cli is not a right method for that.

[Sripathi Krishnan]

I was able to reproduce this as well on unstable.

1. Only reproducible for integer values. 
2. NOT reproducible for string values
3. NOT reproducible on 2.48 branch

--Sri

[Salvatore Sanfilippo]

Hello, thank you for the report. Investigating...

Salvatore

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele

[Salvatore Sanfilippo]

There is no leak, but the slow log accumulates all this arguments... I
just tried but would be cool to get an ACK form the iammutext.

Of course it's fixed in size, but still maybe it makes sense to limit
the slow log to first N arguments and log N+1 as "...".

Makes sense?

Cheers,
Salvatore

[Salvatore Sanfilippo]

On Sun, Apr 1, 2012 at 9:51 PM, Salvatore Sanfilippo <ant...@gmail.com> wrote:

> just tried but would be cool to get an ACK form the iammutext.

Sorry I mean "from iammutext", I was writing "from the original
poster", changed the form but forgot to remove "the".

Salvatore

[Didier Spezia]

Good catch.

I have increased the "slowlog-log-slower-than" parameter and I cannot reproduce anymore from my Python script.

I have not thought about the slowlog ...

Regards,

Didier.

[Salvatore Sanfilippo]

Thanks for the acknowledge Didier, worth fixing limiting to N
arguments. However the "problem" still remains for large strings, so
I'll fix that as well limiting to up to N bytes while I'm at it.

Cheers,
Salvatore

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/redis-db/-/O7YSr8IXEOYJ.

[iammutex]

thx for Didier and Salvatore, I got it. I've never think about the
slow log. very interesting!

BTW. It's iammutex :)