[Nix-dev] Transparent Hugepage Support & Redis

[4levels]

Hi Tobias,

Thank you for your quick reply!

I was asking this since my redis job queue was hanging for 2 days without
any failure notice. Restarting the redis service didn't change anything, it
was only after a server reboot that the queue started working again,
rushing through 2 days of pending jobs in one go.

As this warning in Redis is the only clue I could find I posted this
question here..

Kind regards,

Erik

On Sun, Jun 12, 2016, 13:49 Tobias Geerinckx-Rice <me at tobias.gr> wrote:

> Hullo,
>
> On 12/06/16 12:00, 4levels wrote:
> > when starting Redis I keep getting warnings about Transparent Hugepage
> > Support being enabled in the kernel and how this may negatively impact
> > Redis' performance.
> > [snip]
> >  3. Or is there a better way to only disable this for Redis only?
> >     My guess would be something like "always [madvise redis] never"
>
> The whole point of HUGEPAGE_MADVISE as I understand it, is that
> hugepages are not allocated until an application explicitly requests
> them using MADV_HUGEPAGE. In other words: the *Transparent* Hugepage
> Support that Redis warns about is in fact disabled by default.
>
> So unless Redis explicitly requests hugepages only to then complain
> about them, or there's some other weird interaction, my first guess
> would be that their check is a bit too strict and assumes that !never ==
> always.
>
> If the warning really bothers you, you can always override your kernel
> configuration with something like:
>
>       // Copy-pasted from my config, sort of:
>       nixpkgs.config.packageOverrides = {
>         stdenv = stdenv // {
>           platform = stdenv.platform // {
>             kernelExtraConfig = ''
>               TRANSPARENT_HUGEPAGE? n
>             '';
>           };
>         };
>       };
>
> but my suspicion that it's entirely unneeded still stands.
>
> Kind regards,
>
> T G-R
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160612/83bd36cb/attachment-0001.html>