Что будет если кончится файл дескриптор?

Проблема истощения файловых дескрипторов в Go и Linux

Когда система исчерпывает доступные файловые дескрипторы (FD), это приводит к серьёзным сбоям в работе приложения и всей операционной системы. В контексте Go-приложений последствия особенно критичны.

Что такое файловые дескрипторы?

Это целочисленные идентификаторы, которые Linux kernel использует для управления открытыми ресурсами: файлы, сокеты, каналы и др. Каждый процесс имеет свой лимит FD (обычно 1024 по умолчанию, но может быть увеличен).

Последствия исчерпания дескрипторов в Go

1. Невозможность открытия новых ресурсов Любая операция, требующая FD — открытие файла, создание сетевого соединения, запуск процесса — завершится ошибкой:

   f, err := os.Open("data.txt")
   if err != nil {
       // err будет syscall.EMFILE (Too many open files)
   }
   

2. Сбои в стандартных библиотеках и фреймворках

   • HTTP сервер не сможет принимать новые соединения
   • database/sql не установит новые подключения
   • Любой net.Listener откажет в принятии клиентов

3. Паника или блокировка горутин Необработанные ошибки FD могут вызвать неожиданные паники. Горутины, ожидающие ресурсов, могут зависнуть.

Пример кода, демонстрирующий проблему

package main

import (
    "fmt"
    "net"
    "os"
)

func exhaustDescriptors() {
    for i := 0; i < 10000; i++ {
        conn, err := net.Dial("tcp", "localhost:8080")
        if err != nil {
            fmt.Printf("Ошибка после %d попыток: %v\n", i, err)
            return
        }
        // НЕ закрываем соединение — дескрипторы накапливаются
    }
}

func main() {
    // Сначала увидим ошибку "Too many open files"
    exhaustDescriptors()
    
    // Затем даже открытие файла станет невозможным
    f, err := os.Create("test.txt")
    if err != nil {
        fmt.Println("Файл тоже не открывается:", err)
    }
}

Как диагностировать и предотвратить проблему

Мониторинг в Linux

# Проверить лимит для процесса
ulimit -n

# Посмотреть используемые FD процесса
ls -la /proc/<PID>/fd/

Практики в Go для управления FD

1. Всегда закрывайте ресурсы явно

   func safeRead() {
       f, err := os.Open("file.txt")
       if err != nil {
           return
       }
       defer f.Close() // Критически важно!
       // работа с файлом
   }
   

2. Используйте пулы ресурсов Для сетевых соединений или повторно открываемых файлов.

3. Увеличьте системный лимит

   ulimit -n 65535
   

   Или настройте через /etc/security/limits.conf.

4. Мониторинг через runtime или системные вызовы

   import "golang.org/x/sys/unix"
   
   func checkFDUsage() {
       var rlimit unix.Rlimit
       unix.Getrlimit(unix.RLIMIT_NOFILE, &rlimit)
       fmt.Printf("Максимум FD: %d\n", rlimit.Cur)
   }
   

Глубинные последствия для системы

Когда дескрипторы кончаются на уровне всей системы (не только процесса):

• Новые процессы не могут запуститься
• Системные демоны (ssh, cron) отказывают
• Возможен полный коллапс, требующий перезагрузки

Решение: кроме увеличения лимитов, необходимо тщательное управление ресурсами в коде, использование анализаторов типа pprof для поиска утечек FD, и системный мониторинг через Prometheus или аналогичные инструменты. В Go особенно опасны незакрытые сетевые соединения и забытые defer Close() в долгоживущих горутинах.