Я делю сервер с HAL. На сервере 32 ГБ памяти.
Я редко использую более 1 ГБ памяти, а если и использую, то на несколько минут за раз, и я не возражаю отправлять такие задания на задний план.
HAL читает / записывает большие файлы (например, используя gunzip). Это может занять до 100% объем памяти CPU, с перебоями, часами. Обычно это делается в одночасье, но при запуске будут выполняться даже простые команды, такие как cd взять 30 секунд, открытие emacs может занять несколько минут.
Я хотел бы иметь возможность зарезервировать 1 ГБ для использования процессами, которые используют << 1 ГБ (например, текстовый редактор). Я также хотел бы держаться подальше от HAL и не вижу причин, по которым это должно быть проблемой.
HAL говорит, что система очередей (например, PBS) не может использоваться для установки низкого приоритета на чтение / запись, например чтобы всегда оставался доступным 1 ГБ памяти при выполнении больших заданий. По его словам:
сценарий, используемый для gunzip, захватывает все процессоры, которые он может, потому что данные большие ... постановка в очередь не решит эту проблему ... во время передачи файлов с (этого сервера) на (этот сервер) этап инфляции выполняет много операций чтения / записывать
Почему очередь не может решить эту проблему? Что могло?
Боб читает / записывает большие файлы (например, используя gunzip). Это может занимать до 100% памяти, периодически в течение нескольких часов. Обычно это делается за ночь, но при запуске даже простые команды, такие как cd, занимают 30 секунд, открытие emacs может занять несколько минут.
Первый gzip и gunzip не работают так, как вы думаете - алгоритм, используемый gzip, блочный, и хотя он может быть немного больше при просмотре большого сжатого файла, даже распаковка файла .gz размером 1 ГБ занимает на моей машине около 15 МБ ОЗУ (общий размер процесса).
Во-вторых, если вы не сосете весь файл в ОЗУ, просто чтение или запись большого файла не займет много памяти - ОС может хранить данные в кеше файловой системы, но данные кеша будут удалены, как только программе потребуется эта ОЗУ. Только данные, хранящиеся в рабочей памяти программы, засчитываются как «давление памяти» (использованная оперативная память, плюс или минус несколько других факторов).
Я хотел бы иметь возможность зарезервировать 1 ГБ для использования процессами, которые используют << 1 ГБ (например, текстовый редактор). Я также хотел бы держаться подальше от Боба и не вижу причин, по которым это должно быть проблемой.
Перестаньте пытаться перехитрить пейджер вашей операционной системы: ядро будет менять задачи, чтобы гарантировать, что у того, кто в данный момент выполняется, есть оперативная память для работы. Да, это означает, что вы будете использовать диск, если используете больше оперативной памяти, чем доступно. Решение состоит в том, чтобы ограничить объем используемой оперативной памяти, запустив меньше программ, или добавить больше оперативной памяти.
Концепция «зарезервированного» ОЗУ в корне ошибочна с точки зрения дизайна ОС: у вас не могло бы быть никаких других действий, но программа Боба не могла коснуться «зарезервированной» ОЗУ, поэтому теперь она должна пойти и переключиться на диск. При нехватке (например) 1 КБ программа Боба теперь делает постоянные обращения к диску, выполняя подкачку данных в ОЗУ и из нее, и ваша производительность падает.
Вы можете искусственно ограничить использование ОЗУ Бобом (ulimit), но когда он достигнет жесткого предела, его программы, вероятно, не будут хорошо реагировать (подумайте: malloc(): Unable to allocate XXXXX bytes сопровождаемый некрасивым выходом).
Вы можете, как упоминалось в комментарии rvs, виртуализировать среду и гарантировать, что процессы Боба имеют доступ только к ресурсам, доступным их виртуальной машине, но это просто решает проблему (виртуальная машина Боба начнет заменять местами, а замена виртуальной машины осуществляется путем необходимость, даже медленнее, чем на голом металле).
В реальном мире Джефф, вероятно, прав - вы, вероятно, достигли пределов дискового ввода-вывода, а не ограничений ОЗУ: распаковка файлов - это огромный объем дискового ввода-вывода (считайте из сжатого файла, пропустите его через ЦП и крошечный бит ОЗУ, выплюните в несжатый файл). nice (чтобы повлиять на приоритет ЦП) и ionice если поддерживается (чтобы повлиять на приоритет диска), решит вашу проблему.
Лекция
Не зря, но я вспоминаю тот же вопрос из моего учебника по дизайну операционных систем (хотя пример не был gzip / gunzip). Хотя есть небольшая вероятность, что вы действительно столкнетесь с этой проблемой в реальном мире, я сомневаюсь: это просто слишком надуманный пример.
Помни это Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity - Не для домашнего задания по CS / 301. (Вопросы-Ответы)
Если это реальная проблема, прошу прощения - вы можете быть 1 из 10000, который действительно столкнулся с этим угловым случаем в производственной среде.
Вы можете создать систему очередей заданий или изменить подход ядра к планированию.
Я проигнорирую эти варианты и предложу вам использовать ionice - или, точнее говоря, Боб использует его для снижения своего приоритета. Похоже, у вас проблема с доступом к диску, а не с памятью.
Обычный отлично также может быть вариантом, поскольку это косвенно повлияет на приоритет диска (из справочной страницы ionice: «Приоритет в классе наилучшего усилия будет динамически выводиться из уровня обработки процессора: io_priority = (cpu_nice + 20) / 5».) Программное обеспечение наверху также действительно удобен для получения обзора узких мест и того, является ли проблема регулярным вводом-выводом или переключением на диск.