Meltdown fix impact on Redis performances in virtualized environments

UPDATE: apparently kernel difference may have a serious impact, so I'll redo the test from scratch.

Test performed with AOF enabled, fsync policy 1 second, allowing the rewrites to be triggered.

Command lines used:

View twitter.c
#define F float
F f[]={-.1,-.1,1.7,.8,-.11,-6,.4,-.6,.15,-.3,.22,-3.1,-.1,-.06,3.2,.57,-1.1,19,-176,-4.8,-7.2,43,-86,40,48,65,34,803,39,9.65,-17,-33,-33,16,1167,63,-23,41,-22,9,.56,-.08,4.76,-8,-.28,.63,-1182,-7.27,26.6,-1213,198,5.3,-8.25,38.4,.22,-.78,-903,-7.4,-.26,.42,47.5,33.7,36.5,-184,14.5,-90,3};F o[15];F R(F A,F U){o[0]=A;o[1]=U;F a=0;int k=2,m=3,n=0,z=0,l=1;for(int j=0;j<67;j++){if(j==18)n=2,z=3,m=7,l=-17;if(j==60)n=8,l=-59;if((j+l)%m){a+=f[j]*o[n+(j+z)%m];}else{o[k++]=(F)1/(1+exp(-(a+f[j])));a=0;}}return o[14];}main(){for(int i=0;i<2201;i++){putchar(R(i%55,i/55-5)>.5?58:32);if(!(i%55))putchar(10);}}
View streams.txt
# Let's add a few entries in our stream "mystream". Every entry in a stream is like
# an hash, composed of fields and values, but every entry can have different fields.
# XADD appends a new entry in a stream, and returns an unique ID which is guaranteed
# be incrementing.
# The first part of the ID is the millisecond unixtime during the
# addition (or the time of the last entry in the stream, if greater than the current time).
# The second part of an entry is a 64 bit counter for entries added in the same ms.> XADD mystream name pamela nicknake kill-9
View fizzlefade.html
<!DOCTYPE html>
<canvas id="framebuffer" width="320" height="200"></canvas>
<script type="text/javascript">
/* Fizzlefade using a Feistel network.
View rdbcheck.txt
36143:M 27 Jun 11:18:39.096 # Server initialized
36143:M 27 Jun 11:18:39.096 # Internal error in RDB reading function at rdb.c:1378 -> Unknown RDB encoding type 7
[offset 0] Checking RDB file dump.rdb
[offset 32] AUX FIELD redis-ver = '999.999.999'
[offset 46] AUX FIELD redis-bits = '64'
[offset 58] AUX FIELD ctime = '1498554991'
[offset 73] AUX FIELD used-mem = '1014768'
[offset 89] AUX FIELD aof-preamble = '0'
[offset 139] AUX FIELD repl-id = 'f7a20a009964381cdcc61f401f91f9b228801647'
[offset 154] AUX FIELD repl-offset = '0'
View slowlog_new_output.txt> client setname worker-502
OK> debug sleep 1
(1.00s)> slowlog get
1) 1) (integer) 0
2) (integer) 1497523890
3) (integer) 1002448
4) 1) "debug"
View test_64.c
#include <stdint.h>
#include <pthread.h>
#include <stdio.h>
volatile uint64_t x = 0;
void *writeThread(void *arg) {
for (uint64_t i = 0; i < 10000000; i++) {
while(!__sync_bool_compare_and_swap(&x,x,i+(i<<32))); // x = i+(i<<32)
View background_keys.c
/* The thread entry point that actually executes the blocking part
* of the command HELLO.KEYS.
* Note: this implementation is very simple on purpose, so no duplicated
* keys (returned by SCAN) are filtered. However adding such a functionality
* would be trivial just using any data structure implementing a dictionary
* in order to filter the duplicated items. */
void *HelloKeys_ThreadMain(void *arg) {
RedisModuleBlockedClient *bc = arg;
RedisModuleCtx *ctx = RedisModule_GetThreadSafeContext(bc);
View lmdb.tcl
# Copyriht (C) 2009 Salvatore Sanfilippo <>
# All Rights Reserved
# - cron with cleanup of timedout clients, automatic dump
# - the dump should use array startsearch to write it line by line
# and may just use gets to read element by element and load the whole state.
# - 'help','stopserver','saveandstopserver','save','load','reset','keys' commands.
# - ttl with milliseconds resolution 'ttl a 1000'. Check ttl in dump!
  • Overview delle strutture dati.
  • Persistenza: fork() e copy on write.
  • Implementazione di EXPIRE con sampling a approssimazione dell'algoritmo LRU.
  • Indici secondari usando i sorted set (inclusi i comandi LEX).
  • Geoindexing rappresentato da sorted set.
  • Mass import di dati tramite redis-cli.
  • Protocollo REPL.
  • Lua scripting.
  • Implementazione low level delle strutture dati: 1) Implementazione dual-ported dei sorted set (hash table + skiplist). 2) Hash table con rehashing incementale. 3) Quicklists: ovvero le liste di Redis sono implementate come delle liste linkate di mega-blob che contengono N oggetti.
  • Maxmemory e policy di eviction al raggiungimento della memoria. LRU e LFU.