32 vs 64 bits. Help configuring a BIG server.
JammyZ
my server is running a 64 bits Linux OS. It has 16 cores and 128 GB of RAM.
I am going to make use of sharded redis, so I will have multiple redis instances running on the server.
I know 64 bits version of Redis uses more memory to store the same amount of information. How much more?
In this scenario, if I use 32 bits Redis, I can only use 3 GB of RAM per instance, if I wanted to make use of all the RAM I would need around 40 instances of Redis (allowing for 8 GB of RAM for the OS and backups). It doesn't seem to make too much sense, since I "only" have 16 cores and I've read that I should leave some spare CPUs for better performance (I/O and other processes). I'm afraid I'll have a lot of context switches with this setup.
So I thought that in this case maybe it made sense to setup around 12 64 bits Redis instances and use around 9 GB of RAM on each, leaving spare RAM for snapshots and other tasks.
From what I've seen in the mailing list I know it is not a common setup, but I think in this case a 32 bits version of Redis is not the best fit. I am also concerned about the stability of the 64 bits version vs the 32 bits one, since it is more tested.
I'm planning on using Redis 2.2
Cheers,
Iker.
Josiah Carlson
8 months without any issues with either. How much more memory 64 bit
Redis uses will depend on your data.
If you've got the machine actually running, you may want to run a 32
bit and a 64 bit instance, put the same amount of data in each, and
see what the differences are to determine whether you want better
efficiency, or fewer processes.
Regards,
- Josiah
> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> 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.
>
Salvatore Sanfilippo
today is national holiday in Italy so I was around not able to reply
to emails, and many other times I'm not able to reply to every email
here since I try to push forward Redis codebase.
But I want to say thank you to all the people that not only developed
a deep Redis expertise but also share this information to the
community. It is very hard to see an unanswered question in this
Google Group.
So thank you for your help! A software is just a piece of technology
with benefits, tradeoffs, and problems. What can make the real
difference is the human factor and a great community.
Grazie,
Salvatore
--
Salvatore 'antirez' Sanfilippo
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
Aníbal Rojas
I experimented with 64 bit Redis memory instance in a Quadruple Extra
Memory box in the EC2 and, in the end I would have been more
comfortable with a set of instances regarding disk IO.
--
Aníbal Rojas - @anibalrojas
Ruby / Rails focused Devops
More info: http://www.google.com/profiles/anibalrojas
My free/busy schedule: http://tungle.me/anibal
Salvatore Sanfilippo
> I think that you should also consider the persistence in the equation.
>
> I experimented with 64 bit Redis memory instance in a Quadruple Extra
> Memory box in the EC2 and, in the end I would have been more
> comfortable with a set of instances regarding disk IO.
Good point, and from this point of view I think that what makes a lot
of sense is to have a "persistent" manager, that is, a trivial script
issuing BGSAVE so that of N instances running in a single box just one
is saving at any given time.
So if you have 10 instances in a box, even in the most write-heavy
conditions that will use 100% more ram for copy on write, a single
instance is saving at every given time, that means, you can use at max
10% more memory than usually, and this is a good point.
Why this seems to be magical compared to a big one instance? Nothing
is for free: as a number of instances the different dumps no longer
represent a single point-in-time snapshot, but 10 different point in
time snapshots of different parts of the dataset. The good news is:
this is often not a problem at all.
Cheers,
Salvatore
Jak Sprats
Multiple instances are awesome, but sometimes they start hopping from
core to core (in an undesired fashion), so using "taskset -c <CORE>"
is a good idea EXCEPT rdb-saves & aof-rewrites run on the same core,
which can cause 50%+ performance degradation during the saves (I just
submitted issue 399)
Performance using 32 bit is 40% slower than using 64 bit
Using VM increases memory usage (per key flags for swapped-in/out take
up space), not sure by how much.
If you have really big values, then the overhead of 64 bit pointers is
decreased.
If performance is really important a 1to1 NIC to redis-server instance
w/ NIC CPU affinity setup correctly can help.
W/ the box you have I would use 64bit, and if memory ever becomes
scarce, try to partition any keys that have small values into a 32 bit
instance.
On Dec 8, 12:06 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:
> 2010/12/8 Aníbal Rojas <anibalro...@gmail.com>:
> > I think that you should also consider the persistence in the equation.
>
> > I experimented with 64 bit Redis memory instance in a Quadruple Extra
> > Memory box in the EC2 and, in the end I would have been more
> > comfortable with a set of instances regarding disk IO.
>
> Good point, and from this point of view I think that what makes a lot
> of sense is to have a "persistent" manager, that is, a trivial script
> issuing BGSAVE so that of N instances running in a single box just one
> is saving at any given time.
>
> So if you have 10 instances in a box, even in the most write-heavy
> conditions that will use 100% more ram for copy on write, a single
> instance is saving at every given time, that means, you can use at max
> 10% more memory than usually, and this is a good point.
>
> Why this seems to be magical compared to a big one instance? Nothing
> is for free: as a number of instances the different dumps no longer
> represent a single point-in-time snapshot, but 10 different point in
> time snapshots of different parts of the dataset. The good news is:
> this is often not a problem at all.
>
> Cheers,
> Salvatore
>
> --
Salvatore Sanfilippo
you are right there is a memory cost for VM active per every instance,
that is, in bytes: number of vm pages / 8.
Cheers,
Salvatore
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> 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.
>
>
--
Salvatore 'antirez' Sanfilippo