Linux з 256 Гб пам’яті / 48 ядер - Машина починає молотити / задихатися, коли залишилося багато пам'яті

Машина: 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?

Дякую!

Ваше запитання нагадало мені те, що я нещодавно прочитав:

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

Тут йдеться про те, як архітектури NUMA (як, наприклад, ви знайдете в, наприклад, 48-ядерній системі AMD) впливають на розподіл пам'яті та їх заміну. Я не знаю, чи це ти наштовхуєшся, але це звучало достатньо схоже, що, можливо, варто прочитати.

Навіть якщо це не відповідь, яку вона дає для захоплюючого читання.

Отже, це виявилося помилкою ядра в 64-бітній Centos 5.4 AND 64bit Fedora 14. Після того, як я встановив Centos 5.5, проблема вирішилася.

Вибачте, я не маю кращої відповіді для всіх ...

Ви можете спробувати додати рядок до /etc/sysctl.conf, щоб вказати, що своп використовуватиметься лише при крайній необхідності.

свопіння = 0

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

Де ваш тимчасовий простір. Часто це на темпфах. Tempfs витягує це простір із резервної копії пам’яті за допомогою місця підкачки, тому, якщо ви виявите занадто багато матеріалів у tempfs, це запустить swap I / O.

Враховуючи розмір даних, які ви об'єднуєте, я очікував би простоти, коли ви потрапите в остаточне злиття.

Поширення пам’яті своп на декілька дисків може допомогти.

Незважаючи на те, що ви можете не отримувати своп, ви все ще можете бути пов'язаними вводу / виводу. Про це свідчить ls info.

Я хотів би подивитися на висновок, dstat -dfщоб показати статистику диска, або dstat -af(так, це буде байліоновий стовпчик завширшки; це те, що відбувається, коли у вас є 48 ядер і показуєте використання процесора на всіх), якщо ви хочете все це побачити.

Я був би здивований, якби всі процесори були зайняті (сортування злиття не є інтенсивним процесором), але ви нічого не говорите про вашу систему вводу / виводу. Якщо у вас є кілька дисків і купа файлів, ви можете обмолочувати диск, прагнучи до кожного файлу, щоб зберегти сортування злиття.