-
Notifications
You must be signed in to change notification settings - Fork 9
Python tools killed on the CTP7 with the address table for 12 OH's #41
Comments
Can you try the following:
The from the DAQ machine try to call |
If there's no issue when using the LMDB then this means we need to either:
We cannot increase the memory of the card. |
So, I tried to revert the address table, pickle file and the LMDB to the 4 OH's case. In that case, everything works as expected : python tools on the CTP7 are not killed and the chamber can be configured from the DAQ machine with the When coming back to the 12 OH's case, the issue is back. The python tools on the CTP7 are killed, but the I'll investigate the memory limits more carefully, but here are a few informations :
I think it is possible to reduce the pickle file size which is sent to the CTP7, but that would require to create a lightened Anyway, I'll try to understand what is the limit on the node number/pickle file size on the CTP7. |
The reported size of the Reducing the size of the `Node´ class seems a waste of time and would lead to the maintenance of two address tables. It would be better to move to RPC modules. See this issue for following up. |
I guess we want this eventually https://lmdb.readthedocs.io/en/release/ |
Instead of packaging an external Python package for the CTP7 and redeveloping the register parsing code, I would more simply write a small Python wrapper ( |
When trying to launch the
gbt.py
tool on the CTP7 with the address table for 12 OH's in order to perform a phase scan, the process is killed.Brief summary of issue
During the tests of the new CTP7 release (version 3.7.0) with 12 OH's, the python tools on the CTP7 stopped working. Some of the tools can be used from the DAQ machine, but others, such as
gbt.py
, must currently must be called from the CTP7.Each tool using the address table is killed because an out-of-memory issue during the pickle file loading :
reg_utils/python/reg_interface/common/reg_xml_parser.py
Lines 106 to 113 in 7b9cf05
The precise error is the following :
Types of issue
Expected Behavior
I expected the
gbt.py
tool to perform a phase scan without any error.Current Behavior
The
gbt.py
is currently killed.Steps to Reproduce (for bugs)
ssh gemuser@eagle63
gbt.py 0 0 v3b-phase-scan /mnt/persistent/gemdaq/gbt/OHv3b/20180314/GBTX_OHv3b_GBT_0__2018-03-14_FINAL.txt
Possible Solution (for bugs)
Enabling the GC did not help. The
gbt.py
tools could be refactored to run from the DAQ machine.Your Environment
rpm -qa
output. No mention of version in the/mnt/persistent/gemdaq/python/reg_interface/
files. TheparseXML()
function is the same as in the current repository./bin/sh
Default environment :
The text was updated successfully, but these errors were encountered: