Welcome to the forum @carterwheat.
Please can you provide additional details:
free -g
sudo dmesg | grep -i oom
Hi, Thanks for helping.
The command I’ve been using to check running procs:
ps -ax | grep cryosparc
Master and worker are on the same, single workstation.
bell@ub22-04:~$ free -g
total used free shared buff/cache available
Mem: 187 4 15 0 167 181
Swap: 1 0 1
bell@ub22-04:~$ sudo dmesg | grep -i oom
bell@ub22-04:~$
The second command doesn’t seem to give me any output.
Hi @wtempel ,
Update: I have been using a script to clear the cache every hour and it seems to have gotten around the " … .sock refused connection" issue. However I am still having issues, now during during 2D-classification:
`Traceback (most recent call last):
File “/home/bell/programs/cryosparc_worker/cryosparc_compute/jobs/runcommon.py”, line 2192, in run_with_except_hook
run_old(*args, **kw)
File “cryosparc_master/cryosparc_compute/gpu/gpucore.py”, line 134, in cryosparc_master.cryosparc_compute.gpu.gpucore.GPUThread.run
File “cryosparc_master/cryosparc_compute/gpu/gpucore.py”, line 135, in cryosparc_master.cryosparc_compute.gpu.gpucore.GPUThread.run
File “cryosparc_master/cryosparc_compute/jobs/class2D/newrun.py”, line 632, in cryosparc_master.cryosparc_compute.jobs.class2D.newrun.class2D_engine_run.work
File “cryosparc_master/cryosparc_compute/engine/newengine.py”, line 1619, in cryosparc_master.cryosparc_compute.engine.newengine.EngineThread.find_best_pose_shift_class
File “<array_function internals>”, line 5, in unravel_index
ValueError: index -1089082060 is out of bounds for array with size 336
We have ran the same 2D class job parameters (not cloned) and get this error at different points during iterations.
Along with that error, we also get an unresponsive heartbeat termination for some of the same 2D class jobs as well. Any advice would be greatly appreciated.
Thanks!
Thanks for the update @carterwheat.
What cache is being cleared and what is the command being used?
Regarding the new errors you observed:
cat /sys/kernel/mm/transparent_hugepage/enabled
sudo dmesg -T | grep -i error
eval $(cryosparcm env)
host $CRYOSPARC_MASTER_HOSTNAME
time curl ${CRYOSPARC_MASTER_HOSTNAME}:$CRYOSPARC_COMMAND_CORE_PORT
Hi @wtempel ,
I am running v4.4.1.
In a fresh shell:
bell@ub22-04:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
bell@ub22-04:~$ sudo dmesg -T | grep -i error
(no output)
bell@ub22-04:~$ eval $(cryosparcm env)
(no output)
bell@ub22-04:~$ host $CRYOSPARC_MASTER_HOSTNAME
ub22-04 has address 10.69.108.35
bell@ub22-04:~$ time curl ${CRYOSPARC_MASTER_HOSTNAME}:
$CRYOSPARC_COMMAND_CORE_PORT
Hello World from cryosparc command core.
real 0m0.023s
user 0m0.005s
sys 0m0.005s
not sure if this is the correct way to do so, but the command I’ve been clearing the cache with:
sync; echo 1 > /proc/sys/vm/drop_caches
Regarding
you may want to check for corrupt particles, as suggested in 2D Classification: ValueError: index is out of bounds for array - #23 by hgxy15. You may use the Check for Corrupt Particles job type and enable Check for NaN values. If the test passes and you enabled Cache particle images on SSD for classification, particles may have been corrupted in the cache.
Thanks for your reply @wtempel
I did run a check particles job (with NaN option) on the same particle stack and no corruption was detected. We have been turning off SSD caching as well for every job applicable.
If it helps, 2D classification will run fine with a fraction of the particles (about 1 million), but the full dataset (about 13 million) results in the issues aforementioned.
Interesting. I wonder if each 1M or so partition of the 13M set would succeed individually, or if there were at least one partition that would also fail. Have you tried that?
Hi @wtempel ,
I tried splitting the particle stack into smaller groups to run 2D classification individually, but unfortunately we were met with buffering of the cryosparc session. I assigned 3 2D class jobs (2.5 M particles each), each with 1 GPU and ultimately received the sock connection error:
cryosparcm status
----------------------------------------------------------------------------
CryoSPARC System master node installed at
/home/bell/programs/cryosparc_master
Current cryoSPARC version: v4.4.1
----------------------------------------------------------------------------
CryoSPARC process status:
unix:///tmp/cryosparc-supervisor-2bd2e4ee751475e1d6470e25365ba9c5.sock refused connection
----------------------------------------------------------------------------
So it seems I have not fully addressed this issue quite yet. Any suggestions on what I can try next?
Thanks again!
What are the outputs of these commands when the sock file refuses connection?
free -g
date
ps -eo user,pid,ppid,start,rsz,vsz,cmd | grep -e cryosparc_ -e mongo | grep -v grep
date
ls -l /tmp/cryosparc*.sock /tmp/mongodb-*.sock
Thanks for your reply @wtempel
Here is the requested output
bell@ub22-04:~/useful-scripts$ date
Mon Apr 15 05:07:15 PM EDT 2024
bell@ub22-04:~/useful-scripts$ ps -eo user,pid,ppid,start,rsz,vsz,cmd | grep -e cryosparc_ -e mongo | grep -v grep
bell@ub22-04:~/useful-scripts$ date
Mon Apr 15 05:07:50 PM EDT 2024
bell@ub22-04:~/useful-scripts$ ls -l /tmp/cryosparc*.sock /tmp/mongodb-*.sock
srwx------ 1 bell bell 0 Apr 15 14:17 /tmp/cryosparc-supervisor-2bd2e4ee751475e1d6470e25365ba9c5.sock
srwx------ 1 bell bell 0 Apr 15 14:17 /tmp/mongodb-39001.sock
bell@ub22-04:~/useful-scripts$
The empty ps -e output suggests that CryoSPARC-related processes have exited, but socket files where (unexpectedly) left behind.
What is the output of the command
cryosparcm log supervisord | tail -n 20
?
@wtempel here is the output.
this is while cryosparc is buffering/sock connection issues are happening
bell@ub22-04:~$ cryosparcm log supervisord | tail -n 20
2024-04-15 10:11:08,026 INFO spawned: 'app' with pid 62991
2024-04-15 10:11:09,695 INFO success: app entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 10:11:09,855 INFO spawned: 'app_api' with pid 63009
2024-04-15 10:11:11,206 INFO success: app_api entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 14:17:02,685 INFO RPC interface 'supervisor' initialized
2024-04-15 14:17:02,685 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-04-15 14:17:02,687 INFO daemonizing the supervisord process
2024-04-15 14:17:02,687 INFO supervisord started with pid 69353
2024-04-15 14:17:07,480 INFO spawned: 'database' with pid 69467
2024-04-15 14:17:09,355 INFO success: database entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 14:17:11,321 INFO spawned: 'command_core' with pid 69578
2024-04-15 14:17:17,012 INFO success: command_core entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2024-04-15 14:17:17,773 INFO spawned: 'command_vis' with pid 69611
2024-04-15 14:17:18,775 INFO success: command_vis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 14:17:18,923 INFO spawned: 'command_rtp' with pid 69639
2024-04-15 14:17:19,924 INFO success: command_rtp entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 14:17:23,709 INFO spawned: 'app' with pid 69696
2024-04-15 14:17:25,379 INFO success: app entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-15 14:17:25,539 INFO spawned: 'app_api' with pid 69714
2024-04-15 14:17:26,827 INFO success: app_api entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Thanks for posting the supervisord log.
Please can you post the outputs of these commands
ps 69578 69467 69578
last reboot | head -n 3
dmesg -T | grep -i oom
dmesg -T | grep -e 69353 -e 69578
bell@ub22-04:~$ ps 69578 69467 69578
PID TTY STAT TIME COMMAND
bell@ub22-04:~$ last reboot | head -n 3
reboot system boot 6.2.0-39-generic Tue Apr 9 09:30 still running
reboot system boot 6.2.0-39-generic Sun Apr 7 11:27 still running
reboot system boot 6.2.0-39-generic Wed Mar 20 13:00 - 11:25 (17+22:24)
bell@ub22-04:~$ sudo dmesg -T | grep -i oom
bell@ub22-04:~$ sudo dmesg -T | grep -e 69353 -e 69578
bell@ub22-04:~$
Please can you confirm with the command
uptime -s
@carterwheat Unfortunately, I was not able to confirm the (only) hypothesis I had based on your problem description
and the commands’ outputs that you so patiently provided.
The hypothesis went like this:
TERM signal would have allowed for the cleanup of the
file)The kernel “OOM killer” seemed to me a good candidate for part 2., but there appear to be no supporting log records. Please let us know if you have any additional information that would point to an alternative cause, such as if the CryoSPARC processes are running inside a container or are subject to some cluster workload manager.
@wtempel Thanks for all of your help. I will keep you updated if anything else comes up that may point us in the right direction.
-Carter
