first attempt to non blocking implementation of slave replication and SYNC bulk data download. Never compiled so far...

Revert "Function to compute RSS memory usage in a fast way, suitable to be called inside keys eviction loops"

This reverts commit 7d47ecd5.

Revert "Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory."

This reverts commit a3e60027.

Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory.

Function to compute RSS memory usage in a fast way, suitable to be called inside keys eviction loops

Make sure to reset the signal handler and deliver again the original crashing signal when dumping the stack trace. This will allow to dump the core if core dumping is enabled.

Object approximated LRU algorithm enhanced / fixed / refactored. This is used for the VM currently but will soon be used for maxmemory expiring.

maxmemory fixed, we now try to release memory just before we check for the memory limit. Before fixing there was code between the attempt to free memory and the check for memory limits, and this code could result into allocations going again after the memory limit.

This should fix Issue 332: when there is a background process saving we still allow the hash tables to grow, but only when a critical treshold is reached. Formerly we prevented the resize at all triggering pathological O(N) behavior. Also there is a fix for the statistics in INFO about the number of keys expired

Fixed segfault in freeMemoryIfNeeded due to the fact that keys are now sds strings and not objects in the main hash table, thanks to Anthony Lauzon for spotting the bug and providing a patch.

The pid file is now created only after the server is correctly initialied. It is also removed on sigterm and when the stack trace is produced after a sigbus or a sigsegv. This two changes should fix the Issue 175

This avoids the extra allocation of sizeof(double) for storing the score
of a zset entry in the hash table. Saves sizeof(double) + malloc
overhead = approx. 16 bytes per zset entry.