Назад | Перейти на главную страницу

Почему brk () в выводе strace занимает несколько секунд?

Мы заметили значительное замедление работы одного из наших приложений при переходе на Ubuntu Hardy, amd64. Он отлично работает на Debian Sarge i386.

Запуск 'strace -r' против процесса httpd (Apache 1.3) показал следующий проблемный раздел:

     0.000083 poll([{fd=8, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
     0.000026 recvfrom(8, "_323-412D\0\0\0000\0\2\0\0\0\17recueil-cours"..., 32727, 0, NULL, NULL) = 8192
     0.000061 poll([{fd=8, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
     0.000026 recvfrom(8, "\0\0\0000\0\2\0\0\0\17recueil-courses\0\0\0\23er2"..., 32767, 0, NULL, NULL) = 2369
     0.117422 brk(0x397a000)            = 0x397a000
     0.140721 brk(0x399b000)            = 0x399b000
     4.457037 brk(0x39bc000)            = 0x39bc000
     0.078792 stat("/opt/semantico/slot/nijhoff/3/sitecode/live/public_home.html", {st_mode=S_IFREG|0644, st_size=2194, ...}) = 0

Обратите внимание на brk в предпоследней строке - подразумевается, что brk (0x399b000) занял 4,45 секунды!

Я проверил страницу руководства для brk, которая указывает на то, что она используется для запроса большего сегмента данных / кучи, но я не могу найти причину, по которой это займет так много времени.

У кого-нибудь есть идеи?

Выясняется, что эта проблема в первую очередь связана с тем, что я неправильно понял вывод команды strace -r.

Параметр '-r' указывает время (в секундах) поскольку последний системный вызов, а не время, которое потребовалось для выполнения последнего системного вызова.

В этом случае ЦП выполнял некоторые вычисления, а не обрабатывал brk ().

Проблема здесь решена - она ​​была вызвана обновлением до Perl 5.8.9 (с Perl 5.8.8). Мы отказались от обновления Perl и рассмотрим причину замедления Perl 5.8.9 позже.

brk () - это то, как malloc расширяет доступный пул памяти. Это означает, что ядро ​​может менять местами или играть в игры с оболочкой памяти, чтобы найти достаточно большой новый сегмент памяти для передачи, поэтому производительность ... непредсказуема. Тем не менее, вы можете захотеть взглянуть на некоторые из настроек использования памяти (sysctl -a | grep ^ vm должен дать вам хорошее место для начала поиска), чтобы немного изменить свою стратегию распределения памяти.