Как профилировать постоянно работающий сервер, работающий на FreeBSD

Возможный дубликат:
Сохранение gmon.out перед запуском процесса

Я пытаюсь профилировать сервер (исходный код, доступный для меня. c-code) в среде Linux. Этот сервер работает постоянно, как веб-сервер. Я пытаюсь использовать gprof для профилирования сервера. Если сервер выходит сам по себе, генерируется файл gmon.out. Я могу использовать gprof и gmon.out для понимания профилированных данных. Теперь проблема заключается в том, что этот сервер работает непрерывно, ожидая входящих соединений сокетов, запросов и т.д. Если я убью этот сервер, gmon.out не будет сгенерирован. В этот момент я вижу следующие варианты.

  • измените исходный код на сам профиль и запишите эту информацию после получения сигнала SIGKILL. Это, безусловно, самое уродливое решение и может привести к шуму в измерении.
  • Возможно, есть способ профилировать этот сервер, используя gprof, пока сервер все еще работает.
  • Другие инструменты для проверки?

EDIT: Сервер - многопроцессорный сервер. работает на FreeBSD 7.2

Я уверен, люди решили эти проблемы раньше. Мне не удалось найти полезную информацию о SO или снаружи.

Я ценю любые мысли/решения, которые есть у людей.

Спасибо, куча.

ОБНОВЛЕНИЕ 1:

  • gprof, похоже, не работает с многопроцессорным сервером. Когда мне удастся получить gmon.out после выполнения моего сервера, будет выполняться только родительский процесс, который на самом деле не делает реальной работы!
  • oProfile не поддерживает FreeBSD, на котором работает мой сервер. По различным причинам я не могу (не разрешено) менять ОС.
  • Веб-сайт Valgrind не имеет порта для FreeBSD. Но есть ссылки на порт для FreeBSD. Мне не удалось найти источник порта FreeBSD.

Как-то мне удалось получить порты для valgrind. Когда я запускаю make, я получаю следующие ошибки.

=> valgrind-stable-352.tar.gz doesn't seem to exist in /usr/obj/ports/distfiles/.
=> Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/valgrind-stable-352.tar.gz: File unavailable (e.g., file not found, no access)
=> Attempting to fetch from http://www.rabson.org/.
fetch: http://www.rabson.org/valgrind-stable-352.tar.gz: No address record
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/obj/ports/distfiles/ and try again.
*** Error code 1

Я попытался найти valgrind-stable-352.tar.gz в Интернете. Все ссылки, которые я нашел, мертвы.

  1. У меня установлен pstack на моем freebsd, и реализованный pstack дает только трассировку стека. ссылка: http://sourceforge.net/projects/bsd-pstack/

  2. Я понимаю, что systemtap предназначен только для событий ядра, инструментов и т.д.

Я мог ошибаться или иметь недостаточную информацию. Пожалуйста, поправьте меня и дайте свои мысли. Я очень ценю вашу помощь.

ОБНОВЛЕНИЕ 2: Я думаю, что будет полезно дать некоторые сведения о сервере, который я пытаюсь профилировать.

  • это многосерверная программа. I/O bound, для конкретной базы данных mysql.
  • Ничего не связано. Каждый процесс child-server обрабатывает только один запрос. настраиваемое количество процессов создается при запуске сервера.
  • Я хотел бы найти время, затрачиваемое на каждую функцию и ее частоту. функциональные коды представляют собой комбинацию связанных с CPU и IO привязок (я считаю, больше IO).
  • он работает на FreeBSD 7.2
  • записанный в c. количество чтений намного больше, чем запись в базу данных с помощью этого сервера.

Ответы

Ответ 1

Несмотря на то, что вы, безусловно, должны соблюдать свои требования к профилированию критических производственных систем, используйте oprofile или systemtap, скорее всего, они включены в ваш дистрибутив.

Ответ 2

Даже если вы получаете gprof для обслуживания, возникают проблемы.

  • Он слеп к любым системным вызовам или ввода-выводам. Он основан на предположении, что вы никогда не будете делать ненужные зависания. Он смотрит только на проблемы с ЦП.

  • Если есть какая-либо рекурсия, она просто не может справиться с ней.

  • Время, которое оно дает вам, основано на шатких предположениях, например, что каждый вызов процедуры занимает примерно столько же времени. Это не дает информации о линейном уровне.

Измерение - это одно, но если вы хотите найти "узкие места", которые делают ненужные вещи, будь то CPU или I/O, очень грубый, но эффективный инструмент lsstack (который, я думаю, находится на SourceForge).

Кроме того, посмотрите Zoom. Это стековый сэмплер на стене для Linux. Он дает процентные показатели на уровне строк, и я считаю, что он может быть прикреплен и отсоединен от выполняемого процесса.

Ответ 3

Вы можете просто использовать PmcTools - альтернативу FreeBSD oProfile.

Ответ 4

Вы можете переопределить обработчик SIGTERM для вызова exit(0), который заставит gprof генерировать обычный gmon.out.

Ответ 5

Расширьте свой сервер методом (команда, посланная через сокет, возможно), чтобы выйти из него плавно, и там у вас есть ваш gmon.out. Или я что-то упускаю, и полностью невозможно позволить ему выйти, не убив его?

Ответ 6

Если вы можете попробовать linux box fedora/rhel для тестирования разработки, systemtap должен дать вам хорошую видимость ваших серверных процессов. Например, если вы хотите отображать активные функции в программах пользовательского пространства, то примерно такая простая процедура может помочь:

# stap -e 'global fns; probe timer.profile {if (user_mode()) fns[usymdata(uaddr())] <<< 1 }' -d /bin/yourserver -d /lib/yourlibrary.so -d /lib/yourotherlibrary.so

^C, когда закончите. Отчет может выглядеть как

fns["memset /lib64/libc-2.12.so+0xa7d/0xb20"] @count=0x56 @min=0x1 @max=0x1 @sum=0x56 @avg=0x1

fns["memset /lib64/libc-2.12.so+0x560/0xb20"] @count=0x12 @min=0x1 @max=0x1 @sum=0x12 @avg=0x1

fns["__GI_strlen /lib64/libc-2.12.so+0x0/0x50"] @count=0x4 @min=0x1 @max=0x1 @sum=0x4 @avg=0x1

fns["gobble_file /bin/ls+0x729/0xc70"] @count=0x1 @min=0x1 @max=0x1 @sum=0x1 @avg=0x1

fns["getuser /bin/ls+0x1c/0xa0"] @count=0x1 @min=0x1 @max=0x1 @sum=0x1 @avg=0x1

fns["getuser /bin/ls+0x23/0xa0"] @count=0x1 @min=0x1 @max=0x1 @sum=0x1 @avg=0x1

Ответ 7

Вы можете посмотреть на Dyninst: http://www.dyninst.org/

Это основанный на ptrace() API для динамического добавления и удаления инструментов для запуска кода. Вы можете использовать его для отладки, профилирования и т.д.

Удачи.

Ответ 8

Я не слишком разбираюсь в этом, но не могу ли DTrace использовать это?

FreeBSD просто улучшила поддержку этого. http://wiki.freebsd.org/DTrace/userland

Ответ 9

Это может быть случай PMP