Какова историческая причина ограничений файловых дескрипторов (ulimit -n)
Если вы открыты для альтернативных инструментов сжатия, попробуйте этот почти идентичный вариант.
drt="/var/www/html"
mysqldump -u root -p --all-databases | gzip >"$drt/db-$date.gz"
Если вы предпочитаете, вы можете заменить gzipна bzip2или xzи типичное расширение с gzна bz2или xz.
@patbarron до сих пор не опубликовал свои комментарии в качестве ответа, и они действительно превосходны. Так что для тех, кто ищет ответ, он здесь.
Он пишет:
You can look at the source code from Seventh Edition, for example (minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/h/user.h) to see how this was implemented originally. "NOFILE" is the maximum number of open files per process, and it affects the sizes of data structures that are allocated per-process. These structures take up memory whether they're actually used or not. Again, mostly of historical interest, as it's not done this way anymore, but that might provide some additional background on where this came from.
The other constant, "NFILE", is the maximum number of open files in the entire system (across all processes/users), and the per-process table of open files contains pointers into the "files" structure: minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/conf/c.c. This is also a compile-time constant and sizes the system-wide open files table (which also consume memory whether they're actually used or not).
Это объясняет, что исторически была причина. Каждый процесс будет резервировать файловые дескрипторы NOFILE -независимо от того, используются они или нет. Когда ОЗУ не хватает, вы хотите избежать резервирования памяти, которую вы не используете. Мало того, что ОЗУ сегодня дешевле, так резервирование уже не делается.
Это подтверждает мои наблюдения :Я не смог найти ни одной причины, по которой вы бы оставили ulimit -nна уровне 1024 вместо того, чтобы поднять его до максимума:ulimit -n $(ulimit -Hn). Он занимает память только тогда, когда файловые дескрипторы действительно используются.
Насколько мне известно, да, максимальный жесткий предел ядра файла -был обусловлен стратегией выделения памяти (память для структуры inode была выделена заранее ). Эта стратегия была распространенной, интуитивно понятной и эффективной (тогда )и применялась в DOS, Windows, Linux и других операционных системах.
В настоящее время я считаю, что огромное число, которое вы видите, является теоретическим максимумом (2 64-1 ), а «реальный» файл -max выделяется во время выполнения и может быть установить через ulimit(ulimit -Hnи ulimit -Sn). Таким образом, «файл -макс» — это просто своего рода максимальное значение для ulimit, по сути бессмысленное -означает «независимо от того, пока у ulimits не закончится ОЗУ».