Я обновился с IBM LSF Suite for Enterprise 10.2.0.10 до версии 10.2.0.12, и теперь только на одном из наших кластерных серверов GPU (1 из 8) я не могу заставить службу LIM продолжать работать. Он продолжает падать с ошибкой сегментации:
lim[42062]: segfault at 0 ip 00007f63476c07f7 sp 00007f6345218958 ошибка 4 в libc-2.27.so[7f6347607000+1e7000]
Сбой сегмента процесса обычно происходит после того, как задание было отправлено на сервер или завершено там. Если на сервере есть работающее задание, LIM и его дочерние процессы завершатся сбоем примерно через минуту после запуска.
Поскольку мы используем «Академическую инициативу» IBM на кафедре биоинформатики в университете, у нас нет доступа к поддержке или пакетам исправлений, кроме основных выпусков.
nvidia-smi показывает следующее, в настоящее время:
+--------------------------------------------- ----------------------------+
| NVIDIA-SMI 470.82.01 Версия драйвера: 470.82.01 Версия CUDA: 11.4 |
|-------------------------------+---------------- -----+----------------------+
| Имя GPU Persistence-M| Bus-Id Disp.A | Летучий некорр. ЕСК |
| Мощность вентилятора Temp Perf:Использование/Ограничение| Использование памяти | GPU-Util Compute M. |
| | | МИГ М. |
|===============================+================= =====+======================|
| 0 Quadro RTX 8000 включен | 00000000:1A:00.0 Выкл | Выкл. |
| 33% 40C P8 25 Вт / 260 Вт | 3968 МБ / 48601 МБ | 0% E. Процесс |
| | | Н/Д |
+---------------------------------------------+---------------- -----+----------------------+
| 1 Quadro RTX 8000 включен | 00000000:3E:00.0 Выкл | Выкл. |
| 33% 25C P8 12 Вт / 260 Вт | 1 МБ / 48601 МБ | 0% По умолчанию |
| | | Н/Д |
+---------------------------------------------+---------------- -----+----------------------+
| 2 Quadro RTX 8000 включен | 00000000:89:00.0 Выкл | Выкл. |
| 33% 24C P8 21 Вт / 260 Вт | 1 МБ / 48601 МБ | 0% По умолчанию |
| | | Н/Д |
+---------------------------------------------+---------------- -----+----------------------+
| 3 Quadro RTX 8000 включен | 00000000:B1:00.0 Выкл | Выкл. |
| 33% 24C P8 15 Вт / 260 Вт | 1 МБ / 48601 МБ | 0% По умолчанию |
| | | Н/Д |
+---------------------------------------------+---------------- -----+----------------------+
Мне удалось получить дамп ядра ошибки сегментации и запустить его. gdb. Вот след некоторых дальнейших проверок:
(гдб) бт
#0 __strcat_sse2_unaligned() в ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:298
#1 0x00000000004efa5c в getNvidiaGpu (index=-1408930708, dev=0x7f7dac056810, allDevices=0xbdd9, errorGPU=0x0, errorCount=0, warningGPU=0x7f7dac011730, warningCnt=2) на lim.gpu.c:580
#2 0x00000000004f074b в getGpuReportFullThreadFunc() на lim.gpu.c:858
#3 0x00000000004f11ad в collectGpuInfoThread (arg=0x7f7dac056c6d) на lim.gpu.c:949
#4 0x00007f7db92756db в start_thread (arg=0x7f7db5ec8700) в pthread_create.c:463
#5 0x00007f7db83d771f в клоне () в ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Вот сборка, в которой он терпит неудачу:
=> 0x00007f7db836f7f7 <+1255>: movdqu (%rsi),%xmm1
И здесь мы видим, что адрес памяти rsi равен 0, или указатель NULL
рси 0x0 0
#0 __strcat_sse2_unaligned() в ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:298
Нет местных жителей.
#1 0x00000000004efa5c в getNvidiaGpu (index=-1408930708, dev=0x7f7dac056810, allDevices=0xbdd9, errorGPU=0x0, errorCount=0, warningGPU=0x7f7dac011730, warningCnt=2) на lim.gpu.c:580
fname = 0x7d6878 "getNvidiaGpu"
modelname = "QuadroRTX8000", '\000' <повторяется 242 раза>
устройство = 0x7f7db79b3e58
память = {всего = 50962169856, свободно = 42197254144, использовано = 8764915712}
pState = NVML_PSTATE_2
использование = {gpu = 100, память = 49}
ComputeMode = NVML_COMPUTEMODE_DEFAULT
температура = 83
vsbecc = 0
vdbecc = 0
мощность = 249652
я = 0
j = 0
#2 0x00000000004f074b в getGpuReportFullThreadFunc() на lim.gpu.c:858
Разработчик = 0x7f7dac056810
fname = "getGpuReportFullThreadFunc"
дГлобал = 0x7f7dac001c70
ошибка GPU = 0x0
предупреждениеGPU = 0x7f7dac011730
все устройства = 0x7f7dac00a850
рет = 2886036588
рет1 = 2886036588
ver = {major = 2885721120, minor = 32637, patch = 4294967168, build = 0x11 <ошибка: невозможно получить доступ к памяти по адресу 0x11>}
rsmi_cnt = 0
nvml_cnt = 4
majorTmp = "11\000\000\000\000\000"
compMajorV = <оптимизировано>
compMinorV = <оптимизировано>
majorVer = <оптимизировано>
майор V = 470
минор V = 57
количество ошибок = 0
предупреждениеCnt = 2
я = 0
gpu_lib = -1408931824
nvmlOpened = 1
#3 0x00000000004f11ad в collectGpuInfoThread (arg=0x7f7dac056c6d) на lim.gpu.c:949
fname = "собратьGpuInfoThread"
gpuinfo = 0x7f7dac001c70
gpuinfoError = 0
выборочный интервал = 5
#4 0x00007f7db92756db в start_thread (arg=0x7f7db5ec8700) в pthread_create.c:463
пд = 0x7f7db5ec8700
now = <оптимизировано>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140177899816704, -4327163297919163674, 140177899814848, 0, 0, 10252544, 4398249031032873702, 4398224247775797990}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {предыдущая = 0x0, очистка = 0x0, тип отмены = 0}}}
not_first_call = <оптимизировано>
#5 0x00007f7db83d771f в клоне () в ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
При всем при этом у нас есть еще один сервер с точно такими же характеристиками, на котором этой проблемы нет. Версии NVIDIA CUDA и драйвера также одинаковы, они работают с той же версией Ubuntu, версия 18.04.06 LTS.
Установка LSF использует общую конфигурацию через NFS, что означает, что каждый сервер обращается к одним и тем же файлам конфигурации и сценариям.
Единственные различия, которые я вижу между другими серверами и сервером с проблемой, заключаются в параметре команды, используемом для запуска LIM:
На всех остальных серверах:
корень 53635 1,8 0,0 277728 18844 ? S<sl Feb07 472:40 /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lim -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel
корень 53639 0,0 0,0 18652 5976 ? S<s Feb07 0:11 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/melim
корень 53645 0.0 0.0 4681288 14400 ? S<l Фев07 6:26 | \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lsfbeat -c /opt/ibm/lsfsuite/lsf/conf/lsfbeats/lsfbeat.yml
корень 53640 0.0 0.0 21268 9136 ? S Feb07 7:56 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pim -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel
корень 53641 0,0 0,0 39576 9604 ? Sl Feb07 0:42 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pem
На одном с ошибкой сегментации:
корень 44902 1,8 0,0 272472 16680 ? D<sl 12:17 0:00 /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lim
корень 44919 4,4 0,0 18656 6500 ? S<s 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/melim
корень 44924 2,2 0,0 468764 11280 ? С<л 12:17 0:00 | \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lsfbeat -c /opt/ibm/lsfsuite/lsf/conf/lsfbeats/lsfbeat.yml
корень 44920 5,6 0,0 19276 7364 ? С 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pim
корень 44921 4,6 0,0 39576 10288 ? Сл 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pem
Я попытался перезапустить службы, используя бктрлд как на мастере, так и на сервере, в дополнение к использованию lsfd.service единица... даже запуск лим обслуживание вручную с помощью -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel параметры. Все производят ошибку сегментации.
Кто-нибудь знает, в чем проблема или как ее исправить? Я схожу с ума здесь.
Большое спасибо, что нашли время, чтобы прочитать это и оставить свой отзыв!
