- users-list - monetdb.org

#!ERROR: THRnew: too many threads
by Murthy, Gautham 13 Aug '18

13 Aug '18

Hello, We had a DB crash reported with the below messages, Do we need alter any system level parameters or changes to avoid the below issue - Server has 128 CPU and 1TB memory. 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads /etc/security/limits.conf monetadmin soft nproc 102400 monetadmin hard nproc 102400 monetadmin soft nofile 500000 monetadmin hard nofile 500000 monetadmin soft stack 10240 monetadmin soft memlock unlimited monetadmin hard memlock unlimited [monetadmin@lnx1535 DBFARM_TSV_P_B]$ /monet_binaries/MonetDB-11.27.13_PY/bin/monetdb -p 50010 get all TSV_PROD_DB_B name prop source value TSV_PROD_DB_B name - TSV_PROD_DB_B TSV_PROD_DB_B type default database TSV_PROD_DB_B shared default yes TSV_PROD_DB_B nthreads default 128 TSV_PROD_DB_B optpipe local sequential_pipe TSV_PROD_DB_B readonly local yes TSV_PROD_DB_B embedr default no TSV_PROD_DB_B embedpy local yes TSV_PROD_DB_B embedpy3 default no TSV_PROD_DB_B nclients local 2048 TSV_PROD_DB_B dbextra default <unknown> [monetadmin@lnx1535 DBFARM_TSV_P_B]$ 2018-08-13 08:46:30 MSG merovingian[36790]: target connection is on local UNIX domain socket, passing on filedescriptor instead of proxying 2018-08-13 08:46:30 MSG merovingian[36790]: proxying client 10.106.5.250:29929 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:46:30 MSG merovingian[36790]: target connection is on local UNIX domain socket, passing on filedescriptor instead of proxying 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:31 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:33 MSG merovingian[36790]: proxying client 10.106.5.250:29957 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:46:33 MSG merovingian[36790]: target connection is on local UNIX domain socket, passing on filedescriptor instead of proxying 2018-08-13 08:46:36 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:46:40 MSG merovingian[36790]: proxying client 10.106.5.250:64830 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:46:40 MSG merovingian[36790]: target connection is on local UNIX domain socket, passing on filedescriptor instead of proxying 2018-08-13 08:46:42 MSG TSV_PROD_DB_B[57408]: #!ERROR: THRnew: too many threads 2018-08-13 08:47:47 MSG discovery[36790]: new neighbour lnx1536.ch3.prod.i.com (lnx1536.ch3.prod.i.com) 2018-08-13 08:47:48 MSG discovery[36790]: new database mapi:monetdb://lnx1536.ch3.prod.i.com:50010/TSV_PROD_DB_B (ttl=660s) 2018-08-13 08:48:55 MSG merovingian[36790]: database 'TSV_PROD_DB_B' (57408) has crashed (dumped core) 2018-08-13 08:49:12 MSG merovingian[36790]: database 'TSV_PROD_DB_B' has crashed after start on 2018-08-13 05:35:17, attempting restart, up min/avg/max: 2h/5d/3w, crash average: 1.00 0.70 0.43 (23-10=13) 2018-08-13 08:49:12 MSG TSV_PROD_DB_B[72455]: arguments: /monet_binaries/MonetDB-11.27.13_PY/bin/mserver5 --dbpath=/monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B --set merovingian_uri=mapi:monetdb://lnx1535.ch3.prod.i.com:50010/TSV_PROD_DB_B --set mapi_open=false --set mapi_port=0 --set 2018-08-13 08:49:12 MSG TSV_PROD_DB_B[72455]: mapi_usock=/monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock --set monet_vault_key=/monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.vaultkey --set gdk_nr_threads=128 --set max_clients=2048 --set sql_optimizer=sequential_pipe --set embedded_py=true --readonly --set monet_daemon=yes 2018-08-13 08:49:12 MSG TSV_PROD_DB_B[72455]: 2018-08-13 08:49:12 MSG merovingian[36790]: proxying client 10.106.5.250:16467 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:49:12 MSG merovingian[36790]: proxying client 10.106.5.250:45439 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:49:12 MSG merovingian[36790]: starting a proxy failed: cannot connect: Connection refused 2018-08-13 08:49:12 ERR control[36790]: !monetdbd: an internal error has occurred 'cannot connect: Connection refused' 2018-08-13 08:49:12 ERR merovingian[36790]: client error: cannot connect: Connection refused 2018-08-13 08:49:12 MSG merovingian[36790]: proxying client 10.106.5.250:45447 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B 2018-08-13 08:49:12 ERR control[36790]: !monetdbd: an internal error has occurred 'cannot connect: Connection refused' 2018-08-13 08:49:12 MSG merovingian[36790]: starting a proxy failed: cannot connect: Connection refused 2018-08-13 08:49:13 ERR merovingian[36790]: client error: cannot connect: Connection refused 2018-08-13 08:49:13 MSG merovingian[36790]: proxying client 10.106.5.250:36605 for database 'TSV_PROD_DB_B' to mapi:monetdb:///monet_data02/DBFARM_TSV_P_B/TSV_PROD_DB_B/.mapi.sock?database=TSV_PROD_DB_B /etc/security/limits.conf monetadmin soft nproc 102400 monetadmin hard nproc 102400 monetadmin soft nofile 500000 monetadmin hard nofile 500000 monetadmin soft stack 10240 monetadmin soft memlock unlimited monetadmin hard memlock unlimited [monetadmin@lnx1535 DBFARM_TSV_P_B]$ /monet_binaries/MonetDB-11.27.13_PY/bin/monetdb -p 50010 get all TSV_PROD_DB_B name prop source value TSV_PROD_DB_B name - TSV_PROD_DB_B TSV_PROD_DB_B type default database TSV_PROD_DB_B shared default yes TSV_PROD_DB_B nthreads default 128 TSV_PROD_DB_B optpipe local sequential_pipe TSV_PROD_DB_B readonly local yes TSV_PROD_DB_B embedr default no TSV_PROD_DB_B embedpy local yes TSV_PROD_DB_B embedpy3 default no TSV_PROD_DB_B nclients local 2048 TSV_PROD_DB_B dbextra default <unknown> [monetadmin@lnx1535 DBFARM_TSV_P_B]$

1 0

SQL Statements are skipped when run via scripts concurrently on different tables
by Murthy, Gautham 06 Aug '18

06 Aug '18

Hello, Application Teams are experiencing a behavior where few statements are skipped when executed via scripts, They are running multiple scripts concurrently on different tables. Please let us know if there are any know issues or a fix for the reported behavior. Database: MonetDB v11.27.13 (Jul2017-SP4) ü DROP, CREATE, INSERT - New SQL sequence, however looks like SQL statement are not executing as in order in database as per system catalog table log time entries. We need to check on this. ü First DROP, INSERT started and then after couple of statements, CREATE SQL started executing. DROP TABLE IF EXISTS "KEYFOOD_IT_S_22_43321_C";^M CREATE TABLE "KEYFOOD_IT_S_22_43321_C"(ATTR_NAME VARCHAR(500) NOT NULL, COL_NAME VARCHAR(30) NOT NULL, AVP_KEY INTEGER NOT NULL, ATTR_VALUE VARCHAR(3000), ATTR_LONG_VALUE VARCHAR(3000), ATTR_SHORT_VALUE VARCHAR(100), ATTR_MEDIUM_VALUE VARCHAR(100), PARENT_AVP_KEY INTEGER, SORT_ORDER INTEGER); INSERT INTO "KEYFOOD_IT_S_22_43321_C" (ATTR_NAME, COL_NAME, AVP_KEY, ATTR_VALUE, ATTR_LONG_VALUE, ATTR_SHORT_VALUE, ATTR_MEDIUM_VALUE, PARENT_AVP_KEY, SORT_ORDER) SELECT ATTR_NAME, COL_NAME, AVP_KEY, ATTR_VALUE, ATTR_LONG_VALUE, ATTR_SHORT_VALUE, ATTR_MEDIUM_VALUE, PARENT_AVP_KEY, SORT_ORDER FROM "IT_DSJ_KEYFOOD_43321" WHERE COL_NAME='S_22_KEY' AND SORT_TYPE='CATG'; We were able to statements being skipped in sys.querylog_catalog and sys.querylog_calls. Thank You, Gautham

2 1

incorrect data being fetched with WHERE clause
by Murthy, Gautham 06 Aug '18

06 Aug '18

Hello, Data is retrieved which are not available in "where" clause. Application teams have seen some cases where this works fine after some hours. After data load we are seeing incorrect data being fetched. Are there any know issues with the below versions ? Database: MonetDB v11.27.13 (Jul2017-SP4) sql>select * FROM "IT_DSJ_NCKLDN_45121" WHERE COL_NAME='M_59647_KEY' AND SORT_TYPE='ORTH'; +-------------------+--------------+------------+-------------------+-------------------+--------------------+--------------------+------+-------+------+ | attr_name | col_name | avp_key | attr_value | attr_long_value | attr_short_value | attr_medium_value | pare | sort_ | sort | : : : : : : : : nt_a : order : _typ : : : : : : : : : vp_k : : e : : : : : : : : : ey : : : +===================+==============+============+===================+===================+====================+====================+======+=======+======+ | ABRASIVE INFO | S_22_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | CATG | | ABRASIVE INFO | S_22_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | ORTH | | ABRASIVE INFO | S_22_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | ORTH | | ABSORBENCY LEVEL | S_23_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | CATG | | ABSORBENCY LEVEL | S_23_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | ORTH | | ABSORBENCY LEVEL | S_23_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | ORTH | | ACTIVE INGREDIENT | S_25_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | CATG | | ACTIVE INGREDIENT | S_25_KEY | 30000 | N/A | N/A | N/A | N/A | null | 30000 | ORTH | Thank You, Gautham

2 1

Do "upserts" supports in MonetDB?
by Sharma, Sreejith 06 Aug '18

06 Aug '18

Hello, Is there any roadmap for implementing "upserts" or "merge" alike in oracle for MonetDB? Or is it already available? Regards, Sreejith

1 0

Django + MonetDB
by ALEX OSSIPOV 05 Aug '18

05 Aug '18

Hi All I was looking to use MonetDB with Django framework but couldn't find MonetSQLdb package and all references point to 10 years old git code. Is it possible to use current versions of MonetDB with Django and where can I find required packages with configuration instructions? Thanks Alex

1 0

outstanding updates
by Roberto Cornacchia 03 Aug '18

03 Aug '18

Hi, We are having a problem, for a while, that is difficult to isolate. Our ETL includes the following steps: 1) Open JDBC connection, add data to a table, commit, close connection 2) Open JDBC connection, some ALTER TALBLE statements, commit, close connection Occasionally, we get the following during step 2) : java.sql.SQLException: ALTER TABLE: set READ or INSERT ONLY not possible with outstanding updates (wait until updates are flushed) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConnection.java:2732) What puzzles me is that step one is completed when this happens, the commit is done and the connection is closed (we triple-checked that is actually is closed). Notice that inserting a sleep between the to steps makes it work correctly. As I said, this is hard to isolate and reproduce. Still, can anyone guess what is exactly happening? Can it be that a background process is still flushing updates from step 1) ? Even if the JDBC connection is closed ? Can we force a blocking flush, so that it doesn't return until it's safe? If not, how can we know when updates are flushed? Thanks, Roberto

2 5

Mercurial source compilation fails on Mac OS 10.13.5
by Ying Zhang 19 Jul '18

19 Jul '18

Dear all, Not sure how long this has been going on, but I was just trying to refresh my MonetDB installation (compiled from Mercurial source code), but it failed with the following errors: In file included from /Users/jennie/monet/Mar2018/sql/backends/monet5/UDF/pyapi3/pyapi3.c:13: /Users/jennie/monet/Mar2018/sql/backends/monet5/UDF/pyapi3/../pyapi/pyapi.c:968:18: error: assigning to 'char *' from 'const char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] retnames[i] = PyUnicode_AsUTF8(colname); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jennie/monet/Mar2018/sql/backends/monet5/UDF/pyapi3/../pyapi/pyapi.c:1382:19: error: assigning to 'char *' from 'const char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] py_error_string = PyString_AS_STRING(error); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ Mac OS 10.13.5 Darwin Kernel Version 17.6.0 Happens with both Mar2018 and default branch Does anyone know how to fix these errors and get MonetDB compiled? Thanks in advance! Regards, Jennie

2 2

Mar2018 production compilation fails on Fedora 28
by Roberto Cornacchia 19 Jul '18

19 Jul '18

Compiling from Mar2018 branch, today's hg tip, with production settings: --disable-debug --disable-developer --disable-assert --enable-optimize Fails with this on Fedora 28: In file included from /usr/include/string.h:494, from /home/roberto/MonetDBServer/MonetDB.Spinque_Mar2018/src/gdk/gdk.h:316, from /home/roberto/MonetDBServer/MonetDB.Spinque_Mar2018/src/gdk/gdk_calc.c:10: In function ‘memcpy’, inlined from ‘addstr_loop’ at /home/roberto/MonetDBServer/MonetDB.Spinque_Mar2018/src/gdk/gdk_calc.c:3415:3: /usr/include/bits/string_fortified.h:34:10: error: ‘__builtin_memcpy’ forming offset [3, 65535] is out of the bounds [0, 2] of object ‘str_nil’ with type ‘const char[2]’ [-Werror=array-bounds] return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (same error in several files) Compiling with debug settings succeeds: --enable-debug --enable-developer --enable-assert --disable-optimize Is this reproducible or has it something to do with my machine?

3 2

MonetDB Mar2018 Release - Connection terminates abruptly with no error codes/messages
by Murthy, Gautham 18 Jul '18

18 Jul '18

Hello, MonetDB release - MonetDB Mar2018 We are facing issues when trying to run queries concurrently on the newer version of MonetDB. When 2 or more sessions (create/drop tables) are executed concurrently, sessions get terminated without any error messages. Do we need to explicitly enable error feedback? Does hitting concurrency abruptly terminates the session/connection ? [monetadmin@lnx1490 ~]$ /monet_binaries/MonetDB-11.27.13_PY/bin/mclient mapi:monetdb://lnx1490.ch3.prod.i.com:50105/TSV_PROD_DB_A_C -u DM_POS_TSV_MRT_P6A password: Welcome to mclient, the MonetDB/SQL interactive terminal (Jul2017-SP4) Database: MonetDB v11.29.7 (Mar2018-SP1), 'mapi:monetdb://lnx1490.ch3.prod.i.com:50105/TSV_PROD_DB_A_C' Type \q to quit, \? for a list of available commands auto commit mode: on sql>\</factorydata/prddata02/prd/crosscut_output/create_desc_it_dsj_campbell_33423.sql [monetadmin@lnx1490 ~]$ Thank You, Gautham

1 0

MonetDB Crashed - Version Jul2017-SP4 - GDKmmap(327680) fails, try to free up space memory in use=48376596752, virtual memory in use=102304729360
by Murthy, Gautham 12 Jul '18

12 Jul '18

Hello All, We had a crash reported on our MonetDB database, Below are the error messages. Can you share any insights on the below reported issue. There were no memory/cpu crunch during the crash, System had ample resource available. MonetDB Version - Jul2017-SP4 2018-07-03 06:33:40 ERR TSV_PROD_DB_A315293<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315293>: #GDKmmap(327680) fails, try to free up space memory in use=48376596752,virtual memory in use=102304729360<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/memory+in+use%3…> 2018-07-03 06:33:40 ERR TSV_PROD_DB_A315293<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315293>: #GDKmmap(327680) fails, try to free up space memory in use=48368938424,virtual memory in use=102295694776<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/memory+in+use%3…> 2018-07-03 06:33:40 ERR TSV_PROD_DB_A315293<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315293>: #GDKmmap(327680) fails, try to free up space memory in use=48367612864,virtual memory in use=102294369216<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/memory+in+use%3…> 2018-07-03 06:33:40 ERR TSV_PROD_DB_A315293<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315293>: #GDKmmap(327680) fails, try to free up space memory in use=48374211792,virtual memory in use=102300968144<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/memory+in+use%3…> 2018-07-03 06:33:47 ERR TSV_PROD_DB_A315293<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315293>: #GDKmmap(524288) fails, try to free up space memory in use=48312652864,virtual memory in use=103295521856<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/memory+in+use%3…> 2018-07-03 06:34:33 MSG merovingian315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: database 'TSV_PROD_DB_A' has crashed after start on 2018-07-02 04:52:12, attempting restart, up min/avg/max: 2h/6d/4w, crash average: 1.00 0.60 0.20 (14-8=6) 2018-07-03 06:34:38 ERR control315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: !monetdbd: an internal error has occurred 'unknown or impossible state: 4' 2018-07-03 06:34:40 ERR merovingian315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: client error: unknown or impossible state: 4 2018-07-03 06:34:40 ERR control315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: !monetdbd: an internal error has occurred 'unknown or impossible state: 4' 2018-07-03 06:34:41 ERR merovingian315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: client error: unknown or impossible state: 4 2018-07-03 06:34:41 ERR control315279<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/315279>: !monetdbd: an internal error has occurred 'unknown or impossible state: 4' What was running during the crash ? : Users were dropping, recreating tables and loading data. monetadmin@lnx1535 ~<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/monetadmin%40ln…>$ cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) monetadmin@lnx1535 ~<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/monetadmin%40ln…>$ free -g total used free shared buff/cache available Mem: 1007 199 419 1 388 804 Swap: 31 0 31 monetadmin@lnx1535 ~<https://monetdbsolutions.atlassian.net/wiki/display/SUPPORT/monetadmin%40ln…>$ cat /proc/cpuinfo|grep -i processor|wc -l 128 Thank You, Gautham

1 0