Из проблемы памяти

Я запускаю Ubuntu 14.04LTS на Dell PowerEdge R730 с 32 ГБ RAM и GPU Nvidia K80.. У меня есть сценарий Python, который работает в течение долгого времени, но действительно просто делает набор относительно недолгих системных вызовов других программ (некоторые из которых используют CUDA экстенсивно в случае, если это имеет значение).. Кроме всеобъемлющего сценария Python, отдельные системные вызовы только выполняют в течение приблизительно 45 секунд часть, и сам сценарий Python ничего не "поддерживает" - это просто делает системные вызовы и выполняет итерации - не любое устройство хранения данных результатов и т.д.

Поскольку я слежу за прогоном программы и использованием памяти монитора с "вершиной", я вижу, что "свободная" память, о которой сообщают, понижается со временем.. Я понимаю, что это обычно не беспокойство из-за кэширования использоваться. В конечном счете, тем не менее, машина зависает и не отвечает всегда (т.е. никакое перемещение курсора мыши на консоли, никакой ответ от удаленных терминалов, и т.д.).. Когда это происходит, у меня есть к "жесткой" перезагрузке система, и вещи вернулись к нормальному, и я могу взять, где я кончил, пока она не зависает снова..

Другое интересное место - после достаточного количества перезагрузки-и-перезапусков программа наконец завершается.. Снова, после этого нет ничего из значения, работающего на системе, однако, системном мониторе гнома и вершине и отчет, почти полное использование памяти, и пытающийся выполнить другие (минимальные) команды часто "Уничтожается" ядром.. Проверяя системные журналы, это сообщает "из памяти", которая, кажется, указывает, что используемая память не является кэшем, но памятью, которая на самом деле "требуется". Вопрос - кто? Проверяя все утилиты памяти, которые люди упомянули на этом и других форумах, никакие процессы не утверждают, что использовали много памяти..

Я прочитал сообщения об утечках памяти ядра, и это - то, чего я хочу требовать, но это просто кажется маловероятным..

Вопрос: Как я могу определить то, что требует всей памяти? Я хотел бы смочь определить если в ядре или если его некоторый процесс то выполнение.

Поддержка Infomation:

uname-a:

Linux machinename 3.19.0-47-generic #53~14.04.1-Ubuntu SMP Mon Jan 18 16:09:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

lscpu:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               1200.351
BogoMIPS:              5993.09
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              10240K
NUMA node0 CPU(s):     0-7

Предшествующее Чтение и понимание: я прочитал тонну сообщений о понимании использования памяти Linux и создании отчетов.. Я понимаю, что, когда программы как главный отчет очень мало памяти, "свободной", это - не обязательно проблема, потому что большая часть "используемой" памяти кэшируется, и на самом деле наличие Вашей RAM, полной кэшируемого материала, хорошо.. Я полагаю, однако, что это не проблема, которую я вижу, потому что, если бы это был кэш, кажется, что программы смогли бы использовать его. То, что ядро вступает и уничтожает новые процессы и dmesg, сообщает, что система "из памяти", кажется, указывает, что память занимается в некэше путь, но об этом, кажется, не сообщают ни в каком инструменте анализа памяти, который я попробовал..

Обновление: На основе ответа ниже, я посмотрел на/proc/meminfo, когда дела начинали идти плохо, и в то время как я не знаю то, что все они означают, существуют некоторые, которые кажутся.. подозреваемый.. "DirectMap2M" кажется проблематичным путем и "VmallocChunk" также, хотя меньше...

> cat /proc/meminfo
MemTotal:       32828728 kB
MemFree:          166568 kB
MemAvailable:     100656 kB
Buffers:            6520 kB
Cached:            27416 kB
SwapCached:          300 kB
Active:            17904 kB
Inactive:          16076 kB
Active(anon):        360 kB
Inactive(anon):      212 kB
Active(file):      17544 kB
Inactive(file):    15864 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:      33452028 kB
SwapFree:       33317332 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:           484 kB
Mapped:            23276 kB
Shmem:               144 kB
Slab:             559236 kB
SReclaimable:      60016 kB
SUnreclaim:       499220 kB
KernelStack:        8864 kB
PageTables:        10132 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    49866392 kB
Committed_AS:    1143048 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      358064 kB
VmallocChunk:   34342563088 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:    32637928 kB
DirectMap2M:    18446744073709318144 kB
DirectMap1G:     3145728 kB

Update2 Просто выполнил вещи снова и имел cmd "свободное", получаются каждые 15 секунд.. Я наблюдал, что бесплатный столбец понизился, когда программа работала, пока это не достигло очень низкой стоимости (приблизительно 190 000) и когда это достигло того уровня, подвешенная программа, и все начало идти очень медленно.. Я ctrl-c'ed программа после того, как это зависло некоторое время и в конечном счете терминал, ответила и забрала меня к подсказке.. Однако "свободный" все еще сообщает о приблизительно 190 000 в бесплатном столбце, и даже общее использование (просто вводящий в терминале) является очень медленным - никакая программа в настоящее время не работает. Смотря/proc/meminfo, поле "DirectMap2M" является сумасшедшим снова.. Я действительно получал содержание/proc/meminfo регулярно также и могу смотреть на как вещи, изменяемые со временем.

К вашему сведению: вот вывод "бесплатной" команды, когда вещи зависли:

             total       used       free     shared    buffers     cached
Mem:      32828728   32636496     192232          4       7368      22972
-/+ buffers/cache:   32606156     222572
Swap:     33452028     205160   33246868

Вот график значения DirectMap2M от/proc/meminfo со временем. После самой правой точки в графике это перешло к смешному огромному значению - похож на потерю значимости.. Определенный поиск с помощью Google найденных других с потерей значимости выходит здесь.. Я не знаю то, что DirectMap2M представляет хотя..

enter image description here

Обновление 3: Все еще борьба с этим.. Некоторая недавно обнаруженная информация для добавления:

У нас есть он вниз так, как мы могли к этому:

#include "cublas_v2.h"
int main() {
  cublasHandle_t handle;
  cublasCreate(&handle);
  cublasDestroy(handle);
  return 0;
}

Каждый раз, когда мы выполняем это на Dell T630 с Nvidia K40, мы видим, что DirectMap2M понижается. Если мы делаем это достаточно, мы видим проблему потери значимости, и машина должна быть перезагружена.. У нас также есть Dell R730 с Nvidia K80, которая показывает то же поведение..

Интересно, у нас есть еще один компьютер (ноутбук с NVidia GTX980M) выполнение того же ядра Ubuntu, и мы не наблюдаем это поведение, когда мы выполняем вышеупомянутое..

0
задан 18 February 2016 в 21:27

2 ответа

Хорошее место для запуска состоит в том, чтобы отследить статистику в/proc/meminfo, это имеет значительную сумму детали об использовании глобальной памяти. Я предлагаю получить вывод от/proc/meminfo периодически (говорите каждые 30 минут или так), и можно затем исследовать это для наблюдения, где рост выделения памяти происходит. От этого у Вас будет по крайней мере некоторая идея о том, где посмотреть затем.

1
ответ дан 29 September 2019 в 12:31

Мы испытали ту же проблему с заданиями CUDA, работающими на машинах Debian Jessie с GTX 970 и GTX 980Ti GPU. Ваш тестовый сценарий также заставил наши машины исчерпывать память в течение минут.

то, Что в конечном счете зафиксировало это раздражающее поведение для нас, должно было установить актуальнейший бета драйвер от Nvidia - версия 364.12 во время записи. Это, кажется, независимо от ядра Linux (мы попробовали несколько), и версия CUDA (мы также попробовали несколько). Это, кажется, было ошибкой в самом драйвере Nvidia, который был починен только недавно.

1
ответ дан 29 September 2019 в 12:31

Другие вопросы по тегам:

Похожие вопросы: