Thursday, September 12, 2024

HTAP benchmarks: trying out HATrick with MySQL

For a few years I have only used sysbench and the Insert Benchmark for work but now I need an HTAP benchmark. There are several to choose from but I will start with HATrick. The source is here. It uses C++ and ODBC. I prefer Java (and JDBC), golang or Python but lets see how this goes.

My current OS is Ubuntu 22.04 and I install MySQL in custom locations so I assume that I need to install MySQL's Connector/ODBC from source. That depends on an ODBC driver manager, and for Ubuntu I will try iodbc. I have no experience with ODBC and now I am worried about pointless complexity (I am looking at you Log4J, CORBA and EJB).

The benchmark looks interesting and useful but I'd rather not deal with setting up ODBC again, nor with core dumps. So I will move on and try CH-benchmark from benchmark (Java + JDBC).

The details

So the first step is to install iodbc via: sudo apt install libiodbc2 libiodbc2-dev

Then configure MySQL Connector/ODBC. I didn't expect to need ODBC_INCLUDES= because CMake was able to find iodbc without it, but I do because that path wasn't added to CXXFLAGS unless I added it:

cmake .. -G "Unix Makefiles" \

  -DMYSQLCLIENT_STATIC_LINKING=ON \
  -DBUNDLE_DEPENDENCIES=ON \
  -DMYSQL_CONFIG_EXECUTABLE=/path/to/mysql_config \
  -DDISABLE_GUI=1 \

 -DCMAKE_INSTALL_PREFIX=/install/path/to/myodbc \
 -DODBC_INCLUDES=/usr/include/iodbc

make; make install


Then I compile HATrack after downloading it from github. I had to edit Makefile:


diff --git a/Makefile b/Makefile

index b55f767..fea8860 100644

--- a/Makefile

+++ b/Makefile

@@ -1,6 +1,7 @@

 CC=g++

-CXXFLAGS=-c -std=c++2a

-LDFLAGS=-lodbc -pthread

+CXXFLAGS=-c -std=c++2a -I/usr/include/iodbc

+LDFLAGS=-L/home/me/d/myodbc/lib -lmyodbc8a -pthread

+#LDFLAGS=-lodbc -pthread

 SRCS= src/DataGen.cpp src/DataSrc.cpp src/UserInput.cpp src/Driver.cpp \

 src/DBInit.cpp src/SQLDialect.cpp src/Barrier.cpp src/AnalyticalClient.cpp \

 src/TransactionalClient.cpp src/Workload.cpp src/Globals.cpp \


Then I compile HATrack. The scale factor is hardcoded in src/UserInput.h so you probably need to edit it and compile once per different scale factor you want to try. Compiling just means: make


Then generate data. I assume that ":" is a good value for the delimiter. I had to add LD_LIBRARY_PATH to find the MySQL ODBC libraries that I compiled above.

LD_LIBRARY_PATH=/home/me/d/myodbc/lib \
./HATtrickBench -gen -pa /home/me/hatrick.data -d :


Then load the database. I added secure_file_priv="" to etc/my.cnf for this to work


LD_LIBRARY_PATH=/home/me/d/myodbc/lib \
./HATtrickBench -init -pa /home/me/hatrick.data -usr root -pwd pw -db mysql


All 4 steps completed OK but there was a core dump at the end. While it might be easy to fix I will move on to CH-benchmark which is in benchbase as that means Java + JDBC so I don't have to deal with ODBC, nor must I worry about core dumps.

Program received signal SIGABRT, Aborted.

__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737352611648) at ./nptl/pthread_kill.c:44

44      ./nptl/pthread_kill.c: No such file or directory.

(gdb) where

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737352611648) at ./nptl/pthread_kill.c:44

#1  __pthread_kill_internal (signo=6, threadid=140737352611648) at ./nptl/pthread_kill.c:78

#2  __GI___pthread_kill (threadid=140737352611648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89

#3  0x00007ffff6e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26

#4  0x00007ffff6e287f3 in __GI_abort () at ./stdlib/abort.c:79

#5  0x00007ffff6e2871b in __assert_fail_base (fmt=0x7ffff6fdd130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff6fd9599 "mutex->__data.__owner == 0", file=0x7ffff6fd956e "pthread_mutex_lock.c", line=94, function=<optimized out>)

    at ./assert/assert.c:92

#6  0x00007ffff6e39e96 in __GI___assert_fail (assertion=assertion@entry=0x7ffff6fd9599 "mutex->__data.__owner == 0", file=file@entry=0x7ffff6fd956e "pthread_mutex_lock.c", line=line@entry=94,

    function=function@entry=0x7ffff6fe1840 <__PRETTY_FUNCTION__.0> "___pthread_mutex_lock") at ./assert/assert.c:101

#7  0x00007ffff6e980d0 in ___pthread_mutex_lock (mutex=<optimized out>) at ./nptl/pthread_mutex_lock.c:94

#8  0x0000555555579fdf in __gthread_mutex_lock(pthread_mutex_t*) ()

#9  0x000055555557a034 in std::mutex::lock() ()

#10 0x000055555557a30f in std::unique_lock<std::mutex>::lock() ()

#11 0x000055555557a1a3 in std::unique_lock<std::mutex>::unique_lock(std::mutex&) ()

#12 0x00007ffff770caca in ENV::remove_dbc(DBC*) () from /home/markcallaghan/d/myodbc/lib/libmyodbc8a.so

#13 0x00007ffff770cf2e in DBC::~DBC() () from /home/markcallaghan/d/myodbc/lib/libmyodbc8a.so

#14 0x00007ffff770d610 in my_SQLFreeConnect(void*) () from /home/markcallaghan/d/myodbc/lib/libmyodbc8a.so

#15 0x00007ffff770e4bb in SQLFreeHandle () from /home/markcallaghan/d/myodbc/lib/libmyodbc8a.so

#16 0x000055555556ff64 in Driver::disconnectDB(void*&) ()

#17 0x000055555558a6c8 in main ()


No comments:

Post a Comment

Fixing some of the InnoDB scan perf regressions in a MySQL fork

I recently learned of Advanced MySQL , a MySQL fork, and ran my sysbench benchmarks for it. It fixed some, but not all, of the regressions f...