Taking a look at system metrics it looks like the h1nds1 received went under a some short periods of load that exhausted the memory of the system. See the ndscope plot. The two time axis markers are at daqd/nds crashes.
Reading the system dmesg also points out an out of memory condition. Here is a sample from the dmesg output
Attached images show memory available (percent) as reported by h1nds1 around the times of the morning and afternoon crashes. The vertical lines going to 90% denote the time daqd is restarted. These agree with the generation of a new daqd log file. The times are (local PST):
10:33
10:34
10:49
14:29
14:30
In both cases the available memory started trending to zero about 13 minutes before the eventual crash. As reported in alog 54406 the 10:49 crash showed no error in the daqd logfile, but dmesg shows a segfault. The afternoon crash gives a dmesg memory error.
The pair or restarts following the memory depletion have the same sequence:
First restart: Retransmissions then packet skip
Second restart: Invalid broadcast received
Images attached to this comment
david.barker@LIGO.ORG - 16:52, Friday 10 January 2020 (54420)
When the available memory is being depleted, it happens in steps. The width of the steps are roughly 30 seconds, suggesting data requests are being made with that periodicity.
Taking a look at system metrics it looks like the h1nds1 received went under a some short periods of load that exhausted the memory of the system. See the ndscope plot. The two time axis markers are at daqd/nds crashes.
Reading the system dmesg also points out an out of memory condition. Here is a sample from the dmesg output
If this is a continued issue then we should switch the control room to reference h1nds2 which is a newer system with more resources.
Attached images show memory available (percent) as reported by h1nds1 around the times of the morning and afternoon crashes. The vertical lines going to 90% denote the time daqd is restarted. These agree with the generation of a new daqd log file. The times are (local PST):
In both cases the available memory started trending to zero about 13 minutes before the eventual crash. As reported in alog 54406 the 10:49 crash showed no error in the daqd logfile, but dmesg shows a segfault. The afternoon crash gives a dmesg memory error.
The pair or restarts following the memory depletion have the same sequence:
First restart: Retransmissions then packet skip
Second restart: Invalid broadcast received
When the available memory is being depleted, it happens in steps. The width of the steps are roughly 30 seconds, suggesting data requests are being made with that periodicity.