2015-01-05 4 views
1

У меня есть агент мониторинга, называемый scollector, который использует больше процессора на нашем loadbalancer. Перф говорит, что процессор в основном связан с __d_lookup. Одна из вещей, которые я контролировать это число открытых файлов - Я делаю это с помощью следующего кода:Эффективный способ получить количество файловых ручек, открытых процессом в Go?

fds, e := ioutil.ReadDir("/proc/" + pid + "/fd") 
    if e != nil { 
     w.Remove(pid) 
     continue 
    } 
    ... 
    Add(md, "linux.proc.num_fds", len(fds), tags, metadata.Gauge, metadata.Files, descLinuxProcFd) 

Когда я Трассирование процесса, я вижу его вызовом lstat каждый файл в каталоге /fd (который будет очень много для нашего активного балансировщика нагрузки (не менее 0,5 млн фс) - поэтому я выдвигаю гипотезу, что это источник использования высокочастотного кэша для этого процесса.

У кого-нибудь есть предложение по лучшему пути для этого?

ответ

3

Проблема с ioutil.Readdir такова, что она file.Readdir, в котором говорится, что для каждого файла он имеет lstat.

Кажется Readdirnames не делает этого, возвращая только имена. А поскольку вам нужен только счет, этого должно быть достаточно.

+0

Здесь приведено unix-реализация readdirnames: golang.org/src/os/dir_unix.go –

+0

Да. И основные f.readdirnames не называют 'lstat'. – cnicutar

+0

Readdir также сортирует, это может быть много процессора. Я заметил, что '/ * Open file table structure */ struct files_struct { \t int count; \t fd_set close_on_exec; \t fd_set open_fds; \t struct file * fd [NR_OPEN]; } 'является частью task_struct в linux. Интересно, могу ли я получить этот счет через syscall каким-то образом ... –

 Смежные вопросы

  • Нет связанных вопросов^_^