Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Содержание
Как проверить все открытые файлы пользователем или процессом в Linux
В некоторых ситуациях на Linux могут возникать ошибки, связанные с превышением лимита использования файловых дескрипторов. Эти лимиты накладываются как самим ядром Linux, так и его программными модулями, например PAM.
Лимит ядра Linux
Узнать текущее значение максимального количества файловых дескрипторов, определяемое ядром Linux можно командой:
Этот лимит может быть изменён без перезагрузки системы (начинает действовать сразу и действует до перезагрузки):
Чтобы требуемое значение использовалось постоянно, то есть действовало и после перезагрузки, его необходимо определить в конфиг.файле /etc/sysclt.conf :
Методика подсчёта открытых файлов
Для получения информации о количестве всех открытых файлов всеми процессами в Linux некоторые «знатоки» предлагают использовать команду типа
Однако такая команда показывает гораздо большее значение, чем всего открыто файлов в системе на данный момент на самом деле. Это связано с тем, что по несколько раз в подсчёт попадают одни и теже открытые файлы, используемые разными процессами.
Поэтому проще для получения общего числа открытых файлов использовать данные ядра Linux
Примеры получения данных
Получить список TOP-20 процессов с самым большим количеством открытых файловых дескрипторов:
Подсчитать количество открытых файлов в разрезе процессов (в первой колонке будет выведен PID процесса, во второй количество открытых файлов этим процессом):
Посмотреть открытые файловые дескрипторы во всех процессах для отдельно взятого пользователя, например «apache»
Подсчитать количество открытых файлов в каждом процессе для отдельно взятого пользователя:
Тоже самое, только в реальном режиме времени:
Посмотреть открыте файловые дескриптры для отдельно взятого процесса (по PID процесса):
Подсчитать количество файловых дескриптров для отдельно взятого процесса:
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 09.06.2018 11:18
3 способа изменить ограничение на количество открытых файлов в ОС Linux
Операционная система временно присваивает файлу номер, называемый дескриптором файла, когда он открыт для доступа. Особая область основной памяти зарезервирована для дескрипторов файлов, и размер этой области определяет, насколько файлов может быть открыто одновременно. Процессы в Linux ограничены рядом ограничений, какие также препятствуют их правильному выполнению, и каждый процесс имеет несколько ограничений, связанных с ним. Оболочка суживает количество файлов, которые программы могут открывать одновременно. В этой статье я покажу вам разные методы, которые вы можете использовать для изменения количества открытых файлов в Linux.
Зачем суживать количество открытых файлов
Поскольку операционной системе требуется память для управления каждым файлом, вы сможете столкнуться с ограничением количества файлов, которые можно открыть. Поскольку программа также сможет закрывать обработчики файлов, она может создавать множество файлов любого размера, пока все вразумительное дисковое пространство не будет заполнено. В этом случае одним из аспектов безопасности является предупреждение исчерпания ресурсов путем введения ограничений.
В Linux существует два вида ограничений:
Вы можете увидать максимальное количество открытых файловых дескрипторов в вашей системе Linux, как показано ниже:
# cat /proc/sys/fs/file-max100576
Свойство показывает количество файлов, которые пользователь может открыть за сеанс входа в систему, но вы обязаны заметить, что результат может отличаться в зависимости от вашей системы. По некоторым причинам может понадобиться увеличить значение набора ограничений. Вот почему ваша система Linux предлагает возможность (повышая или уменьшая) изменять эти ограничения, изменяя максимальное количество открытых файлов на процесс и на систему.
Бригада ulimit
Команду ulimit можно использовать для увеличения количества файлов, которые можно раскрыть в оболочке. Эта команда является встроенной командой bash, поэтому она влияет только на bash и програмки, запускаемые из него. Синтаксис ulimit следующий:
Ulimit [options [limit]]
Параметры определяют, что довольствуется. Вы можете увидеть некоторые варианты, как показано ниже
Модуль подключаемых модулей аутентификации (PAM)
Устанавливать такие ограничения лучше всего с помощью Включаемых модулей аутентификации (PAM), называемых Pam_limits. Большинство основных дистрибутивов Linux используют этот часть как часть своей стандартной конфигурации PAM, поэтому он уже присутствует в некоторых системах Linux, но вам нужно станет настроить его, отредактировав /etc/security/limits. conf файл. Этот файл содержит четыре главных поля:
Вы можете увидать, например, содержимое этого файла, как показано ниже:
Дабы отредактировать максимальное количество открытых файлов для всех пользователей, вы можете добавить, например, приплюсовать в конец файла строки ниже:
# vim /etc/security/limits. conf* hard nofile 20000* soft nofile 15000
После данного вам необходимо отредактировать файл /etc/pam. d/login
# vim /etc/pam. d/loginsession required pam_limits. so
Затем сохраните файл. Вы сможете проверить результат, как показано ниже:
Общесистемный предел
В системе Linux у нас есть Файл-макс, какой является максимальным дескриптором файлов (FD), и настройки по умолчанию для ulimit и file-max предполагают, что несколько юзеров будут совместно использовать систему. Вот почему эти настройки ограничивают количество ресурсов, используемых любым пользователем. Вы можете увеличить количество открытых файлов в Linux, отредактировав /etc/sysctl. conf или путем редактирования директивы Fs. file-max
Вы сможете увидеть текущее значение для открытых файлов с помощью команды
И вы можете менять значение по умолчанию, как показано ниже:
Вы можете проверить итог, как показано ниже
С помощью Sysctl command, изменения применяются до следующей повторная загрузки. Чтобы сделать конфигурацию постоянной, вы можете напрямую отредактировать /etc/sysctl. conf файл, как представлено ниже:
# vim /etc/sysctl. conffs. file-max=250000
Русские Блоги
Количество процессов и дескрипторов linux
Примечание: версия Linux CentOS7
оглавление
Единая концепция обработки и управления
Программа может открывать несколько объектов, а именно процессов;
Во время работы процесс будет открывать множество ресурсов, включая файл файла, сокет коммуникационного соединения, порт прослушивания и т. Д. Мы называем их коллективными дескрипторами. Все в Linux является файлом, поэтому, когда процесс открывает количество дескрипторов При превышении системного лимита мы получим предупреждение: слишком много открытых файлов.
Во-вторых, ограничения ресурсов Linux
1. Ограничения пользовательских ресурсов
В Bash есть команда ulimit, которая обеспечивает управление доступными ресурсами оболочки и процессами, запускаемыми оболочкой. В основном это количество открытых файловых дескрипторов, максимальное количество процессов пользователя, размер файла coredump и т. Д.
Конфигурацию ограничений ресурсов можно настроить в файле подконфигурации в /etc/security/limits.conf или /etc/security/limits.d/. Система сначала загружает limits.conf, а затем загружает каталог limits.d в алфавитном порядке. После загрузки файла конфигурации он перезапишет предыдущую конфигурацию. Формат конфигурации следующий:
Просмотр ограничений пользовательских ресурсов для входа в текущую оболочку
2. ограничение ресурса обслуживания
Мы всегда упоминали оболочку выше, поэтому для тех пользователей, которые не вошли в систему через аутентификацию PAM, таких как mysql, nginx и т. Д., Вышеуказанная конфигурация не эффективна;
Поскольку в системе CentOS 7 / RHEL 7 вместо предыдущего SysV используется Systemd, область конфигурации файла /etc/security/limits.conf сокращается. Конфигурация в limits.conf применима только для аутентификации PAM. Ограничение ресурсов вошедшего в систему пользователя, оно не влияет на ограничение ресурсов службы systemd.
Формат конфигурации следующий:
= Тип ресурса слева, размер справа
Просмотр лимита ресурсов службы
Например, проверьте влияние конфигурации службы nginx:
3. Лимит системных ресурсов
Для пользователя и службы ранее были выделены ресурсы, но каково общее количество ресурсов в системе? Сюда входят параметры ядра. Существует много параметров ядра. Нам нужно только знать, как изменить наиболее часто используемые, такие как количество процессов и количество дескрипторов.
Три, количество процессов ограничено
1. Ограничьте количество пользовательских процессов.
По умолчанию в /etc/security/limits.d/ есть файл подконфигурации 20-nproc.conf, который используется для установки максимального количества процессов для каждого пользователя.
Проверка /etc/security/limits.d/20-nproc.conf обнаружит, что пользователь root по умолчанию не ограничен, а максимальное количество обычных пользовательских процессов составляет 4096
Фактически, root и обычные пользователи по умолчанию используют значение # cat / proc / sys / kernel / threads-max / 2, что составляет половину количества системных потоков.
Установите максимальное количество процессов на пользователя
Примечание. Изменение файла конфигурации не повлияет на ограничение процесса для текущего пользователя, вошедшего в систему.
2. Лимит процесса обслуживания
Примечание: изменение файла конфигурации не изменит ограничение на количество процессов запущенной в данный момент службы, и ее необходимо перезапустить.
3. Общее количество процессов в системе.
Выше мы установили максимальное количество процессов, которые может открыть каждый пользователь, но это не контролирует общее количество процессов в системе (kernel.pid_max). Предполагая, что kernel.pid_max = 1000, максимальное количество пользовательских процессов пользователя, независимо от того, насколько велико заданное значение, Максимальное количество процессов, которые можно открыть, по-прежнему составляет 1000
Просмотрите глобальный метод pid_max:
Временно измените этот метод значения:
Следовательно, после завершения вышеуказанных операций значение максимального числа пользовательских процессов изменяется правильно.
Вышеуказанное действует только временно, оно будет недействительным после перезапуска машины, постоянный эффективный метод:
Добавьте kernel.pid_max = 65535 в /etc/sysctl.conf
Затем перезапустите машину.
В-четвертых, ограничение количества ручек
1. Ограничьте количество пользовательских дескрипторов
Лимит пользователя для входа, как упоминалось выше, можно настроить с помощью файла подконфигурации в /etc/security/limits.conf или /etc/security/limits.d/ следующим образом:
Примечание: изменение файла конфигурации не повлияет на ограничение дескриптора текущего пользователя, вошедшего в систему.
2. Предел обработки обслуживания
Примечание. Изменение файла конфигурации не приведет к изменению ограничения дескриптора запущенной в данный момент службы.
3. Общее количество системных дескрипторов.
Количество процессов, которые могут быть открыты каждым пользователем, и количество дескрипторов, которые могут быть открыты каждым процессом, указаны выше; есть также файл, который устанавливает общее количество дескрипторов, которые могут быть открыты всеми процессами в системе, то есть этот параметр является системным.
Измените максимальное количество системных дескрипторов, метод следующий (действителен после настройки):
Просмотрите общее количество дескрипторов, используемых в настоящее время в системе:
Настройка сетевого стека Linux для высоконагруженных систем
Максимизируем количество входящих соединений
Приглашаем всех желающих посетить открытый демо-урок «Практикум по написанию Ansible роли». На этом вебинаре участники вместе с экспертом будут писать, тестировать и отлаживать ansible роли. Это важно для тех, кто хочет автоматизировать настройку инфраструктуры, поскольку это один из инструментов, который это позволяет сделать. Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.
Очередь приема и netdev_max_backlog
net.core.netdev_max_backlog — параметр задается на ядро процессора.
Очередь ожидающих запросов на соединение и tcp_max_syn_backlog
Если в состоянии «SYN_RECV» находятся много соединений, то можно также подстроить продолжительность нахождения SYN-пакета в этой очереди.
SYN Cookie
Если SYN cookie отключены, то клиент просто повторяет отправку SYN-пакета. Если включены (net.ipv4.tcp_syncookies), то соединение не создается и не помещается в SYN backlog, но клиенту отправляется SYN+ACK так, как если бы это было сделано на самом деле. SYN cookie могут быть полезны при нормальной нагрузке, но при всплесках трафика некоторая информация о соединении может быть потеряна и клиент столкнется с проблемами, когда соединение будет установлено. Подробнее о SYN cookie можно прочитать в статье Грэма Коула (Graeme Cole) SYN cookies ate my dog (SYN cookie съели мою собаку), в которой подробно объясняется, почему включение SYN cookie на высоконагруженных серверах может привести к проблемам.
Повторы SYN+ACK
Что происходит, если SYN+ACK отправлен, но ответа ACK нет? В этом случае сетевой стек сервера повторит отправку SYN+ACK. Задержка между попытками вычисляется таким образом, чтобы обеспечить восстановление сервера. Если сервер получает SYN и отправляет SYN+ACK, но не получает ACK, то тайм-аут повторной передачи вычисляется по экспоненте (Exponental Backoff) и, следовательно, зависит от количества повторных попыток. Количество повторных попыток отправки SYN+ACK задается параметром ядра net.ipv4.tcp_synack_retries (по умолчанию равно 5). Повторные попытки будут через следующие интервалы: 1с, 3с, 7с, 15с, 31с. При шести попытках последняя будет примерно через 63 секунды после первой. Это позволяет удержать SYN-пакет в очереди ожидания более 60 секунд до истечения времени ожидания пакета. Если очередь SYN backlog мала, то не требуется большого количества соединений, чтобы возникла ситуация, когда полуоткрытые соединения никогда не завершатся и тогда никакие соединения не смогут быть установлены. Установите количество повторных попыток SYN+ACK равным 0 или 1, чтобы избежать такого поведения на высоконагруженных серверах.
Повторы SYN
Несмотря на то что повторные SYN-пакеты отправляются клиентом во время ожидания SYN+ACK, они могут влиять и на высоконагруженные серверы, работающие с прокси-соединениями. Например, сервер nginx, устанавливающий несколько десятков прокси-соединений к бэкенд-серверу, из-за всплесков трафика может на некоторое время перегрузить сетевой стек, а повторные попытки создадут дополнительную нагрузку на бэкэнд как в очереди приема, так и в очереди ожидания (SYN backlog). Это, в свою очередь, может повлиять на клиентские соединения. Повторные попытки SYN контролируются параметром net.ipv4.tcp_syn_retries (по умолчанию 5 или 6 в зависимости от дистрибутива). Ограничьте количество повторных попыток SYN до 0 или 1, чтобы не было долгих повторных попыток отправки в течение 63–130 с.
Более подробно о проблемах с клиентскими соединениями при обратном прокси-сервере читайте в статье Linux Kernel Tuning for High Performance Networking: Ephemeral Ports.
Очередь установленных соединений ожидающих принятия (accept queue) и somaxconn
somaxconn и параметр backlog в listen()
Значения по умолчанию для очереди
Значение по умолчанию для net.core.somaxconn берется из константы SOMAXCONN, которая в ядрах Linux вплоть до версии 5.3 имеет значение 128, но в 5.4 она была увеличена до 4096. Однако, на момент написания этой статьи, ядро 5.4 еще не очень распространено, поэтому в большинстве систем значение будет 128, если вы не модифицировали net.core.somaxconn.
Часто приложения для размера очереди по умолчанию используют константу SOMAXCONN, если этот размер не задается в конфигурации приложения. Хотя некоторые приложения устанавливают и свои значения по умолчанию. Например, в nginx размер очереди равен 511, который автоматически усекается до 128 в ядрах Linux до версии 5.3.
Изменение размера очереди
Потоки
Если очередь большая, то подумайте также об увеличении количества потоков, которые обрабатывают запросы в приложении. Например, установка для nginx очереди ожидания в 20480 для HTTP-listener без достаточного количества worker_connections для управления очередью приведет к тому, что сервер будет отказываться отвечать на запросы на установку соединения.
Соединения и файловые дескрипторы
Системные ограничения
Любое сокетное соединение использует файловый дескриптор. Максимальное количество дескрипторов, которые могут быть созданы в системе, задается параметром ядра fs.file-max. Посмотреть количество используемых дескрипторов можно следующим образом:
Вывод показывает, что используется 1976 файловых дескрипторов. Выделено, но не используется 12 (для ядер 2.6+), а максимальное количество — 2048. В высоконагруженной системе значение должно быть достаточно большим, чтобы справиться как с большим количеством соединений, так и с потребностями в файловых дескрипторах других процессов.
Пользовательские ограничения
Помимо системного ограничения количества файловых дескрипторов, у каждого пользователя есть свои лимиты. Они настраиваются в системном файле limits.conf (nofile) или, при запуске процесса под управлением systemd, в unit-файле systemd (LimitNOFILE). Чтобы увидеть значение по умолчанию запустите:
Для systemd (на примере nginx):
Настройка
Для настройки системных ограничений установите параметр ядра fs.max-file в максимальное количество файловых дескрипторов, которое может быть в системе (с учетом некоторого буфера). Например:
Для настройки пользовательского лимита установите достаточно большое значение, чтобы хватило сокетам и файловым дескрипторам рабочих процессов (также с некоторым буфером). Пользовательские ограничения устанавливаются в /etc/security/limits.conf, в conf-файле в /etc/security/limits.d/ или в unit-файле systemd. Например:
Количество worker’ов
Аналогично файловым дескрипторам, количество worker’ов или потоков, которые может создать процесс, ограничено как на уровне ядра, так и на уровне пользователя.
Системные ограничения
Пользовательские ограничения
Есть свои ограничения и у каждого пользовательского процесса. Это также настраивается с помощью файла limits.conf (nproc) или unit-файла systemd (LimitNPROC). Для просмотра максимального количества потоков, которое может создать пользователь запустите:
Для systemd (на примере nginx):
Настройка
Обратный прокси и TIME_WAIT
При большом всплеске трафика прокси-соединения, застрявшие в «TIME_WAIT», суммарно могут потреблять много ресурсов при закрытии соединения. Это состояние говорит, что клиент получил последний FIN-пакет от сервера (или вышестоящего worker’а) и находится в ожидании для корректной обработки пакетов. Время нахождения соединения в состоянии «TIME_WAIT» по умолчанию составляет 2 x MSL (Maximum Segment Length — максимальная длина сегмента), что составляет 2 x 60 с. В большинстве случаев это нормальное и ожидаемое поведение, и значение по умолчанию в 120 с вполне приемлемо. Однако много соединений в состоянии «TIME_WAIT» может привести к тому, что приложение исчерпает эфемерные порты для соединений к клиентскому сокету. В этом случае следует уменьшить FIN тайм-аут.
Собираем все вместе
Очередь приема (receive queue) должна быть рассчитана на обработку всех пакетов, полученных через сетевой интерфейс, не вызывая отбрасывания пакетов. Также необходимо учесть небольшой буфер на случай, если всплески будут немного выше, чем ожидалось. Для определения правильного значения следует отслеживать файл softnet_stat на предмет отброшенных пакетов. Эмпирическое правило — использовать значение tcp_max_syn_backlog, чтобы разрешить как минимум столько же SYN-пакетов, сколько может быть обработано для создания полуоткрытых соединений. Помните, что этот параметр задает количество пакетов, которое каждый процессор может иметь в своем буфере, поэтому разделите значение на количество процессоров.
Размер SYN очереди ожидания (SYN backlog queue) на высоконагруженном сервере должен быть рассчитан на большое количество полуоткрытых соединений для обработки редких всплесков трафика. Здесь эмпирическое правило заключается в том, чтобы установить это значение, по крайней мере, на максимальное количество установленных соединений, которое слушатель может иметь в очереди приема, но не выше, чем удвоенное количество установленных соединений. Также рекомендуется отключить SYN cookie, чтобы избежать потери данных при больших всплесках соединений от легитимных клиентов.
Очередь установленных соединений, ожидающих принятия (accept queue) должна быть рассчитана таким образом, чтобы в периоды сильного всплеска трафика ее можно было использовать в качестве временного буфера для установленных соединений. Эмпирическое правило — устанавливать это значение в пределах 20–25% от числа рабочих потоков.
Параметры
В этой статье были рассмотрены следующие параметры ядра:
И следующие пользовательские ограничения:
Заключение
Все параметры в этой статье приведены в качестве примеров и не должны вслепую применяться на ваших продакшн-серверах без тестирования. Есть и другие параметры ядра, которые влияют на производительность сетевого стека. Но в целом, это наиболее важные параметры, которые я использовал при настройке ядра для высоконагруженных систем.
Исправляем ошибку “Too many open files“ в Linux
Очень часто при работе на высоконагруженных Linux серверах могут возникать ошибки “too many open files». Это означает, что программа открыла слишком много файлов (читай файловых дескрипторов) и не может открыть новые. В Linux ограничения “max open file limit“ установлены по умолчанию для каждого процесса и пользователя, и они не слишком высокие.
В данной статье мы рассмотрим, как проверить текущие ограничения по количеству открытых файлов, как его изменить эту настройку для всего сервера, для отдельных сервисов и для сеанса.
Ошибка: Too many open files и лимиты на количество открытых файлов в Linux
Для начала разберемся, где мы можем наблюдать ошибку “too many open files“. Чаще всего эта ошибка встречается на серверах с установленным веб-серверов NGINX/httpd, сервером БД (MySQL/MariaDB/PostgreSQL), при чтении большого количества логов. Например, когда веб-серверу Nginx не хватает лимита для открытия файлов, вы получите ошибку:
Максимально количество файловых дескрипторов, которые могут быть открыты в вашей системе можно узнать так:
Ограничение на количество открытых файлов для текущего пользователя – 1024. Можно проверить так:
Есть два типа ограничений: Hard и Soft. Пользователь может изменить лимит для soft ограничения (но значение soft не может превышать hard). Hard ограничение можно изменить только от привилегированного пользователя.
Для вывода Hard-ограничения:
Настройки лимитов ограничения на количество одновременно открытых файлов в Linux
Чтобы разрешить всем сервисам открывать большее количество файлов, можно изменить лимиты на уровне всей ОС Linux. Чтобы новые настройки работали постоянно и не сбрасывались при перезапуске сервера или сессии, нужно поправить файл /etc/security/limits.conf. Добавьте строки:
Ели вы используете Ubuntu, нужно прописать строку:
Данный параметр добавляет возможность загрузки ограничений при авторизации пользователя.
После изменений, перезапустите терминал и проверьте значение лимита max_open_files:
Увеличить лимита открытых файловых дескрипторов для отдельного сервиса
Вы можете изменить лимит на количество открытых файловых дескрипторов для конкретного сервиса, а не для всей системы. Рассмотрим на примере apache. Чтобы изменить значения, откройте настройки службы через systemctl: # systemctl edit httpd.service Добавьте необходимые лимиты, например:
После изменения, нужно обновить конфигурацию сервиса и перезапустить его:
# systemctl daemon-reload
# systemctl restart httpd.service
Чтобы проверить, изменились ли значения, нужно получить PID сервиса:
# systemctl status httpd.service
Например, вы определил PID сервиса 32724:
# cat /proc/32724/limits | grep «Max open files”
Так вы изменили значения Max open files для конкретного сервиса.
Увеличение максимального количества открытых файлов для Nginx и Apache
При изменении ограничения на количество открытых файлов для веб-сервера, нужно также поправить конфигурационный файл службы. Например, для Nginx в файле конфигурации /etc/nginx/nginx.conf, нужно прописать/изменить значение в директиве:
После чего выполнить рестарт Nginx.
Для apache, нужно создать директорию:
После этого создайте файл limit_nofile.conf:
Не забудьте перезапустить сервис httpd.
Лимиты file-max для текущей сессии
Чтобы изменить лимиты на открытые файлы в рамках вашей сессии терминала, выполните команду:
При закрытии терминала и создания новой сессии, лимиты вернуться к начальным значениям, указанным в файле /etc/security/limits.conf.
Чтобы изменить общее значение в системе /proc/sys/fs/file-max, измените значение fs.file-max в /etc/sysctl.conf:
В данной статье мы разобрались, как решить проблему с недостаточным лимитом для открытых файловых дескрипторов в Linux и рассмотрели несколько вариантов изменения лимитов на сервере.