Машина: Dell r815, CentOS 5.4, 256 ГБ ОЗУ, 4 x 12 ядер.
У нас есть приложение с файлом размером 275 ГБ. Он выполняет сортировку на месте по 20 ГБ данных за раз, то есть меняет местами биты и заменяет их в том же файле. Все работает нормально.
Существует последний проход, который затем читает весь файл и выполняет сортировку слиянием на разных блоках по 20 ГБ и выводит их в совершенно новый файл.
Этот процесс ВИДЕТЬ, что какое-то время работает нормально, и в итоге на диск сбрасывается около 50 ГБ. Через какое-то время ВСЯ машина начинает нервничать.
Простые команды вроде ps -ef, ls -al, зависают на долгое время и отображаются как загружающие 100% ЦП (это всего лишь одно ядро).
Глядя на статистику памяти на top, Я вижу, что он использует около 120 ГБ ОЗУ (то есть 128 ГБ свободно) и имеет 120 ГБ в разделе «кэширование».
Кто-нибудь видел такое поведение раньше? Тот же процесс отлично работает на машине с 64 ГБ памяти - поэтому я почему-то думаю, что это связано с монтированием оперативной памяти, которая у меня есть на машине.
(пока мы говорим, я запускаю тест на этой машине со всеми, кроме 64 ГБ - чтобы исключить проблему с оборудованием).
Возможно, мне не хватает некоторых параметров vm в /etc/sysctrl.conf?
Спасибо!
Таким образом, это оказалось ошибкой ядра в 64-битной Centos 5.4 И 64-битной Fedora 14. После того, как я установил Centos 5.5, проблема исчезла.
Извините, у меня нет лучшего ответа для всех ...
Ваш вопрос напомнил мне кое-что, что я недавно прочитал:
http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
Это касается того, как архитектуры NUMA (например, в 48-ядерной системе AMD) влияют на распределение и подкачку памяти. Я не знаю, с чем вы столкнулись, но это звучало достаточно похоже, и его стоит прочитать.
Даже если это не ответ, чтение будет увлекательным.
Вы можете попробовать добавить строку в /etc/sysctl.conf, чтобы указать, что своп должен использоваться только в случае крайней необходимости.
swappiness = 0
Возможно, вы уже знаете, что этот файл определяет глобальные параметры, поэтому необходимо учитывать влияние этого изменения на остальные приложения, работающие в среде.
Где твое временное пространство. Часто это происходит на tempfs. Tempfs извлекает это пространство из памяти, зарезервированной с помощью пространства подкачки, поэтому, если в конечном итоге в tempfs будет слишком много материала, он вызовет ввод-вывод подкачки.
Учитывая размер данных, которые вы объединяете, я ожидал бы, что при окончательном слиянии будет происходить замена.
Может помочь распространение хранилища подкачки на несколько дисков.
Хотя вы можете не использовать свопинг, вы все равно можете быть привязаны к вводу-выводу. Информация ls предполагает это.
Я бы посмотрел на результат dstat -df чтобы показать статистику диска, или dstat -af (да, это будет баджиллион столбцов шириной; это то, что происходит, когда у вас 48 ядер и показывается загрузка ЦП на всех из них), если вы хотите увидеть все это.
Я был бы удивлен, если бы все ЦП были заняты (сортировка слиянием не является задачей, требующей интенсивного использования ЦП), но вы ничего не говорите о своей системе ввода-вывода. Если у вас мало дисков и куча файлов, вы можете перебрать диск, выполняя поиск каждого файла, чтобы сохранить сортировку слияния.