Ограничения дескриптора файла и размеры стека по умолчанию - PullRequest
4 голосов
/ 27 февраля 2010

Где я работаю, мы создаем и распространяем библиотеку и пару сложных программ, построенных на этой библиотеке. Весь код написан на C и доступен на большинстве «стандартных» систем, таких как Windows, Linux, Aix, Solaris, Darwin.

Я начал работать в отделе контроля качества, и недавно, выполняя тесты, мне несколько раз напоминали, что я должен помнить, чтобы установить пределы дескриптора файла и размер стека по умолчанию, более высокий, иначе произойдут плохие вещи. Особенно это касается Соляриса, а теперь и Дарвина.

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

Edit:

Замечательные комментарии, которые описывают проблему и немного предыстории. Однако я не думаю, что сформулировал вопрос достаточно хорошо. В настоящее время мы требуем, чтобы клиенты, а значит и мы, тестировщики, устанавливали эти ограничения перед запуском нашего кода. Мы не делаем это программно. И это не та ситуация, когда они МОГУТ закончиться, при нормальной нагрузке наши программы закончатся и вызовут ошибку. Итак, перефразируя вопрос, требует ли заказчик изменить эти значения ulimit для запуска нашего программного обеспечения, ожидаемого на некоторых платформах, например, Solaris, Aix, или мы, как компания, затрудняем запуск этих пользователей?

Bounty: Я добавил вознаграждение, чтобы надеяться получить немного больше информации о том, что другие компании делают, чтобы управлять этими ограничениями. Вы можете установить это прагматично? Должны ли мы? Должны ли наши программы даже выходить за эти пределы или это может быть признаком того, что вещи могут быть немного грязными под прикрытием? Это действительно то, что я хочу знать, поскольку перфекционист, казалось бы, грязная программа действительно доставляет мне неприятности.

Ответы [ 7 ]

7 голосов
/ 13 апреля 2010

Если вам нужно изменить эти значения, чтобы запустить ваши тесты QA, тогда это не слишком большая проблема.Тем не менее, следует избегать требования потребителя сделать это для запуска программы (IMHO).Если ничего другого, создайте скрипт-обертку, который устанавливает эти значения и запускает приложение, чтобы пользователи по-прежнему могли запускать приложения одним щелчком мыши.Однако установка их изнутри программы была бы предпочтительнее.По крайней мере, пусть программа проверит лимиты при запуске и (чисто) выдает ошибку рано, если лимиты слишком малы.

Если разработчик программного обеспечения сказал мне, что мне пришлось возиться со своим стеком ипределы дескриптора, чтобы заставить их программу работать, это изменило бы мое восприятие программного обеспечения.Это заставило бы меня задуматься «почему они должны превышать системные ограничения, которые, по-видимому, приемлемы для любого другого программного обеспечения, которое у меня есть?».Это может или не может быть действительной проблемой, но просьба сделать что-то, что (для многих) может показаться хакерским, не имеет такого же профессионального преимущества, как программа, которую вы только запускаете и запускаете.

Эта проблемакажется еще хуже, когда вы говорите: «Это не та ситуация, когда они МОГУТ закончиться, при нормальной нагрузке наши программы закончатся и вызовут ошибку».Программа, превышающая эти пределы, это одно, а программа, которая не корректно обрабатывает условия ошибки, возникающие в результате превышения этих ограничений, - это совсем другое.Если вы достигнете предела дескриптора файла и попытаетесь открыть файл, вы должны получить сообщение об ошибке, указывающее, что у вас слишком много открытых файлов.Это не должно вызывать сбой программы в хорошо разработанной программе.Может быть сложнее обнаружить проблемы использования стека, но нехватка файловых дескрипторов никогда не должна вызывать сбой.

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

Хотя всегда есть исключения, я бы сказал, что в целом программа, которая превышает этиограничения должны быть пересмотрены.Ограничения существуют по определенной причине, и почти все остальные части программного обеспечения в вашей системе работают в этих пределах без проблем.Вам действительно нужно, чтобы столько файлов открывалось одновременно, или было бы лучше открыть несколько файлов, обработать их, закрыть их и открыть еще несколько?Ваша библиотека / программа пытается сделать слишком много в одном большом пакете, или было бы лучше разбить его на более мелкие, независимые части, которые работают вместе?Превышаете ли вы пределы стека, потому что используете глубоко рекурсивный алгоритм, который можно переписать нерекурсивным способом?Вероятно, существует множество способов улучшения рассматриваемой библиотеки и программы, чтобы облегчить необходимость изменения ограничений системных ресурсов.

1 голос
/ 19 апреля 2010

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

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

Что касается размеров стеков, это может означать две вещи. Стандартной причиной запуска программы вне стека является чрезмерная рекурсия (или неограниченная рекурсия), которая является условием ошибки, для которого фактически предназначены ограничения. Второе - это то, что в стеке располагаются некоторые большие (возможно, конфигурационные) структуры, которые должны быть размещены в динамической памяти. Это может быть даже хуже, и эти огромные структуры передаются по значению (а не по ссылке), что будет означать большой удар по доступному (потерянному) пространству стека, а также большой штраф за производительность.

1 голос
/ 13 апреля 2010

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

Размер по умолчанию для стеков pthread, например, такой случай. Недавно мне пришлось выяснить, что для HPUX11.31 по умолчанию установлено значение 256 КБ (!), Что не очень разумно, по крайней мере для наших приложений.

Установка четко определенных значений увеличивает переносимость приложения, поскольку вы можете быть уверены, что на каждой платформе есть дескрипторы файлов X, размер стека Y, ... и что все работает не просто по счастливой случайности.

У меня есть склонность устанавливать такие ограничения внутри самой программы, так как у пользователя меньше вещей, которые можно испортить (кто-то всегда пытается запустить двоичный файл без сценария-оболочки). Для необязательного разрешения настройки среды выполнения переменные могут использоваться для переопределения значений по умолчанию (все еще применяя минимальные ограничения).

1 голос
/ 27 февраля 2010

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

Это не означает, что пределы не могут быть изменены постоянными / воспроизводимыми способами ни пользователем по усмотрению пользователя (например, путем добавления соответствующих вызовов ulimit в .profile), ни программно из программ / библиотек, которые с уверенностью знать, что им потребуется большое количество файловых дескрипторов (например, setsysinfo (SSI_FD_NEWMAX, ...) ), стека (предоставляется во время создания pthread) и т. д.

1 голос
/ 27 февраля 2010

В Дарвине мягкое ограничение по умолчанию для количества открытых файлов составляет 256; жесткое ограничение по умолчанию не ограничено.

AFAICR, в Solaris мягкое ограничение по умолчанию для количества открытых файлов составляет 16384, а жесткое ограничение - 32768.

Для размеров стеков Дарвин имеет мягкие / жесткие ограничения 8192/65536 КБ. Я забыл, какой лимит установлен для Solaris (а моя машина Solaris недоступна - перебои в подаче электроэнергии в Покипси, штат Нью-Йорк, означают, что я не могу получить доступ к VPN для доступа к машине в Канзасе из моего дома в Калифорнии), но это существенно.

Я бы не беспокоился о жестких пределах. Если бы я думал, что в библиотеке может быть 256 файловых дескрипторов, я бы увеличил мягкое ограничение для Дарвина; Вероятно, я бы не стал беспокоиться о Солярисе.

Аналогичные ограничения применяются в Linux и AIX. Я не могу ответить за Windows.

Грустная история: несколько лет назад я удалил код, который изменял максимальный размер файла в программе - потому что он не менялся со времен, когда 2 МБ был большим файлом (а некоторые системы имели программный лимит всего 0,5 МБ). Когда-то десятилетие и несколько лет назад это фактически увеличило предел; когда это было удалено, это раздражало, потому что это уменьшило предел. Темпус фугит и все такое.


В SuSE Linux (SLES 10) ограничения на открытые файлы составляют 4096/4096, а ограничения на стек - 8192 / неограниченно.

0 голосов
/ 20 апреля 2010

Возможно, вы могли бы добавить все, что подходит для стартового скрипта, например 'ulimit -n -S 4096'.

Но, работая с Solaris с версии 2.6, весьма обычно постоянно изменять rlim_fd_cur и rlim_fd_max в / etc / system. В старых версиях Solaris они слишком малы для некоторых рабочих нагрузок, например для работы веб-серверов.

0 голосов
/ 17 апреля 2010

Небольшой совет: если вы планируете запускать приложение на 64-битном процессоре, будьте осторожны с настройкой размера стека без ограничений. Который в 64-битной системе Linux дает -1 как размер стека.

Спасибо Shyam

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