Перейти на PRO

Что произойдет при исчерпании лимита файловых дескрипторов в приложении?

Тип вопроса: Linux Вероятность: 10% Категория: Golang Разработчик

Ответ

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

В Go это, как правило, приводит к ошибке too many open files.

Что такое файловый дескриптор? Это уникальное неотрицательное целое число, которое операционная система использует для идентификации открытого файла, сокета или другого ресурса ввода-вывода.

Основные причины и способы решения:

  1. Утечка дескрипторов: Вы забываете закрывать файлы или сетевые соединения. Всегда используйте defer для гарантированного закрытия. 
    f, err := os.Open("file.txt")
if err != nil {
    // обработка ошибки
}
defer f.Close() // Гарантирует закрытие файла при выходе из функции
  2. Высокая нагрузка: Приложение одновременно обрабатывает слишком много соединений или файлов. Решение — использовать пулы ресурсов (например, пулы соединений с БД) или архитектурно ограничить количество одновременных операций.
  3. Низкий системный лимит: Лимит по умолчанию может быть слишком мал для вашего приложения. Его можно проверить (ulimit -n в Linux/macOS) и увеличить, но это следует делать осознанно, после исключения утечек.

Для диагностики в Linux можно посмотреть открытые дескрипторы конкретного процесса: ls -l /proc/<PID>/fd.

Ответ 18+ 🔞

Слушай, а вот представь себе такую пиздопроебибну ситуацию: твоя программа, как этот Герасим из рассказа, молча и упорно работает, работает, а потом — бац! — и начинает орать «Муму!», то есть «too many open files». И всё, пиздец, встала как вкопанная, новые дела делать не может.

А вся трагедия-то в чём? В файловых дескрипторах, блядь. Это такие вот циферки, которые операционка выдает, когда ты что-то открываешь — файлик там, сетевое соединение, ещё какую хуйню. И этих циферок, как и всего хорошего, конечное количество. Кончились — и ты накрылся медным тазом.

Ну и откуда эта хуйня вообще лезет? Три главные причины:

  1. Ты — распиздяй и не закрываешь за собой. Открыл файл, прочитал и пошёл дальше, а он там болтается, как манда с ушами. В Go за тебя это может сделать defer, это же ебать мои старые костыли, гениальная штука! Используй, не будь мудаком.

    f, err := os.Open("file.txt")
if err != nil {
    // ну тут понятно, ошибку обработай
}
defer f.Close() // Вот этот волшебный пинок под зад гарантирует, что файл закроется, когда функция кончит свои дела.

  2. Твоё приложение слишком хорошее и все его любят. Серьёзно, нагрузка овердохуища: десять тысяч соединений одновременно, файлы пачками. Тут уже надо головой думать, а не надеяться на авось. Пулы соединений делать, лимиты ставить, архитектуру пересматривать.

  3. Система сама по себе скупая. Лимит по умолчанию может быть таким смешным, что любая серьёзная программа его продырявит с одного пинка. Посмотреть можно командой ulimit -n. Увеличить — тоже можно, но это как дать алкоголику ключ от бара: сначала убедись, что у тебя нет утечек, а то будет просто быстрее и громче пиздец.

А если совсем припёрло и непонятно, куда они все деваются — в Линуксе есть способ посмотреть на эту жопу собственными глазами. Запусти ls -l /proc/<PID>/fd для своего процесса, и ты увидишь всю эту толпу открытых дескрипторов, которые, возможно, просто тусят без дела. Волнение ебать!

© ХакСобесов, 2026
support@hacksobesov.com