<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
30
00:02 wlightning-fuel joined
00:03 jon-mac joined
00:05 soveran joined
00:16 EyePulp joined
00:30 hahuang61 joined
00:41 cyborg-one joined
00:43 jgt2 joined
00:49 jon-mac joined
01:03 EyePulp joined
01:30 hndk joined
01:32 steeze joined
01:43 EyePulp joined
01:46 edvorg joined
01:49 ogres joined
01:58 wlightning-fuel joined
02:08 EyePulp joined
02:09 soveran joined
02:18 svm_invictvs joined
02:22 enigma_raz joined
02:25 chipotle joined
02:31 hahuang61 joined
03:04 sanyo joined
03:18 sanyo joined
03:23 iamchrisf joined
03:25 steeze joined
03:50 EyePulp joined
04:00 fakenerd joined
04:04 jgt2 joined
04:06 svm_invictvs joined
04:20 rchavik joined
04:31 SkyRocknRoll joined
04:32 hahuang61 joined
04:38 EyePulp joined
04:41 RemiFedora joined
04:46 enigma_raz joined
04:49 vchav joined
04:51 al-damiri joined
04:58 enigma_raz joined
05:05 fakenerd joined
05:11 soveran joined
05:25 xiaomiao joined
05:25 xiaomiao joined
05:36 xco joined
05:44 enigma_raz joined
05:47 rchavik joined
06:05 hos7ein joined
06:08 jgt2 joined
06:14 soveran joined
06:14 soveran joined
06:29 MrXXIV joined
06:33 hahuang61 joined
06:41 bannakaffalatta joined
06:49 Dave_R joined
07:02 rendar joined
07:08 enigma_raz joined
07:16 HelgeO joined
07:31 |cub| joined
07:31 <|cub|> hey there)
07:31 <|cub|> one quick teoretical question: 1 client = 1 connection from client to corresponding port on server?
07:38 JohnnyRun joined
07:50 <fanfan> |cub|: should be
07:51 <fanfan> \wi soveran
07:52 <|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 <fanfan> |cub|: if your application opens a new session for each query but does not close connections.
07:54 <|cub|> that was second thought after checking maxclients. Application closes connection
07:57 ren0v0 joined
08:00 <minus> |cub|: the actual limit might be lower than the maxclients setting if the fd ulimit is too low
08:12 mikecmpbll joined
08:16 EyePulp joined
08:17 Dave_R joined
08:23 rchavik joined
08:31 SkyRocknRoll joined
08:34 hahuang61 joined
08:37 EyePulp joined
08:39 Mr__Anderson joined
08:41 rchavik joined
08:47 <|cub|> yep, problem was in ulimits
08:47 <|cub|> thanks. have a good day
08:47 |cub| left
08:50 programmingcool joined
08:53 dblessin_ joined
09:00 Majiir joined
09:03 brodolfo joined
09:06 JohnnyRun joined
09:14 raspado joined
09:25 sppadic joined
09:25 sppadic left
09:25 sppadic joined
09:33 <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:33 enigma_raz joined
09:49 <mstaack> how many clients do you have?
09:49 <mstaack> maybe you are reaching the network limit?
10:05 fxn joined
10:06 <fxn> are different pub/sub channels in Redis dispatched to subscribers concurrently?
10:07 <Habbie> define 'concurrently'
10:09 <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 <Habbie> no
10:10 <fxn> why :)
10:10 <Habbie> because redis is single threaded
10:10 <Habbie> so it will issue the messages to you at the exact same rate as if they were in one channel
10:10 <fxn> well, internally I have heard it is not, its public interface for commands is because the interface and semantics are serial
10:11 <Habbie> what is not?
10:11 <fxn> for example, persistence is done in a different thread I believe
10:11 <Habbie> well yes
10:11 tavish joined
10:11 <Habbie> but that's besides the point here
10:11 <fxn> so, since multiplexing pub/sub does not seem to violate semantics, I was sondering
10:11 <fxn> *wondering
10:12 <Habbie> it would be possible to write a redis-clone with the same semantics, but multithreaded internally
10:12 <Habbie> but redis itself does not do it
10:12 <fxn> if I push to channel A, and then to channel B, that is serial, but subscribers have no ordering guarantee
10:12 <Habbie> yes
10:12 <fxn> Habbie: gotcha, thanks!
10:12 <Habbie> np!
10:20 <minus> fbred: that's extremely slow unless you're going over the internet, maybe give redis-benchmark a shot
10:20 raspado joined
10:21 raspado joined
10:34 hahuang61 joined
10:36 efphe joined
10:39 Guest96 joined
11:07 soveran joined
11:07 soveran joined
11:26 dh1tw joined
11:27 jgt2 joined
11:32 fakenerd joined
11:37 tavish joined
11:54 <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:03 drbobbeaty joined
12:08 winem_ joined
12:10 <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 <winem_> and without sentinel
12:12 <mstaack> you could do client site replication
12:12 <mstaack> like always sending 3 time the data :D
12:14 <minus> winem_: not with redis' builtin replication mechanism
12:15 sz0 joined
12:24 pid1 joined
12:33 soosfarm joined
12:36 hahuang61 joined
12:44 EyePulp joined
12:57 daxelrod joined
13:01 daxelrod1 joined
13:18 EyePulp joined
13:33 <winem_> sorry, forgot the irc..
13:33 <winem_> mstaack: thanks, that's what I got from the documentation, too
13:33 <winem_> minus: is there any 3rd-party solution to achieve a multimastersetup?
13:34 <mstaack> i meant using something like predis
13:34 <mstaack> from php
13:34 <mstaack> but this feels kinda hacky imho
13:35 <minus> winem_: not that i know of
13:36 <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 <winem_> ok, then we'll go for a cluster. thanks guys :)
13:37 <minus> i'm inferring that your read load is too much for a single instance?
13:37 <minus> though then master/slave would work fine
13:40 dh1tw joined
13:42 <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 <winem_> and, tbh, we tried to find a way to avoid to support redis clustering for now
13:44 <minus> mutlimaster wouldn't even solve the write load in the first place (though alleviate the read load)
13:44 <minus> yeah, sounds like you don't really have a choice other than cluster
13:45 <minus> manual sharding maybe
13:47 <winem_> then we would have to tweak the keys.. will evaluate that :)
13:55 bannakaffalatta joined
14:00 FeersumEndjinn joined
14:09 bannakaffalatta joined
14:10 dh1tw joined
14:10 hos7ein joined
14:15 jgt2 joined
14:19 bannakaf_ joined
14:19 shinnya joined
14:22 freddie_ joined
14:22 raspado joined
14:25 bannakaffalatta joined
14:25 freddo joined
14:25 ArchDebian joined
14:26 daxelrod joined
14:26 ArchDebian joined
14:31 cyborg-one joined
14:35 edrocks joined
14:37 hahuang61 joined
14:45 Guest96 joined
15:04 FunnyLookinHat joined
15:13 al-damiri joined
15:15 Mr__Anderson joined
15:15 iamchrisf joined
15:20 ogres joined
15:21 SkyRocknRoll joined
15:21 fakenerd joined
15:25 steeze joined
15:27 fxn left
15:28 fxn joined
15:28 xiaomiao joined
15:30 <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 <fxn> the only thing that seems parallelizable is the broadcasting of one single message
15:33 Dave_R joined
15:34 <fxn> but the code at first sight seems serial https://github.com/antirez/redis/blob/unstable/src/pubsub.c#L225
15:39 enigma_raz joined
15:42 enigma_raz joined
15:47 enigma_r_ joined
15:51 bannakaffalatta joined
15:55 iamchrisf joined
16:04 <Habbie> fxn, ah
16:04 <Habbie> fxn, yes the code is serial by definition, everything in redis is (except persistence)
16:11 tavish joined
16:12 wlightning-fuel joined
16:12 svm_invictvs joined
16:18 svm_invictvs joined
16:24 iamchrisf joined
16:30 enigma_raz joined
16:31 __alex joined
16:34 raspado joined
16:34 fakenerd_ joined
16:38 hahuang61 joined
16:45 enigma_raz joined
16:48 enigma_r_ joined
16:56 enigma_raz joined
17:02 svm_invictvs joined
17:06 hos7ein joined
17:08 Fiber^ joined
17:10 pid1 joined
17:10 cyborg-one joined
17:14 jgt2 joined
17:15 edrocks joined
17:29 mikecmpbll joined
17:35 cliluw joined
17:37 jgt2 joined
17:37 forgotmynick joined
17:45 bannakaffalatta joined
17:46 hahuang61 joined
17:49 Orion3k joined
18:21 cliluw joined
18:22 olalonde joined
18:59 xiaomiao joined
19:04 timg__ joined
19:06 Specialist joined
19:08 minimalism joined
19:15 Specialist joined
19:17 dh1tw joined
19:27 iamchrisf joined
19:33 Specialist_ joined
19:35 rendar joined
19:39 chipotle joined
19:49 Guest96_ joined
19:52 efphe joined
19:54 enigma_raz joined
19:56 enigma_r_ joined
20:51 GreenJello joined
20:51 wlightning-fuel joined
20:57 hive-mind joined
21:01 svm_invictvs joined
21:05 dh1tw joined
21:27 iamchrisf joined
21:28 timg__ joined
21:37 Mr__Anderson joined
21:45 soveran joined
21:45 soveran joined
22:15 edrocks joined
22:16 mikecmpbll joined
22:51 bannakaffalatta joined
22:54 soveran joined
22:54 soveran joined
23:07 Majiir joined
23:17 minimalism joined
23:26 Guest96 joined
23:53 bannakaffalatta joined