Server crashes with code 137

[peterzh]

I currently run a datajoint server on Docker (Windows 10 64bit). The database starts OK, and runs well most of the time. However occasionally when I'm running commands via MATLAB, the server crashes.

On MATLAB for example I wanted to delete some data entries for a session:

>> del(d.Session & 'session_date="2018-05-09"')

ABOUT TO DELETE:
       2 tuples from `d`.`session` (manual)
       2 tuples from `d`.`__session_chronometric` (computed)
       2 tuples from `d`.`__session_performance` (computed)
       3 tuples from `d`.`__session_psychometric` (computed)
    1100 tuples from `d`.`_trial` (imported)
    1100 tuples from `d`.`_trial__response` (imported)
    1100 tuples from `d`.`_trial__stim` (imported)
    1100 tuples from `d`.`_trial__timings` (imported)
    1100 tuples from `d`.`_trial__wheel` (imported)

Proceed to delete? (yes/no) > yes
Deleting from d.TrialWheel

 ** delete rolled back due to an error
Error using mym
Lost connection to MySQL server at 'reading initial communication packet', system error: 0

Error in dj.Connection/query (line 162)
                self.connId=mym('open', self.host, self.user, self.password);

Error in dj.Connection/cancelTransaction (line 194)
            self.query('ROLLBACK')

Error in dj.Relvar/del (line 111)
                        self.schema.conn.cancelTransaction

On the commandline for docker, I see the following error message:

...
db_1  | Version: '5.7.20'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
db_1  | 2018-05-09T10:02:18.939769Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.
db_1  | 2018-05-09T10:02:18.939818Z 0 [Note] Beginning of list of non-natively partitioned tables
db_1  | 2018-05-09T10:02:19.440568Z 0 [Note] End of list of non-natively partitioned tables
datajointserver_db_1 exited with code 137

Thanks
Peter

[ixcat]

Hello - thanks for the report and apologies we haven't been able to investigate further thus far.

We think we have been able to reproduce the issue as being due to the Docker runtime running out of memory due to the size of the mysql VM and will be investigating how to improve or mitigate the situation.

To verify the issue, if this happens, the system logs on the docker for windows VM/WSL host should have a clear message that the linux OOM killer terminates the mysql process. For Docker/Windows/WSL this can be done by using the 'wsl' utility to enter the docker VM and checking /var/log/syslog and dmesg (apologies, didn't note precise steps). I wasn't able to test on a Docker/Windows/HyperV setup but expect the same cause in those cases.

To adjust the docker for windows memory settings, please see the following: https://docs.docker.com/docker-for-windows/#resources

The issue covering the other case and discussing potential mitigation approaches is here: #31

will plan on closing this issue if you can confirm it is the same issue or will assume the same case and close after that one is completed.