How to reduce redis io usage

[Haluk AKIN]

Hello,

Our redis server can spike up its io usage from time to time. And when that happens we tend to have more connection problems to redis.

If possible I would like to try to reduce redis's io usage.
checking the conf file. The following configuration looks like it could help reduce io usage:
-CONFIG set save "900 1 300 50000 60 100000"
-"append only file" is already turned off.

How about other options?

For instance:
Would setting linux's overcommit_memory to 1 help reduce redis's io usage?

Thanks,
Haluk

[Dvir Volk]

do the IO spikes occur when redis is dumping to disk?

have you tried not persisting at all (CONFIG SET SAVE "")?

BTW is this an AWS instance?

--
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/-/ggd815PGsScJ.
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.

--

Dvir Volk

Chief Architect, Everything.me

http://everything.me 

[Haluk AKIN]

Dvir,

 

This is not AWS. It is a dedicated server.

 

I hadn’t thought of (config set save “”). I now pushed this configuration to production.

I’ll post an update probably tomorrow on how the results are. Maybe this could also reduce connection problems.

 

Thanks,

Haluk

[Josiah Carlson]

Note that when you disable saving, you have no persistence.

Regards,
- Josiah

[Dvir Volk]

Yeah, just to clarify: I offered it as a debugging/testing measure, not a solution.

sent from my Sinclair ZX48

[Haluk AKIN]

No problem here. I think it is a solid advice. We do not need persistence on this server. We have over 30GB of data, but it can totally rebuild itself from scratch in case of failure. So this could even be a production configuration for us.

 

So far we are definitely seeing significantly less io usage.

Tomorrow, I would like to try isolating redis to a new harddrive and observe a bit more before I share the results.

[Dvir Volk]

if you disable persistence, redis does not touch the hard drive at all, and all IO is just network.

[Greg Andrews]

Dvir, I haven't kept up-to-date on this particular behavior with versions after 2.2.x.  Does a Redis instance with persistence disabled still perform a AOF creation and write when a slave is attached and sends the SYNC command?

  -Greg

[Dvir Volk]

oh, I forgot about that one :) yeah, it's not AOF but RDB dump when a slave connects to it. for 30GB of data, even on a physical server this can cause the redis instance to halt a bit while we fork. but that's far more rare (hopefully!) than forking for BGSAVE or rewriting AOFs every few minutes.

[Matthew Palmer]

On Sun, Sep 30, 2012 at 04:29:50PM -0700, Greg Andrews wrote:
> Dvir, I haven't kept up-to-date on this particular behavior with versions
> after 2.2.x. Does a Redis instance with persistence disabled still perform
> a AOF creation and write when a slave is attached and sends the SYNC
> command?

It's an RDB, but yes, connecting a slave triggers an RDB creation on the
master, and that RDB will be copied to disk on the slave before being
loaded into memory.

http://redis.io/topics/replication

- Matt

[Greg Andrews]

Wow, the copy to disk on the slave side is a new one to me.  Maybe that's how recent versions prevent the slave from blocking all querys during the SYNC.

  -Greg

[Josiah Carlson]

Redis has been able to not block on requests during sync for quite a
while (maybe since 2.0). Somewhere around version 2.0 is also when
Redis got the option to serve stale data when sync had been lost (the
default in pre-2.0 versions), or to return an error (the new default).

And I am pretty sure that writing the incoming rdb to disk and being
able to serve requests prior to complete startup are independent and
unrelated. Redis should have always been writing incoming dumps to
disk, it's just that returning something during load was something
that would be useful to know (instead of blocking on startup).

Regards,
- Josiah

[Haluk AKIN]

Dvir;

 

This worked just fine. Once I set “save” configuration to nothing, io usage drops to zero.

 

 

Thank you,

Haluk

 

 

 

From: redi...@googlegroups.com [mailto:redi...@googlegroups.com] On Behalf Of Dvir Volk

Sent: Monday, October 01, 2012 1:03 AM

[Dvir Volk]

cool. if you want to avoid this AND keep some persistence, you might want to keep a slave process that does that but no one will ever talk to.

[M. Edward (Ed) Borasky]

On Wed, Oct 3, 2012 at 3:54 PM, Dvir Volk <dvi...@gmail.com> wrote:
> cool. if you want to avoid this AND keep some persistence, you might want to
> keep a slave process that does that but no one will ever talk to.

Ah, but then you have the network I/O to the slave, which might be a
bigger bottleneck than the disk I/O on the master. Your mileage may
vary, as the saying goes. ;-)

--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://j.mp/QCsXOr

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?