Вопрос о профилировании

Вобщем ситуация. Есть некий сервер. Очень желательно поднять его производительность. Проблема однако же в том, что стартует он долго и муторно, выделяет кучу буферов и парсит текстовые конфиги.

Т.е. если решать задачу в лоб — львиная доля процессорного времени придется на стартап и на ее фоне оверхед на маршевом режиме видится бесконечно малой величиной.

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

Есть ли возможность исключить из профилирования обращения к целым библиотекам (например libxml) или вести подсчет событий не для всего аптайма, а для определенных моментов — когда окончился сетап и пошел тестовый трафик (наблюдать как poll обходит массив дескрипторов тоже не интересно) ?

Теми: производительность, профилирование

Ctrl + Enter

Igor Mazur Инженер надежности веб-сайтов 13.06.2017 12:14

www.brendangregg.com/linuxperf.html

Відповісти

Підтримати

Eugene Nuribekov SSE 13.06.2017 12:24

Спасибо. Видел, но не вчитывался. Теперь буду курить.

Igor Mazur

Olena Software Engineer 15.06.2017 18:19

Там вся книга исключительно прекрасна www.amazon.com/...ndan-Gregg/dp/0133390098

Denis Pyshev 13.06.2017 11:24

google://flame graphs

anonymous 13.06.2017 09:57

Eugene Nuribekov SSE 13.06.2017 12:21

Больше всего жрет стартап. На 10-15 минутных прогонах — 80% процессорного времени.
На его фоне 20 % поделенных на все остальные функции показывает околонуля.
А меня интересует именно то, как делятся ресурсы в этих самых двадцати.

anonymous

anonymous 13.06.2017 14:04

Eugene Nuribekov

Олексій Пєніє 13.06.2017 04:33

В теории-то можно всё, вплоть до того что сам семафоры пропишешь дабы на боевом серваке мониторить производительность. Она ж критичная, верно? А значит и мониторить её надо всегда.

А насчёт «парсит текстовые конфиги» — как-то вообще совсем непонятная причина. Современный проц Британскую энциклопедию менее чем в секунду распарсит, что-то тут не то. Может в HDD проблема? Так дай ему виртуальный диск в оперативе, посмотришь как взлетит.

То что хочется — нет, нельзя. Вернее, можно теоретически, но сервер-то постарался сделать бесшовную интеграцию с библиотеками, и ежели в эту дрянь даже гипотетически влезть — она настолько будет тупить из-за отключённых оптимизаций, что производительность никак не замеришь.

Как это решают в реале — уже говорил. Делают так, чтобы сам боевой код безусловно замерял время, и отчитывался некому виртуальному логеру. А уж будет это реальный логер, файл или /dev/null — решать на этапе прочтения первичных конфигов. В дальнейшем, по мере взросления софта, количество этих сигналов будет сокращаться.

В подавляющем большинстве случаев ЕСЛИ задача параллелизируемая, то есть не один большой клубок, а куча маленьких и средних вполне себе обособленных задач, изредка пересекающихся — то они вообще не нуждаются в исследовании производительности, достаточно засечь время входа и выхода. А уже наблюдать — длину очереди за ресурсами.

Один из самых железобетонных методов — получить стектрейс всех потоков, в сыром виде, или же как-то агрегировать. Суть в чём: будешь видеть где затык, где код тупит. ИЧСХ, этот монитор можно оставить и в боевом коде, пока его не дёрнут — он будет просто незаметно существовать, и нисколечко не тормозить. Но если вдруг чего — можно будет видеть где горечко случилось. Однако, согласно закону Мэрфи, доступ к этому монитору нужно делать парольным — всегда найдётся какой-нибудь идиот или робот, который дёрнет за верёвочку.

Eugene Nuribekov SSE 13.06.2017 08:11

Современный проц Британскую энциклопедию менее чем в секунду распарсит, что-то тут не то. Может в HDD проблема?

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

Олексій Пєніє

Вопрос о профилировании

9 коментарів

Підписатись на коментарі