Auto merge of #1649 - sgrif:sg-enable-profiling, r=jtgeibel

Allow profiling jemalloc

This builds jemalloc with profiling enabled, and preserves debug symbols
in the release binary (note: `debug = true` does not disable
optimizations). This commit by itself doesn't actually perform any
profiling, but it allows it to be controlled by an environment variable.

At this point I cannot get any useful information about the memory issue
we're seeing in production locally. We also can't reproduce it in a
staging environment. There's *something* about our production traffic
patterns that we're missing, so the next step is to start looking at
dumps of production memory usage.

My intention is to start enabling sampling based profiling in
production, and copy some of the dumps off the server to examine
locally.

Author: bors

Cargo.toml

@@ -11,6 +11,7 @@ edition = "2018"
 
 [profile.release]
 opt-level = 2
+debug = true
 
 [lib]
 name = "cargo_registry"
@@ -60,7 +61,7 @@ derive_deref = "1.0.0"
 reqwest = "0.9.1"
 tempdir = "0.3.7"
 parking_lot = "0.7.1"
-jemallocator = { version = "0.1.8", features = ['unprefixed_malloc_on_supported_platforms'] }
+jemallocator = { version = "0.1.8", features = ['unprefixed_malloc_on_supported_platforms', 'profiling'] }
 jemalloc-ctl = "0.2.0"
 
 lettre = {git = "https://github.com/lettre/lettre", version = "0.9"}