maria-developers team mailing list archive

["Leif Walsh" <leif.walsh@xxxxxxxxx>]

As far as I know there are no other technical reasons. I don't know how else to be certain that jemalloc is loaded if the user isn't using mysqld_safe though. 
-- 
Cheers,
Leif

On Fri, Apr 26, 2013 at 7:30 AM, Vladislav Vaintroub
<wlad@xxxxxxxxxxxxxxxx> wrote:

>  
>  
> From: Leif Walsh [mailto:leif.walsh@xxxxxxxxx] 
> Sent: Freitag, 26. April 2013 13:18
> To: Vladislav Vaintroub
> Cc: MARK CALLAGHAN; Kristian Nielsen; maria-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Maria-developers] Installing jemalloc on build VMs
>  
> Hi,
>  
> In previous versions, we shipped jemalloc as a shared library and patched mysqld_safe to inject it into LD_PRELOAD. Some users ran mysqld directly and therefore didn't have jemalloc. To protect users from this, we opted to statically link jemalloc into mysqld instead. To my knowledge that's the only reason it's a build dependency. 
>  
> Thanks.  So, is this correct, that unlike what XL said previously,  there is no technical reason to have this build dependency, you  just want to be nice and protect people from  libc.   Every Linux user can run server with  jemalloc if they wished to, e.g via mysqld_safe –malloc-lib=jemalloc, right?
>  
>  
>  
> -- 
> Cheers,
> Leif
>  
> On Fri, Apr 26, 2013 at 3:26 AM, Vladislav Vaintroub <wlad@xxxxxxxxxxxxxxxx> wrote:
> Mark, your links do not tell me why build dependency is good.
> Yes, yes, malloc() replacement du jour is nice,  is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered.
>  
> From: MARK CALLAGHAN [mailto:mdcallag@xxxxxxxxx] 
> Sent: Freitag, 26. April 2013 08:16
> To: Vladislav Vaintroub
> Cc: Kristian Nielsen; Daniel Bartholomew; maria-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Maria-developers] Installing jemalloc on build VMs
>  
> Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that?
> http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html
> http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html
> http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html
>  
> On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@xxxxxxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Maria-developers [mailto:maria-developers-
>> bounces+wlad=montyprogram.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>> Kristian Nielsen
>> Sent: Donnerstag, 25. April 2013 18:30
>> To: Daniel Bartholomew
>> Cc: maria-developers@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Maria-developers] Installing jemalloc on build VMs
>>
>> It is said that tokutek "requires" jemalloc - maybe it would be better to
> fix
>> tokutek to work with standard libraries?
>>
> I wanted to say the same. I do not understand quite how it is possible to
> rely on malloc replacement library - it is a replacement, it is typically
> handled at runtime (using LD_PRELOAD environment variable). Perhaps someone
> familiar with the subject can enlighten us on it.
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>  
> -- 
> Mark Callaghan
> mdcallag@xxxxxxxxx 
>