RLIMIT_AS не работает при установке своего мягкого предела на определенное значение - PullRequest
2 голосов
/ 05 марта 2011

Для процесса я установил мягкое предельное значение 335544320 и жесткое предельное значение 1610612736 для ресурса RLIMIT_AS.Даже после установки этого значения адресное пространство процесса достигает максимального значения 178MB.Но я могу видеть, что значения мягких и жестких ограничений в /proc/process_number/limits правильно установлены на вышеуказанные значения.

Я хотел бы знать, работает ли RLIMIT_AS в моей ОС, а также хотел бы узнать, как я могу проверить функцию RLIMIT_AS.

CentOS 5.5 (64 бит) - это операционная система, которую я использую.

Некоторые, пожалуйста, помогите мне в этом.Спасибо!

1 Ответ

4 голосов
/ 05 марта 2011

Все setrlimit() пределы: верхние пределы .Процессу разрешено использовать столько ресурсов, сколько ему нужно, до тех пор, пока он остается в мягких пределах.На странице руководства setrlimit() :

Мягкое ограничение - это значение, которое ядро ​​устанавливает для соответствующего ресурса.Жесткий лимит действует как верхний предел для мягкого предела: непривилегированный процесс может только установить для своего мягкого предела значение в диапазоне от 0 до жесткого предела и (необратимо) понизить свой жесткий предел.Привилегированный процесс (в Linux: процесс с возможностью CAP_SYS_RESOURCE) может вносить произвольные изменения в любое из предельных значений.

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

В вашем случае вы указываете верхний предел в 320 МБ для адресапространство и ваш процесс использует около 180 МБ из них - в пределах своих ресурсов.Если вы хотите, чтобы ваш процесс развивался, вам нужно сделать это в его коде .

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

Если вы хотите настроить использование памяти вашего процесса, например, выделивбольше буферов для увеличения производительности, вы должны выполнить одно или оба из следующих действий:

  • запросить у пользователя соответствующее значение.На мой взгляд, это единственное, что всегда должно быть возможным.Пользователь (или системный администратор) всегда должен иметь возможность контролировать такие вещи, отвергая любые догадки из вашего приложения.

  • проверьте, сколько памяти доступно, и попытайтесь угадать хорошеесумма для выделения.

В качестве sidenote, вы можете (и должны) иметь дело с 32-битными и 64-битными во время компиляции.Проверки времени выполнения для чего-то подобного подвержены сбоям и бесполезно расходуют циклы процессора.Имейте в виду, однако, что «разрядность» процессора не имеет прямой связи с доступной памятью:

  • 32-битные системы действительно накладывают ограничение (обычно в 1-3 ГБ) в памяти, которую может использовать процесс.Это не означает, что этот объем памяти фактически доступен .

  • 64-битных систем, будучи относительно более новым, обычно имеют больше физической памяти,Это не означает, что она есть в конкретной системе или что ваш процесс должен ее использовать.Например, многие люди создали 64-битные домашние файловые серверы с 1 ГБ оперативной памяти, чтобы снизить стоимость.И я знаю немало людей, которые были бы раздражены, если бы случайный процесс заставил их СУБД поменяться местами только потому, что он думает только о себе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...