11:41:32 GMT <Abhijeet> HI
14:14:19 GMT <arthurl> hi guys- i'm seeing a 'Can't save in background: fork: Cannot allocate memory' error on a production redis instance
14:14:24 GMT <arthurl> but the box appears to have plenty of memory
14:15:02 GMT <arthurl> this is what the memory looks like- it's a 32gb server
14:15:03 GMT <arthurl> https://gist.github.com/alyssenko/219cd57d5869ea8d8cdcd3a5572f63e9
14:37:32 GMT <minus> arthurl: overcommit might be turned off
14:38:41 GMT <minus> Assuming you have less than 50% ram free that might be the cause
14:40:22 GMT <arthurl> minus so now i'm worried i did something bad- i tried to stop the service and i see it did a 'Saving the final RDB snapshot before exiting.'
14:41:28 GMT <minus> Seems to be fine?
14:45:33 GMT <arthurl> minus well i was expecting to see output that indcates successful save/dump to the rdb file
14:46:16 GMT <arthurl> but maybe redis output has changed in recent versions- and the status just seemed to be stuck on stop 'stop/waiting'
14:46:38 GMT <arthurl> but then i just issued a 'start' command and it came back up
15:51:21 GMT <arthurl> i see this article states 'Make sure to setup some swap in your system'- but it seems that redis vm is now depreciated? https://redis.io/topics/admin
15:51:30 GMT <arthurl> based on what i see in https://redis.io/topics/virtual-memory
15:56:09 GMT <arthurl> minus so now that vm is depreciated is setting overcommit to on more dangerous?
17:17:11 GMT <GNU\colossus> hi
17:17:32 GMT <GNU\colossus> has anyone yet publicly/officially considered implementing systemd Notify support for redis?
17:55:51 GMT <minus> arthurl: virtual memory is an old, deprecated feature. have you read this? https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram
18:01:16 GMT <arthurl> thanks minus i did read that actually- i guess it's not clear to me still as to how dangerous setting this value to 1 can be
18:02:03 GMT <arthurl> i realize why it was failing for me now- its because overcommit was set to 0 and our current working set in memory was slightly larger than what we had available in memory and since it's forking it needs at least the same amount free as what's currently being used- so that much makes sense to me
18:44:02 GMT <badboy_> GNU\colossus: there is support for it in Redis
18:44:28 GMT <badboy_> GNU\colossus: https://github.com/antirez/redis/blob/unstable/redis.conf#L138-L147
18:47:52 GMT <GNU\colossus> badboy_, ah, neat! :)
18:48:05 GMT <GNU\colossus> *wipes branch*
18:48:43 GMT <GNU\colossus> I just noticed that redis bugs me about transparent hugepage support even though my running kernel has it configured for "madvise" only; is that intentional?
18:49:12 GMT <GNU\colossus> (I doubt redis would madvise() to use hugepages for its allocations when it's considered bad for performance...)
18:49:18 GMT <badboy_> yes and no
18:49:26 GMT <badboy_> redis only does a bare detection checking if it is on
18:49:57 GMT <badboy_> https://github.com/antirez/redis/issues/3895
18:50:06 GMT <badboy_> (did I submit that as a PR?)
18:52:08 GMT <badboy_> now i did
18:52:57 GMT <GNU\colossus> :) awesome
18:53:04 GMT <GNU\colossus> *wipes another branch*
18:53:18 GMT <badboy_> :D
18:53:22 GMT <badboy_> I leave the rest to you ;)
19:13:48 GMT <popsch> I would like a redis node to be a slave of multiple redis servers (e.g., slaveof A and then slaveof B)
19:14:14 GMT <popsch> I want to use that method to aggregate data from different redis instances on a single machine. is that possible?
19:19:54 GMT <minus> no
19:28:25 GMT <GNU\colossus> badboy_, the supervision support arrived with Redis 3.2, is that correct?
19:28:53 GMT <badboy_> puh, don't know of the top of my head
19:28:58 GMT <badboy_> should be in the release notes though
19:29:12 GMT <GNU\colossus> I think I found it in the 3.2 changelog
19:42:54 GMT <GNU\colossus> I'm looking for non-evasive ways to figure out how the individual databases in a redis server contribute to its resource consumption (allocation size and IOPS) - is there a tool that can help me do that, or will I have to get creative?
19:43:02 GMT <GNU\colossus> (still dealing with Redis 2.8 in this case)
19:56:38 GMT <popsch> is there a way to have redis bind to all available network interfaces? in redis.conf, bind at the moment needs a specific IP listed, but with DHCP, this IP might change. A wildcard like 192.168.* doesn't seem to work.
20:02:39 GMT <aphistic> hey all! I'm using a sorted set to keep track of things in history and i'd like to keep a nanosecond timestamp as the score (zadd testkey 1494876546384534904 1234) but when i try to get the score back with zrevrangebyscore it's giving me the score back in scientific notation ("1.4948765463845348e+18"). Is there a way I can change this so it returns the original value or is it a limitation of redis and I ne
20:02:45 GMT <aphistic> ed to reduce the length of the number i'm storing?
20:03:27 GMT <minus> popsch: bind to 0.0.0.0 probably
20:04:41 GMT <minus> aphistic: scores are stored as double precision floating point numbers and have a maximum integer-precision of 53 bits
20:05:37 GMT <aphistic> minus: ahh, ok. thanks!
21:00:38 GMT <GNU\colossus> can I get redis' build system to alter all artifact/binary names for me? (I'd like to have a version-specific suffix on executables et al., like with automake's "--program-suffix=" option)
21:09:17 GMT <badboy_> GNU\colossus: no
21:09:29 GMT <badboy_> Redis uses a plain makefile, you could edit the variables
21:09:35 GMT <badboy_> or simply mv the files afterwards
21:10:58 GMT <GNU\colossus> I was afraid you'd say that :) will have to work something out that makes this possible with Debian's packaging
21:17:52 GMT <badboy_> why do you need that if I may ask?
21:23:10 GMT <GNU\colossus> badboy_, well, I'm planning a rather complex restructuring of our redis deployments (4 master instances, ~20 slaves, with 20 databases in total in the masters, with the initial setup dating back to at least Redis 2.4)
21:24:04 GMT <GNU\colossus> since we have several an outdated Debian release still in use, we roll our own packages for redis, since the replication isn't expected to work between the version available in Debian itself
21:24:27 GMT <GNU\colossus> now, I'd also like to be able to operate Redis in at least two versions in parallel during the migration phase
21:24:50 GMT <GNU\colossus> we have 2.8 right now and will need to support that version for a number of days while making the switch to (I hope) 4.0
21:25:40 GMT <badboy_> you should be able to change the destination dir if that helps
21:26:19 GMT <GNU\colossus> yeah I've seen support for that in the Makefile. I'll consider that as another resort :)
21:26:31 GMT <GNU\colossus> I'm not in a rush
23:13:58 GMT <popsch> minus, bind 0.0.0.0 works. thanks a lot