07:31:15 GMT <|cub|> hey there)
07:31:57 GMT <|cub|> one quick teoretical question: 1 client = 1 connection from client to corresponding port on server?
07:50:50 GMT <fanfan> |cub|: should be
07:51:22 GMT <fanfan> \wi soveran
07:52:41 GMT <|cub|> than what can cause problem, when "maxclients 20000" and im getting "ERR max number of clients reached" when there is something about 1000 connections?
07:53:38 GMT <fanfan> |cub|: if your application opens a new session for each query but does not close connections.
07:54:36 GMT <|cub|> that was second thought after checking maxclients. Application closes connection
08:00:56 GMT <minus> |cub|: the actual limit might be lower than the maxclients setting if the fd ulimit is too low
08:47:35 GMT <|cub|> yep, problem was in ulimits
08:47:43 GMT <|cub|> thanks. have a good day
09:33:07 GMT <fbred> Hello! My redis instance is very slow (average 9 ms pr query). It doesn't look like it's out of cpu (constant 43.9 cpu %). I have another redis instance on the same server that is much faster. The slow commands are AUTH and GET's for simple keys. The server load is low (1.61 on a 8 core system). What more can I check? I have gone through the latency guide..
09:49:30 GMT <mstaack> how many clients do you have?
09:49:47 GMT <mstaack> maybe you are reaching the network limit?
10:06:53 GMT <fxn> are different pub/sub channels in Redis dispatched to subscribers concurrently?
10:07:20 GMT <Habbie> define 'concurrently'
10:09:53 GMT <fxn> I have a busy stream of events, would splitting the channel in several, c.001, c.002, c.003, ..., c.100, and then listening to c.* in a Go program be more efficient than doing all in one single channel be more efficient that publishing to one single channel?
10:10:01 GMT <Habbie> no
10:10:13 GMT <fxn> why :)
10:10:18 GMT <Habbie> because redis is single threaded
10:10:32 GMT <Habbie> so it will issue the messages to you at the exact same rate as if they were in one channel
10:10:55 GMT <fxn> well, internally I have heard it is not, its public interface for commands is because the interface and semantics are serial
10:11:09 GMT <Habbie> what is not?
10:11:10 GMT <fxn> for example, persistence is done in a different thread I believe
10:11:13 GMT <Habbie> well yes
10:11:27 GMT <Habbie> but that's besides the point here
10:11:35 GMT <fxn> so, since multiplexing pub/sub does not seem to violate semantics, I was sondering
10:11:48 GMT <fxn> *wondering
10:12:12 GMT <Habbie> it would be possible to write a redis-clone with the same semantics, but multithreaded internally
10:12:20 GMT <Habbie> but redis itself does not do it
10:12:31 GMT <fxn> if I push to channel A, and then to channel B, that is serial, but subscribers have no ordering guarantee
10:12:41 GMT <Habbie> yes
10:12:42 GMT <fxn> Habbie: gotcha, thanks!
10:12:46 GMT <Habbie> np!
10:20:06 GMT <minus> fbred: that's extremely slow unless you're going over the internet, maybe give redis-benchmark a shot
11:54:03 GMT <fbred> mstaack, minus, sorry, was caught in a meeting. I have about 7500 clients and 30-50k ops/s. I'm not running on the internet. It's just that redis suddenly gets very slow, and I can't really see that the CPU usage is corresponding
12:10:10 GMT <winem_> hi. is it possible to have a multi master setup where all master nodes have the same set of data and each node accepts write queries? basically, a cluster without sharding?
12:12:05 GMT <winem_> and without sentinel
12:12:11 GMT <mstaack> you could do client site replication
12:12:18 GMT <mstaack> like always sending 3 time the data :D
12:14:10 GMT <minus> winem_: not with redis' builtin replication mechanism
13:33:30 GMT <winem_> sorry, forgot the irc..
13:33:40 GMT <winem_> mstaack: thanks, that's what I got from the documentation, too
13:33:57 GMT <winem_> minus: is there any 3rd-party solution to achieve a multimastersetup?
13:34:03 GMT <mstaack> i meant using something like predis
13:34:12 GMT <mstaack> from php
13:34:22 GMT <mstaack> but this feels kinda hacky imho
13:35:03 GMT <minus> winem_: not that i know of
13:36:06 GMT <winem_> client site replication is not an option. this would create too much overhead. and we would have to write our own client for haskell to do the job anyway
13:36:22 GMT <winem_> ok, then we'll go for a cluster. thanks guys :)
13:37:02 GMT <minus> i'm inferring that your read load is too much for a single instance?
13:37:11 GMT <minus> though then master/slave would work fine
13:42:12 GMT <winem_> it's a combination of read and write load and a platform that scales itself (spawns new vms, terminates them, etc...) and is shared over different DCs
13:43:19 GMT <winem_> and, tbh, we tried to find a way to avoid to support redis clustering for now
13:44:24 GMT <minus> mutlimaster wouldn't even solve the write load in the first place (though alleviate the read load)
13:44:41 GMT <minus> yeah, sounds like you don't really have a choice other than cluster
13:45:04 GMT <minus> manual sharding maybe
13:47:21 GMT <winem_> then we would have to tweak the keys.. will evaluate that :)
15:30:30 GMT <fxn> Habbie: actually, I think it is just not possible with the current semantics, because the return value of the first PUBLISH is the number of subscribers that got the message, therefore all is broadcasted before the second PUBLISH can be even issued, no way yo can parallelize those
15:31:12 GMT <fxn> the only thing that seems parallelizable is the broadcasting of one single message
15:34:33 GMT <fxn> but the code at first sight seems serial https://github.com/antirez/redis/blob/unstable/src/pubsub.c#L225
16:04:33 GMT <Habbie> fxn, ah
16:04:43 GMT <Habbie> fxn, yes the code is serial by definition, everything in redis is (except persistence)