Машина: 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 ядер и вы показываете загрузку ЦП на всех из них), если вы хотите увидеть все это.Я был бы удивлен, если бы все процессоры были заняты (сортировка слиянием не является трудоемкой задачей ЦП), но вы ничего не говорите о своей системе ввода-вывода. Если у вас мало дисков и куча файлов, вы можете перебирать диск, выполняя поиск каждого файла, чтобы поддерживать сортировку слиянием.
источник