[MCOL-465] InfiniDB goes down after every alter on tables Created: 2016-12-14  Updated: 2016-12-14  Resolved: 2016-12-14

Status: Closed
Project: MariaDB ColumnStore
Component/s: ExeMgr
Affects Version/s: None
Fix Version/s: Icebox

Type: Bug Priority: Critical
Reporter: Abhinav santi Assignee: Daniel Lee (Inactive)
Resolution: Won't Do Votes: 0
Labels: None


 Description   

Hi,
we use infinidb v 4.6 with 3 cluster nodes, DDL/DML/PRIMPROC gets dropped for every alter statement that runs on the database.
And also when the database server uses more than 80% swap memory, ExeMgr fails to restart and stays in dead state for ever.
Since there is hardly any information online as a last resort I'm contacting you.
Thanks in advance.

ExeMgr[8080]: 12.976744 |0|0|0| C 16 CAL0044: FATAL ERROR: ExeMgr has allocated too much memory! Percent allocation-96, allowed-95. ExeMgr is restarting.
Dec 13 17:10:14 ip-X-X-X-X ProcessMonitor[1815]: 14.384955 |0|0|0| C 18 CAL0000: *****Calpont Process Restarting: ExeMgr, old PID = 8080
ip-X-X-X-X joblist[2112]: 14.402120 |0|0|0| C 05 CAL0000: clientrotator.cpp @ 318 Could not get a ExeMgr connection.
ip-X-X-X-X joblist[2112]: 14.402171 |0|0|0| C 05 CAL0000: clientrotator.cpp @ 146 clientrotator.cpp: Could not get a connection to a ExeMgr

 Comments   
Comment by David Thompson (Inactive) [ 2016-12-14 ]

Hi Abhinav, can you provide some details on how to reproduce this? What alter statement and what table ddl / size of table etc? You can see from the logs that the system is attempting to stabilize by restarting the server under the assumption a run away query is consuming memory.

Also please confirm your topology and columnstore version.

Comment by David Thompson (Inactive) [ 2016-12-14 ]

I see you specified this is for InfiniDB. This jira project is for ColumnStore which is the MariaDB port. MariaDB does offer paid support for InfiniDB.

As mentioned the issue is because you are running out of memory as a cause of whatever action you are doing.

Generated at Thu Feb 08 02:21:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.