03:07:01 GMT <cwkatzmann> anyone in here?
07:04:28 GMT <Mattias> When redis gets full, even with volatile-ttl set as maxmemory-policy, redis refuses to clean out old entries for new ones. Magento 2 (which is using redis) just shows an error for redis when it gets full.
08:24:53 GMT <badboy_> Mattias: do you actually have volatile keys?
08:25:19 GMT <Mattias> badboy_: is that something the application sets? Not sure what magento 2 does really when is uses redis
08:25:50 GMT <Mattias> s/when is/when it
08:27:13 GMT <badboy_> show output of INFO please
08:27:20 GMT <Mattias> sure, sec
08:27:24 GMT <badboy_> volatile = keys with an expire
08:29:27 GMT <Mattias> badboy_: https://gist.github.com/mattias/30c7122d9456fd6590e778c2a750c928
08:32:22 GMT <Mattias> I think I tried volatile-lru or allkeys-lru but that kept removing sessions which only had been inactive for 1-5 min.
08:32:37 GMT <Mattias> redis is used for both cache and sessions in this case
08:33:11 GMT <badboy_> so you have some with an expire, that's giod
08:33:35 GMT <badboy_> it might be that it can't remove enogh/quickly enough
08:34:44 GMT <Pinchiukas> As I understand in AWS Elasticache I need to use separate endpoints for reading and writing. Is this the default way Redis clusters are set up?
08:36:19 GMT <Mattias> badboy_: For now we have doubled maxmemory, and I'll keep an eye on peak memory usage for a few days and see if it is stable. but volatile-ttl should still  help some? Or is there a better alternative? lru just doesn't work because it gets rid of sessions for some reason. Been thinking of trying to set up two redis instances, unless you can configure each database with separate maxmemory + policies.
08:38:44 GMT <badboy_> you can't
08:39:01 GMT <badboy_> if you have different requirements for your data you need to use two instances
08:39:04 GMT <badboy_> Pinchiukas: no
08:39:34 GMT <Pinchiukas> badboy_: "no" as in AWS made that up?
08:40:09 GMT <badboy_> I don't know AWS Elasticache, but I know Redis clusters^^
08:40:24 GMT <badboy_> Pinchiukas: can you point me to documentation about it requiring separate endpoints
08:41:04 GMT <Pinchiukas> badboy_: http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Endpoints.html?shortFooter=true
08:41:09 GMT <Pinchiukas> At least that's how I read it.
08:42:36 GMT <badboy_> where does it say that you _have_ to use separate endpoints?
08:43:06 GMT <badboy_> also are we talking Redis in Cluster mode or not in Cluster mode?
08:43:12 GMT <Pinchiukas> How else can you use it?
08:43:16 GMT <Pinchiukas> Cluster mode.
08:44:24 GMT <badboy_> > Redis (cluster mode enabled) clusters, use the cluster's Configuration Endpoint for all operations.
08:45:11 GMT <badboy_> (though you need a client that can handle Redis Cluster, it will follow the redirects)
08:45:12 GMT <Pinchiukas> I must be stupid.
08:45:36 GMT <Pinchiukas> Yeah I was actually thinking of using the Redis cluster as a memcache server.
08:52:43 GMT <Pinchiukas> Guess I'll have to use their memcached offering...
08:56:34 GMT <badboy_> if you need memcached, you should use memcached, yes
08:58:31 GMT <Pinchiukas> I was hoping to use Redis' replication and data retention features.
08:58:52 GMT <badboy_> but Redis != Memcached
09:00:30 GMT <Pinchiukas> It does support the memcached protocol though?
09:12:34 GMT <Pinchiukas> badboy_: but I'd fail if I use a *cluster* of Redis nodes because it redirects to different shards?
09:12:58 GMT <badboy_> it does not support the memcached protocol
09:16:12 GMT <Pinchiukas> I've been mislead it appears. :)
09:17:16 GMT <badboy_> yes
09:49:12 GMT <p1rate> how do I run a script without defining keys?
09:49:22 GMT <p1rate> my script: return redis.call('del', unpack(redis.call('keys', ARGV[1])))
09:49:34 GMT <p1rate> it deletes all keys with matching pattern
09:50:33 GMT <p1rate> I call it as: eval "<script>" 1 "p:200:*"
09:50:44 GMT <p1rate> but I get "ERR wrong number of arguments for 'eval' command"
09:50:49 GMT <p1rate> anyone can explain why?
10:01:28 GMT <badboy_> because you're passing p:200:* into KEYS, not ARGV?
10:01:45 GMT <badboy_> EVAL "<script>" 0 p:200:*
11:21:46 GMT <Pinchiukas> Wait so did I imagine the fact that memcache clients can connect to Redis?
11:23:07 GMT <Habbie> i'd say you did
11:23:10 GMT <Habbie> maybe some wrapper?
11:24:00 GMT <Pinchiukas> I must be losing my mind. :)
11:25:56 GMT <Habbie> redis labs does sell 'buckets' with memcached access
12:39:35 GMT <badboy_> I think the inline protocol is similar
12:39:45 GMT <badboy_> things like "GET a" should work for both, redis and memcache
12:39:49 GMT <badboy_> but that's about it
12:44:27 GMT <Pinchiukas> Does memcached need anything more then get/get? :)
12:44:50 GMT <Pinchiukas> Err get/set.
12:54:20 GMT <badboy_> add, cas, ...
12:54:26 GMT <badboy_> but even the SET command is not compatible ;)
14:33:16 GMT <p1rate> badboy_, late reply but what should I pass to KEYS if I don't have those?
14:33:37 GMT <badboy_> nothing?
14:33:44 GMT <p1rate> so how to pass nothing? :)
14:34:25 GMT <p1rate> mm, "" seems to work
14:34:40 GMT <p1rate> EVAL "script" 1 "" "p:200:*"
14:34:47 GMT <p1rate> thought I tried that already
14:34:49 GMT <badboy_> 0
14:34:59 GMT <badboy_> nothing = zero keys
14:35:08 GMT <p1rate> 0 doesn't work, only "" does
14:35:29 GMT <badboy_> 127.0.0.1:6379> eval "return ARGV[1]" 0 foobar
14:35:29 GMT <badboy_> "foobar"
14:35:33 GMT <badboy_> works for me
14:36:00 GMT <p1rate> weird, it doesn't for me
14:36:05 GMT <badboy_> which version of redis?
14:36:09 GMT <p1rate> at least not with my script
14:36:26 GMT <p1rate> redis_version:2.8.24
14:36:28 GMT <badboy_> through redis-cli?
14:36:31 GMT <badboy_> oh, upgrade ;)
14:36:48 GMT <p1rate> I thought it was on 3.2... I guess staging wasn't upgraded then
14:36:57 GMT <badboy_> (might have been fixed since then? I don't know)
14:37:02 GMT <p1rate> I guess
14:37:05 GMT <p1rate> thanks anyway :)
19:04:03 GMT <dudeji> "The command port and cluster bus port offset is fixed and is always 10000." is it 10000 always or adding 10000 to client port like : 7000 is my client port then 17000 is my cluster bus port
19:06:35 GMT <minus> the offset is fix, so 17000, yes