Linux с 256 ГБ памяти mem / 48 Core - машина начинает биться / захлебываться с оставшимися тоннами памяти

Машина: Dell r815, CentOS 5.4, 256 ГБ оперативной памяти, 4 х 12 ядер.

У нас есть приложение, которое имеет файл 275 ГБ. Он выполняет сортировку на месте по 20 ГБ данных за раз, то есть обменивает биты и заменяет их в одном и том же файле. Это все отлично работает.

Существует последний проход, который затем считывает весь файл и выполняет сортировку слиянием на разных порциях по 20 ГБ и выводит их в новый файл.

Этот процесс, кажется, работает некоторое время нормально, и в итоге он сбрасывает около 50 ГБ на диск. Спустя какое-то время ВСЯ машина начинает беситься.

Простые команды, такие как ps -ef, ls -alзависают в течение долгого времени и обнаруживают, что они занимают 100% ЦП (что составляет всего одно ядро).

Глядя на статистику памяти top, я вижу, что она использует около 120 ГБ ОЗУ (так что 128 ГБ свободно) и имеет 120 ГБ в разделе «кэширование».

Кто-нибудь видел такое поведение раньше? Тот же процесс прекрасно работает на машине с 64 ГБ памяти - так или иначе, я думаю, что это связано с подключением оперативной памяти, установленной в машине.

(как мы говорим, я запускаю тест на этой машине со всеми, кроме 64 ГБ - чтобы исключить аппаратную проблему).

Возможно, я пропускаю некоторые параметры VM /etc/sysctrl.conf?

Благодарность!

Ваш вопрос напомнил мне кое-что, что я недавно прочитал:

http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

Это касается того, как архитектуры NUMA (как, например, в 48-ядерной системе AMD) влияют на распределение памяти и перестановку. Я не знаю, с чем ты сталкиваешься, но это звучит достаточно похоже, чтобы это стоило прочитать.

Даже если это не ответ, это делает для увлекательного чтения.

Так что это оказалось ошибкой ядра в 64-битной Centos 5.4 И 64-битной Fedora 14. После того, как я установил Centos 5.5, проблема исчезла.

Извините, у меня нет лучшего ответа для всех ...

Вы можете попробовать добавить строку в /etc/sysctl.conf, чтобы указать, что подкачка должна использоваться только тогда, когда это абсолютно необходимо.

swappiness = 0

Возможно, вы уже знаете, что этот файл определяет глобальные параметры, поэтому необходимо учитывать влияние, которое это изменение окажет на остальные приложения, работающие в среде.

Где ваше временное пространство. Часто это на tempfs. Tempfs извлекает это пространство из памяти, резервной копии под пространство подкачки, поэтому, если у вас слишком много вещей в tempfs, это вызовет операции ввода-вывода подкачки.

Принимая во внимание размер данных, которые вы объединяете, я ожидаю перестановки, когда вы достигнете окончательного слияния.

Распределение хранилища подкачки по нескольким дискам может помочь.

Хотя вы, возможно, и не пользуетесь свопом, вы все равно будете связаны с вводом / выводом. Информация ls подсказывает это.

Я бы посмотрел на вывод, dstat -dfчтобы показать статистику диска, или dstat -af(да, это будет столбец шириной в баджиллион; это то, что происходит, когда у вас 48 ядер и вы показываете загрузку ЦП на всех из них), если вы хотите увидеть все это.

Я был бы удивлен, если бы все процессоры были заняты (сортировка слиянием не является трудоемкой задачей ЦП), но вы ничего не говорите о своей системе ввода-вывода. Если у вас мало дисков и куча файлов, вы можете перебирать диск, выполняя поиск каждого файла, чтобы поддерживать сортировку слиянием.