well, recent is 3.4.0 however, the releas enotes are not really true jemalloc not linked nor loaded https://mariadb.com/kb/en/mariadb-5533-release-notes/ Other Notable Information MariaDB is now built with jemalloc by default on Linux [root@testserver:~]$ rpm -q --file /usr/libexec/mysqld mariadb-server-5.5.33-6.fc19.20130917.rh.x86_64 [root@testserver:~]$ ldd /usr/libexec/mysqld linux-vdso.so.1 => (0x00007fff16c89000) libaio.so.1 => /lib64/libaio.so.1 (0x00007f8af9864000) libz.so.1 => /lib64/libz.so.1 (0x00007f8af964c000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8af9414000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8af9210000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f8af8fa8000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8af8bd6000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8af88d2000) libm.so.6 => /lib64/libm.so.6 (0x00007f8af85d0000) libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f8af83c0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8af81a4000) libc.so.6 => /lib64/libc.so.6 (0x00007f8af7de3000) /lib64/ld-linux-x86-64.so.2 (0x00007f8afb1f5000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f8af7b76000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8af792d000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8af764f000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8af744a000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8af7215000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8af6fff000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8af6df0000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8af6bec000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8af69d2000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8af67ae000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8af654a000) [root@testserver:~]$ rpm -qa | grep jemalloc jemalloc-devel-3.4.0-1.fc19.x86_64 jemalloc-3.4.0-1.fc19.x86_64 [root@testserver:~]$ lsof | grep jemalloc [root@testserver:~]$ Am 18.09.2013 17:54, schrieb Roberto Spadim:

hummm maybe at mariadb-5.5 release notes should explain about using jemalloc-3.1.0 ? instead of 3.3.1? from what i read, this give a big difference in server with many cores

2013/9/18 Reindl Harald <h.reindl@thelounge.net>:

...

Am 18.09.2013 17:40, schrieb Roberto Spadim:

...

Hi guys, there're benchmark with jemalloc and last malloc implemention?

the much more interesting question - how to build MariaDB with jemalloc

https://lists.launchpad.net/maria-developers/msg05425.html does not really give an answer

hum.... i'm a bit confused now.... reading the revision patch.. http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/3888#extra/je... 3.3.1-0-g9ef9d9e8c271cdf14f664b871a8f98c827714784 why 3.3.1 if 3.1.0 should be better? 2013/9/18 Roberto Spadim <roberto@spadim.com.br>

hum... that's a point to consider, the last link ( https://lists.launchpad.net/maria-developers/msg05425.html) is a bit old: Date: Wed, 24 Apr 2013 18:00:51 +0200

maybe time to a new benchmark? or better explain about binary packages of mariadb? i use the source code version some times and didn't remember about checking malloc versions

from changelog:

- Revision #3888<http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/3888> [merge] Tue 2013-09-10 23:02:25 +0200 - merge with 5.5-tokudb tree (TokuDB 7.0.4). In particular: - add TokuDB, together with the ft-index library - cmake support, auto-detecting whether tokudb can be built - fix packaging - tokudb-engine.rpm, deb - remove PBXT - add jemalloc (no information about version here) - the server is built with jemalloc by default even if TokuDB is not built (no information about version here) - documentation files in RPM are installed in the correct location - support for optional deb packages (tokudb has specific build requirements) - move plugins from mariadb-server deb to appropriate debs (server/test/libmariadbclient) - correct mariadb-test.deb to be not architecture-independent - fix out-of-tree builds to never modify in-tree files - new handler::prepare_index_scan() method

2013/9/18 Reindl Harald <h.reindl@thelounge.net>

...

well, recent is 3.4.0 however, the releas enotes are not really true jemalloc not linked nor loaded

https://mariadb.com/kb/en/mariadb-5533-release-notes/ Other Notable Information MariaDB is now built with jemalloc by default on Linux

[root@testserver:~]$ rpm -q --file /usr/libexec/mysqld mariadb-server-5.5.33-6.fc19.20130917.rh.x86_64

[root@testserver:~]$ ldd /usr/libexec/mysqld linux-vdso.so.1 => (0x00007fff16c89000) libaio.so.1 => /lib64/libaio.so.1 (0x00007f8af9864000) libz.so.1 => /lib64/libz.so.1 (0x00007f8af964c000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8af9414000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8af9210000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f8af8fa8000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8af8bd6000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8af88d2000) libm.so.6 => /lib64/libm.so.6 (0x00007f8af85d0000) libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f8af83c0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8af81a4000) libc.so.6 => /lib64/libc.so.6 (0x00007f8af7de3000) /lib64/ld-linux-x86-64.so.2 (0x00007f8afb1f5000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f8af7b76000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8af792d000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8af764f000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8af744a000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8af7215000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8af6fff000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8af6df0000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8af6bec000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8af69d2000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8af67ae000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8af654a000)

[root@testserver:~]$ rpm -qa | grep jemalloc jemalloc-devel-3.4.0-1.fc19.x86_64 jemalloc-3.4.0-1.fc19.x86_64

[root@testserver:~]$ lsof | grep jemalloc [root@testserver:~]$

Am 18.09.2013 17:54, schrieb Roberto Spadim:

...

hummm maybe at mariadb-5.5 release notes should explain about using jemalloc-3.1.0 ? instead of 3.3.1? from what i read, this give a big difference in server with many cores

2013/9/18 Reindl Harald <h.reindl@thelounge.net>:

...

Am 18.09.2013 17:40, schrieb Roberto Spadim:

...

Hi guys, there're benchmark with jemalloc and last malloc

implemention?

...

the much more interesting question - how to build MariaDB with jemalloc

https://lists.launchpad.net/maria-developers/msg05425.html does not really give an answer

_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

-- Roberto Spadim SPAEmpresarial

-- Roberto Spadim SPAEmpresarial

Hi Sergei! I was reading the patch, in messages inside lauchpad there's a benchmark showing a better performace with version 3.1 of jemalloc, but at mariadb 5.5 we are using 3.3 (if i'm not wrong) I know it's a fresh new release of mariadb, we need time to know if it's really better Any idea why we are using 3.3 instead 3.1, or maybe why not the last jemalloc version? Thanks :) 2013/9/18 Sergei Golubchik <serg@mariadb.org>

Hi, Reindl!

On Sep 18, Reindl Harald wrote:

...

well, recent is 3.4.0 however, the releas enotes are not really true jemalloc not linked nor loaded

https://mariadb.com/kb/en/mariadb-5533-release-notes/ Other Notable Information MariaDB is now built with jemalloc by default on Linux

[root@testserver:~]$ rpm -q --file /usr/libexec/mysqld mariadb-server-5.5.33-6.fc19.20130917.rh.x86_64

Where did you get it from? In the fedora19-update repo I only see mariadb-server-5.5.32.

Anyway, jemalloc is bundled with the mariadb sources and is linked in statically:

$ ldd sql/mysqld|grep jemalloc $ grep jemalloc sql/mysqld Binary file sql/mysqld matches $

Regards, Sergei

_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

-- Roberto Spadim SPAEmpresarial

Hummm no problem, only to my knowledge :) 2013/9/18 Sergei Golubchik <serg@mariadb.org>

Hi, Roberto!

On Sep 18, Roberto Spadim wrote:

...

Hi Sergei! I was reading the patch, in messages inside lauchpad there's a benchmark showing a better performace with version 3.1 of jemalloc, but at mariadb 5.5 we are using 3.3 (if i'm not wrong) I know it's a fresh new release of mariadb, we need time to know if it's really better Any idea why we are using 3.3 instead 3.1, or maybe why not the last jemalloc version?

That's basically what TokuDB team has decided to use, https://github.com/Tokutek/jemalloc

But in the next release one will be able to use system jemalloc.

Regards, Sergei

-- Roberto Spadim SPAEmpresarial

Hi, Reindl! On Sep 18, Reindl Harald wrote:

...

Anyway, jemalloc is bundled with the mariadb sources and is linked in statically:

$ ldd sql/mysqld|grep jemalloc $ grep jemalloc sql/mysqld Binary file sql/mysqld matches

oh no - please no static libraries that is a very bad style and explicitly forbidden by most distributions and patched around whereever upstreams insists on it

so we really need soemthing like

-DWITH_SSL=system \ -DWITH_ZLIB=system \

Yes. https://mariadb.atlassian.net/browse/MDEV-5026 I'll fix it for 5.5.34 At the moment you can try a workaround -DWITH_JEMALLOC=no -DLIBJEMALLOC=jemalloc (or only the first one, to disable jemalloc completely) Regards, Sergei

Am 18.09.2013 19:22, schrieb Roberto Spadim:

hum about static libs... a default binary version with static libs are ok to me

a binary yes a source build should *never* default to static linking

... if anyone need a more "dynamic" we could compiler a second binary version

as said the binary packages does not matter distribution ones does 98 out of 100 users get their binaries from them upstream binaries are linked statically because you never know about a major upgrade of whatever distribution which would need a rebuild while break the binary for others

static is very easier to report bugs, we just know what is running and don't need to ask users about it today when i install mariadb i use the binary package, i'm not using rpm deb or others packages... when possible i have the binary and a copy of source package with a compiled binary (to make sure i can change if something happen, or a important patch appear)

in theory yes practically not really because you depend on enough dynamic libraries linking other libraries dynamic that you can only catch specific things with static linking but never make regressions impossible in case of cross-dependencies you may even hit a bug *because* you linked whatever statically and one of the dynamic libraries doe snot work properly with it while the distribution ships a patch for this siutuation not visible for you *because* of the static linking defaulting to static/bundeled libraries only makes the life of distributions harder they work around it, the ordinary user does not compile from source and the userbase which does has enough expierience to verify the results

2013/9/18 Sergei Golubchik <serg@mariadb.org <mailto:serg@mariadb.org>>

Hi, Reindl!

On Sep 18, Reindl Harald wrote: > > > Anyway, jemalloc is bundled with the mariadb sources and is linked in > > statically: > > > > $ ldd sql/mysqld|grep jemalloc > > $ grep jemalloc sql/mysqld > > Binary file sql/mysqld matches > > oh no - please no static libraries that is a very bad style > and explicitly forbidden by most distributions and patched > around whereever upstreams insists on it > > so we really need soemthing like > > -DWITH_SSL=system \ > -DWITH_ZLIB=system \

Yes. https://mariadb.atlassian.net/browse/MDEV-5026 I'll fix it for 5.5.34 At the moment you can try a workaround

-DWITH_JEMALLOC=no -DLIBJEMALLOC=jemalloc

(or only the first one, to disable jemalloc completely)

Am 18.09.2013 19:07, schrieb Reindl Harald:

Am 18.09.2013 18:35, schrieb Sergei Golubchik:

...

Anyway, jemalloc is bundled with the mariadb sources and is linked in statically:

$ ldd sql/mysqld|grep jemalloc $ grep jemalloc sql/mysqld Binary file sql/mysqld matches

oh no - please no static libraries that is a very bad style and explicitly forbidden by most distributions and patched around whereever upstreams insists on it

so we really need soemthing like

-DWITH_SSL=system \ -DWITH_ZLIB=system \

or if it exists a more recent online manual because i often enough find things referring to ./configure and not cmake while figure it out from the source tree is not that nice for web-developers like which are good in rpm-building but not in C/C++ sources and make-scripts

don't get me wrong - but that is a joke looking at the commented line there was even a "-DWITH_JEMALLOC=system" planned and later dropped - that is not how linux systems should work if there is a security bug in whatever bundeled library and the distribution is pushing a update mariadb will still use the vulnerable version and that is why linux-distributions would use "-DWITH_JEMALLOC=no" if they can't patch around this upstream bug to not violate packaging guidelines the solution is support "-DWITH_JEMALLOC=system" and if it does not work with "jemalloc-3.4.0" this is a bug because dbmail and Apache Trafficserver are doing ________________________________________ SET(WITH_JEMALLOC "yes" CACHE STRING "Which jemalloc to use (possible values are 'no', 'bundled', 'yes' (same as bundled)") #"Which jemalloc to use (possible values are 'no', 'bundled', 'system', 'yes' (system if possible, otherwise bundled)") MACRO (CHECK_JEMALLOC) IF(WIN32) SET(WITH_JEMALLOC "no") ENDIF() IF(WITH_JEMALLOC STREQUAL "bundled" OR WITH_JEMALLOC STREQUAL "yes") USE_BUNDLED_JEMALLOC() ENDIF() ENDMACRO()