2009-03-22 10:30:00 +01:00
|
|
|
/* zmalloc - total amount of allocated memory aware version of malloc()
|
|
|
|
*
|
2010-02-19 11:23:57 +01:00
|
|
|
* Copyright (c) 2009-2010, Salvatore Sanfilippo <antirez at gmail dot com>
|
2009-03-22 10:30:00 +01:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
|
|
|
* * Redistributions of source code must retain the above copyright notice,
|
|
|
|
* this list of conditions and the following disclaimer.
|
|
|
|
* * Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* * Neither the name of Redis nor the names of its contributors may be used
|
|
|
|
* to endorse or promote products derived from this software without
|
|
|
|
* specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
|
|
|
|
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2011-06-20 11:34:04 +02:00
|
|
|
#ifndef __ZMALLOC_H
|
|
|
|
#define __ZMALLOC_H
|
|
|
|
|
|
|
|
/* Double expansion needed for stringification of macro values. */
|
|
|
|
#define __xstr(s) __str(s)
|
|
|
|
#define __str(s) #s
|
|
|
|
|
|
|
|
#if defined(USE_TCMALLOC)
|
|
|
|
#define ZMALLOC_LIB ("tcmalloc-" __xstr(TC_VERSION_MAJOR) "." __xstr(TC_VERSION_MINOR))
|
|
|
|
#include <google/tcmalloc.h>
|
2012-04-05 08:25:22 +02:00
|
|
|
#if (TC_VERSION_MAJOR == 1 && TC_VERSION_MINOR >= 6) || (TC_VERSION_MAJOR > 1)
|
2011-06-20 11:34:04 +02:00
|
|
|
#define HAVE_MALLOC_SIZE 1
|
|
|
|
#define zmalloc_size(p) tc_malloc_size(p)
|
|
|
|
#else
|
|
|
|
#error "Newer version of tcmalloc required"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#elif defined(USE_JEMALLOC)
|
|
|
|
#define ZMALLOC_LIB ("jemalloc-" __xstr(JEMALLOC_VERSION_MAJOR) "." __xstr(JEMALLOC_VERSION_MINOR) "." __xstr(JEMALLOC_VERSION_BUGFIX))
|
|
|
|
#include <jemalloc/jemalloc.h>
|
2012-04-05 08:25:22 +02:00
|
|
|
#if (JEMALLOC_VERSION_MAJOR == 2 && JEMALLOC_VERSION_MINOR >= 1) || (JEMALLOC_VERSION_MAJOR > 2)
|
2011-06-20 11:34:04 +02:00
|
|
|
#define HAVE_MALLOC_SIZE 1
|
2012-05-15 15:27:12 +02:00
|
|
|
#define zmalloc_size(p) je_malloc_usable_size(p)
|
2011-06-20 11:34:04 +02:00
|
|
|
#else
|
|
|
|
#error "Newer version of jemalloc required"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
#include <malloc/malloc.h>
|
|
|
|
#define HAVE_MALLOC_SIZE 1
|
|
|
|
#define zmalloc_size(p) malloc_size(p)
|
|
|
|
#endif
|
|
|
|
|
2021-02-24 09:48:04 +02:00
|
|
|
/* On native libc implementations, we should still do our best to provide a
|
2021-02-25 09:24:41 +02:00
|
|
|
* HAVE_MALLOC_SIZE capability. This can be set explicitly as well:
|
|
|
|
*
|
|
|
|
* NO_MALLOC_USABLE_SIZE disables it on all platforms, even if they are
|
|
|
|
* known to support it.
|
|
|
|
* USE_MALLOC_USABLE_SIZE forces use of malloc_usable_size() regardless
|
|
|
|
* of platform.
|
2021-02-24 09:48:04 +02:00
|
|
|
*/
|
2011-06-20 11:34:04 +02:00
|
|
|
#ifndef ZMALLOC_LIB
|
|
|
|
#define ZMALLOC_LIB "libc"
|
2021-03-07 14:14:23 +02:00
|
|
|
|
2021-02-25 09:24:41 +02:00
|
|
|
#if !defined(NO_MALLOC_USABLE_SIZE) && \
|
|
|
|
(defined(__GLIBC__) || defined(__FreeBSD__) || \
|
|
|
|
defined(USE_MALLOC_USABLE_SIZE))
|
2021-03-07 14:14:23 +02:00
|
|
|
|
|
|
|
/* Includes for malloc_usable_size() */
|
|
|
|
#ifdef __FreeBSD__
|
|
|
|
#include <malloc_np.h>
|
|
|
|
#else
|
2018-06-19 16:59:45 +03:00
|
|
|
#include <malloc.h>
|
2021-03-07 14:14:23 +02:00
|
|
|
#endif
|
|
|
|
|
2018-06-19 16:59:45 +03:00
|
|
|
#define HAVE_MALLOC_SIZE 1
|
|
|
|
#define zmalloc_size(p) malloc_usable_size(p)
|
2021-03-07 14:14:23 +02:00
|
|
|
|
2018-06-19 16:59:45 +03:00
|
|
|
#endif
|
2011-06-20 11:34:04 +02:00
|
|
|
#endif
|
2009-03-22 10:30:00 +01:00
|
|
|
|
2017-01-10 11:25:39 +01:00
|
|
|
/* We can enable the Redis defrag capabilities only if we are using Jemalloc
|
|
|
|
* and the version used is our special version modified for Redis having
|
|
|
|
* the ability to return per-allocation fragmentation hints. */
|
|
|
|
#if defined(USE_JEMALLOC) && defined(JEMALLOC_FRAG_HINT)
|
|
|
|
#define HAVE_DEFRAG
|
|
|
|
#endif
|
|
|
|
|
2009-03-22 10:30:00 +01:00
|
|
|
void *zmalloc(size_t size);
|
2010-07-24 23:20:00 +02:00
|
|
|
void *zcalloc(size_t size);
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 12:01:05 +00:00
|
|
|
void *zcalloc_num(size_t num, size_t size);
|
2009-03-22 10:30:00 +01:00
|
|
|
void *zrealloc(void *ptr, size_t size);
|
2020-11-22 21:22:49 +02:00
|
|
|
void *ztrymalloc(size_t size);
|
|
|
|
void *ztrycalloc(size_t size);
|
|
|
|
void *ztryrealloc(void *ptr, size_t size);
|
2009-03-23 14:50:09 +01:00
|
|
|
void zfree(void *ptr);
|
2020-10-02 08:19:44 +03:00
|
|
|
void *zmalloc_usable(size_t size, size_t *usable);
|
|
|
|
void *zcalloc_usable(size_t size, size_t *usable);
|
|
|
|
void *zrealloc_usable(void *ptr, size_t size, size_t *usable);
|
2020-11-22 21:22:49 +02:00
|
|
|
void *ztrymalloc_usable(size_t size, size_t *usable);
|
|
|
|
void *ztrycalloc_usable(size_t size, size_t *usable);
|
|
|
|
void *ztryrealloc_usable(void *ptr, size_t size, size_t *usable);
|
2020-10-02 08:19:44 +03:00
|
|
|
void zfree_usable(void *ptr, size_t *usable);
|
2009-03-22 10:30:00 +01:00
|
|
|
char *zstrdup(const char *s);
|
|
|
|
size_t zmalloc_used_memory(void);
|
2012-08-24 12:55:37 +02:00
|
|
|
void zmalloc_set_oom_handler(void (*oom_handler)(size_t));
|
2010-11-02 10:51:09 +01:00
|
|
|
size_t zmalloc_get_rss(void);
|
2018-02-18 17:36:21 +02:00
|
|
|
int zmalloc_get_allocator_info(size_t *allocated, size_t *active, size_t *resident);
|
2019-05-30 12:51:32 +03:00
|
|
|
void set_jemalloc_bg_thread(int enable);
|
|
|
|
int jemalloc_purge();
|
2016-09-19 10:28:05 +02:00
|
|
|
size_t zmalloc_get_private_dirty(long pid);
|
|
|
|
size_t zmalloc_get_smap_bytes_by_field(char *field, long pid);
|
2014-12-17 17:11:20 +01:00
|
|
|
size_t zmalloc_get_memory_size(void);
|
2012-03-27 15:24:33 +02:00
|
|
|
void zlibc_free(void *ptr);
|
Use madvise(MADV_DONTNEED) to release memory to reduce COW (#8974)
## Backgroud
As we know, after `fork`, one process will copy pages when writing data to these
pages(CoW), and another process still keep old pages, they totally cost more memory.
For redis, we suffered that redis consumed much memory when the fork child is serializing
key/values, even that maybe cause OOM.
But actually we find, in redis fork child process, the child process don't need to keep some
memory and parent process may write or update that, for example, child process will never
access the key-value that is serialized but users may update it in parent process.
So we think it may reduce COW if the child process release memory that it is not needed.
## Implementation
For releasing key value in child process, we may think we call `decrRefCount` to free memory,
but i find the fork child process still use much memory when we don't write any data to redis,
and it costs much more time that slows down bgsave. Maybe because memory allocator doesn't
really release memory to OS, and it may modify some inner data for this free operation, especially
when we free small objects.
Moreover, CoW is based on pages, so it is a easy way that we only free the memory bulk that is
not less than kernel page size. madvise(MADV_DONTNEED) can quickly release specified region
pages to OS bypassing memory allocator, and allocator still consider that this memory still is used
and don't change its inner data.
There are some buffers we can release in the fork child process:
- **Serialized key-values**
the fork child process never access serialized key-values, so we try to free them.
Because we only can release big bulk memory, and it is time consumed to iterate all
items/members/fields/entries of complex data type. So we decide to iterate them and
try to release them only when their average size of item/member/field/entry is more
than page size of OS.
- **Replication backlog**
Because replication backlog is a cycle buffer, it will be changed quickly if redis has heavy
write traffic, but in fork child process, we don't need to access that.
- **Client buffers**
If clients have requests during having the fork child process, clients' buffer also be changed
frequently. The memory includes client query buffer, output buffer, and client struct used memory.
To get child process peak private dirty memory, we need to count peak memory instead
of last used memory, because the child process may continue to release memory (since
COW used to only grow till now, the last was equivalent to the peak).
Also we're adding a new `current_cow_peak` info variable (to complement the existing
`current_cow_size`)
Co-authored-by: Oran Agra <oran@redislabs.com>
2021-08-05 04:01:46 +08:00
|
|
|
void zmadvise_dontneed(void *ptr);
|
2009-03-22 10:30:00 +01:00
|
|
|
|
2017-01-10 11:25:39 +01:00
|
|
|
#ifdef HAVE_DEFRAG
|
|
|
|
void zfree_no_tcache(void *ptr);
|
|
|
|
void *zmalloc_no_tcache(size_t size);
|
|
|
|
#endif
|
|
|
|
|
2012-02-07 13:05:36 +01:00
|
|
|
#ifndef HAVE_MALLOC_SIZE
|
|
|
|
size_t zmalloc_size(void *ptr);
|
2020-10-02 08:19:44 +03:00
|
|
|
size_t zmalloc_usable_size(void *ptr);
|
2018-02-21 20:18:34 +02:00
|
|
|
#else
|
2020-10-02 08:19:44 +03:00
|
|
|
#define zmalloc_usable_size(p) zmalloc_size(p)
|
2012-02-07 13:05:36 +01:00
|
|
|
#endif
|
|
|
|
|
Add warning for suspected slow system clocksource setting (#10636)
This PR does 2 main things:
1) Add warning for suspected slow system clocksource setting. This is Linux specific.
2) Add a `--check-system` argument to redis which runs all system checks and prints a report.
## System checks
Add a command line option `--check-system` which runs all known system checks and provides
a report to stdout of which systems checks have failed with details on how to reconfigure the
system for optimized redis performance.
The `--system-check` mode exists with an appropriate error code after running all the checks.
## Slow clocksource details
We check the system's clocksource performance by running `clock_gettime()` in a loop and then
checking how much time was spent in a system call (via `getrusage()`). If we spend more than
10% of the time in the kernel then we print a warning. I verified that using the slow clock sources:
`acpi_pm` (~90% in the kernel on my laptop) and `xen` (~30% in the kernel on an ec2 `m4.large`)
we get this warning.
The check runs 5 system ticks so we can detect time spent in kernel at 20% jumps (0%,20%,40%...).
Anything more accurate will require the test to run longer. Typically 5 ticks are 50ms. This means
running the test on startup will delay startup by 50ms. To avoid this we make sure the test is only
executed in the `--check-system` mode.
For a quick startup check, we specifically warn if the we see the system is using the `xen` clocksource
which we know has bad performance and isn't recommended (at least on ec2). In such a case the
user should manually rung redis with `--check-system` to force the slower clocksource test described
above.
## Other changes in the PR
* All the system checks are now implemented as functions in _syscheck.c_.
They are implemented using a standard interface (see details in _syscheck.c_).
To do this I moved the checking functions `linuxOvercommitMemoryValue()`,
`THPIsEnabled()`, `linuxMadvFreeForkBugCheck()` out of _server.c_ and _latency.c_
and into the new _syscheck.c_. When moving these functions I made sure they don't
depend on other functionality provided in _server.c_ and made them use a standard
"check functions" interface. Specifically:
* I removed all logging out of `linuxMadvFreeForkBugCheck()`. In case there's some
unexpected error during the check aborts as before, but without any logging.
It returns an error code 0 meaning the check didn't not complete.
* All these functions now return 1 on success, -1 on failure, 0 in case the check itself
cannot be completed.
* The `linuxMadvFreeForkBugCheck()` function now internally calls `exit()` and not
`exitFromChild()` because the latter is only available in _server.c_ and I wanted to
remove that dependency. This isn't an because we don't need to worry about the
child process created by the test doing anything related to the rdb/aof files which
is why `exitFromChild()` was created.
* This also fixes parsing of other /proc/\<pid\>/stat fields to correctly handle spaces
in the process name and be more robust in general. Not that before this fix the rss
info in `INFO memory` was corrupt in case of spaces in the process name. To
recreate just rename `redis-server` to `redis server`, start it, and run `INFO memory`.
2022-05-22 17:10:31 +03:00
|
|
|
int get_proc_stat_ll(int i, long long *res);
|
|
|
|
|
2018-09-30 11:49:03 +02:00
|
|
|
#ifdef REDIS_TEST
|
2021-11-16 14:55:10 +08:00
|
|
|
int zmalloc_test(int argc, char **argv, int flags);
|
2018-09-30 11:49:03 +02:00
|
|
|
#endif
|
|
|
|
|
2011-06-20 11:34:04 +02:00
|
|
|
#endif /* __ZMALLOC_H */
|