Проследяване на PostgreSQL с перф

Помощната програма за профилиране perf което се доставя с ядрото на Linux, е изключително полезно за изследване на поведението в цялата система и много процеси – но прави много повече от профилирането на процесора, за което често се използва. Вероятно сте гледали perf top -az или perf top -u postgres изход, но това е само най-малкото от това, което може да направи. (Ако искате версията TL/DR, скочете надолу до „Динамични сонди на потребителското пространство“).

Едно от големите предимства на perf е, че не е натрапчиво. Не е нужно да прикачвате дебъгер и да прекъсвате изпълнението. Не е нужно да изпълнявате команди директно под профайлър в специална среда. Няма нужда да рестартирате сървъра, за да отстраните проблемно работно натоварване и често няма нужда от повторно компилиране с опции за отстраняване на грешки. Това е изключително полезно, когато се опитвате да откриете проблеми с производителността в жива система, тъй като ви позволява да тествате теории за това какво може да се случва бързо и с минимално въздействие.

перфектно не е само профайлър, той също има поддръжка за проследяване. Профилирането се основава на вземане на проби от състоянието на системата, когато се задейства от хардуерни или софтуерни броячи на производителност; той дава статистическа извадка от точките, където системата прекарва най-много време. Вместо това проследяването взема проби, когато възникне конкретно проследяване, така че е много по-полезно за редки, но важни събития.

Когато работите с PostgreSQL, една от най-вълнуващите функции на perf е способността за проследяване на процеси в потребителското пространство . Искате ли да знаете колко често вашият PostgreSQL разменя WAL сегменти, колко често извършва търсене на външни ключове и т.н.? За един PostgreSQL бекенд или в целия клъстер? перфектно може да помогне с това.

Точките за проследяване на потребителското пространство и пространството на ядрото могат да се смесват и могат да се използват едновременно като профилиране на брояча на производителността, за да ви помогнат да получите добра картина на системата. перфектно може да улавя стек следи както от ядрото, така и от потребителското пространство и може също да прави статистически визуализации. Точките за проследяване на потребителското пространство се създават с динамични сонди; Тези в пространството на ядрото могат да бъдат предварително дефинирани или могат да бъдат динамични проби.

И така, как използвате някои от тези функции?

Инсталирайте инструментите

Първо, уверете се, че използвате текущо perf . Тази статия е написана на Fedora 19 с perf 3.11.6 на x86_64 и някои от функциите са сравнително нови.

Ако искате резултати от стека на потребителското пространство, ще искате кодът, който разглеждате, да бъде изграден с -Og -ggdb -fno-omit-frame-pointer . Ако използвате perf изграден с libunwind нямате нужда от указатели на рамка; вижте тази публикация за препълване на стека и RH Bugzilla #1025603. Нищо от това не е необходимо, ако се интересувате само от данни от страна на ядрото. Ако използвате дистрибутивни пакети, може да се наложи да инсталирате -debuginfo пакети също.

Всички следващи тестове бяха извършени със стандартни пакети PGDG PostgreSQL 9.2 от http://yum.postgresql.org/ с помощта на perf възстановен с libunwind поддръжка съгласно горните инструкции.

Точки за проследяване и сонди на ядрото

перфектно може да улавя данни от предварително дефинирани точки за проследяване на ядрото, някои от които са информативни при разглеждане на проблеми с фрагментация на паметта, дисков вход/изход и т.н. Можете да получите списък с точки за проследяване с sudo perf list . Могат да бъдат посочени списъци с точки за проследяване и се поддържат заместващи знаци. Например, ако искаме да получим статистически данни за запис и изчистване на диск на работещ екземпляр на PostgreSQL, можем да изпълним:

sudo perf record -g dwarf -e block:block_rq_issue,syscalls:sys_enter_fsync -u postgres sleep 10

за улавяне на данните. Вместо спящ режим, можете да използвате без команда и да натиснете control-C, когато приключите със заснемането, или можете да използвате някаква друга команда като psql -c за да задействате натоварването, което искате да измерите.

-u postgres профилира всички процеси, работещи като потребител postgres . Вместо това можете да използвате -a за профилиране на цялата система във всички процесори. Също така е възможно да се проследи само един бекенд. Стартирайте psql , стартирайте select pg_backend_pid() , стартирайте perf с -p $the_pid , след което стартирайте натоварването в същия psql сесия.

Когато работите с PostgreSQL, целевият процес по подразбиране, който е командата, която се изпълнява под контрола на perf , обикновено не е много полезно, защото бекендът върши по-голямата част от работата, а не psql . Все още е полезно да използвате подкомандата, за да контролирате тестовото натоварване и времето.

След като заснемете данните, можете да използвате perf report да го изследвам. Има твърде много опции за обсъждане тук – за контролиране на агрегирането и опростяването на резултатите, показване на проследяване на стека, интерактивни проклятия срещу извеждане на текстов отчет и др.

Вземете тази сесия като пример, където има сесия на обвивка (терминал „T2“) и сесия на postgres, свързана с база данни „regress“ (терминал „T1“):

T1| regress=> изберете pg_backend_pid();T1| pg_backend_pid T1| ----------------T1| 4495T1|(1 ред)

T2| $ sudo perf record -g dwarf -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -p 4495

T1| regress=> създайте таблица x като изберете FROM generate_series(1,1000000) a;T1| regress=>

T2| $ ^CT2| [ perf record:Събуди се 332 пъти за запис на данни ]T2| [ perf запис:Заснети и записани 86,404 MB perf.data (~3775041 проби) ]T2|T2| $ sudo perf доклад -g

Можете да използвате perf report 's curses gui, за да копаете надолу в трасето, или можете да използвате perf report --stdio опция да го накарате да предава данни към stdout. Например, ако искате проследяване на стека, можете да изпълните:

$ sudo perf report -g --stdio... blah blah ...# Примери:1 от събитие 'syscalls:sys_enter_fsync'# Брой събития (приблизително):1## Символ на споделен обект на команди от главната стойност# .. ...... ........ .............................................# 100,00 % postgres libc-2.17.so [.] __GI___libc_fsync | --- __GI___libc_fsync mdimmedsync heap_sync intorel_shutdown standard_ExecutorRun ExecCreateTableAs PortalRunUtility PortalRunMulti PortalRun PostgresMain ServerLoop PostmasterMain main __libc_start_main(manil) 

 показва, че за събитието syscalls:sys_enter_fsync имаше едно събитие с горния стек, fsync, извикан чрез ExecCreateTableAs .
 

 (По причина, поради която все още не съм успял да определя окончателния fsync() изглежда не е уловен от perf когато psql се изпълнява директно под контрола на perf . Това не е проблем с perf stat , само perf record . Ето защо прескачам през обръчи, за да избера предварително бекенда чрез pid по-горе.)
 
Динамични сонди на потребителското пространство
 

 Понякога се интересувате повече от нещо, което се случва в самия PostgreSQL, отколкото от събития в ядрото, които се задействат от PostgreSQL. По-нови версии на perf може да помогне с това, като вмъкне динамични точки за проследяване, които се задействат при повиквания в програми за потребителско пространство.
 

 Да приемем, че се интересувате от гледане на WAL активност и искате да видите кога XLogFlush , XLogFileInit или XLogFileOpen са наречени. Можете да вмъкнете динамични проследяващи точки за тези повиквания с perf :
 
sudo perf probe -x `which postgres` XLogFileInitsudo perf probe -x `which postgres` XLogFileOpensudo perf probe -x `which postgres` XLogFlush
 

 Можете да изследвате само външни символи (нестатични, не скрити от -fvisibility флагове), освен ако не сте изградили с -ggdb . перфектно ще се оплаква няма намерени символи ако се опитате да използвате символ, който не съществува. Към момента на писане perf не поддържа използването на външна информация за отстраняване на грешки за търсене на символи за сонди, въпреки че може да го използва за анализ на стека. Като цяло, ако е външен в src/include можете да го използвате с perf .
 

 Всяка точка на проследяване ще отпечата името на създадената точка за проследяване и можете да използвате perf probe -l за да ги изброите всички така или иначе:
 
$ sudo perf probe -l probe_postgres:XLogFileInit (на 0x000000000009a360) probe_postgres:XLogFileOpen (на 0x000000000009a860) probe_postgres:XLogFlush (на 0x0x000000000000000000) 

 Тези сонди вече могат да се използват като perf събития. Нека да разгледаме xlog активността по време на примерно работно натоварване, наблюдавайки целия клъстер, докато изпълнявам pgbench:
 
sudo perf record -g dwarf -u postgres -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlush
 

 Опитайте сами с perf report -g  . Ето как изглеждат резултатите. Можете да използвате опции като -g фрактал,0 за контрол на детайлите. Ще можете да видите процента на попаденията на даден брояч, дошли от един или друг клон на стека, pid и процес и т.н. --sort опциите ви дават повече контрол върху агрегирането и групирането.
 
Но чакайте, има още
 

 Трябва също да проверите перф стат и perf top команди. Те могат да приемат същите списъци със събития като perf record , въпреки че по някаква странна причина тяхната поддръжка на филтър на процеси е различна.
 

 Ето пример, който изпълнява фиктивно работно натоварване и разглежда точки за проследяване на I/O ядрото по време на изпълнение:
 
$ sudo perf stat -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -a -r 5 -- psql -q -U postgres craig -c "пуснете таблица, ако съществува x; създайте таблица x като изберете ОТ генерирана_серия(1,1000000) a;"; Статистика на брояча на производителността за 'psql -U postgres craig -c пускане на таблица, ако съществува x; създайте таблица x като изберете FROM generate_series(1,1000000) a;' (5 стартирания):0 block:block_rq_abort [100.00%] 0 block:block_rq_requeue [100.00%] 97 block:block_rq_complete ( +- 14.82% ) [100.00%] 96 block:block_rq_insert (%-0.8) 0.4 block:block_rq_issue ( +- 14,67% ) [100,00%] 0 block:block_rq_remap [100,00%]10 607 syscalls:sys_enter_write ( +- 0,17% ) [100,00% ) [100,00%] 1 sys800 секунди:1 sys800 секунди 1 sys80 секунди /предварително> 

 Можете да видите, че изпълнява средно около 100 I/O заявки на блоков слой за 10k write()s и прави един fsync(). Част от това е системен фонов шум, тъй като правим цялото профилиране на системата (-a ), но тъй като системата е доста неактивна, това не е много и е осреднено за пет стартирания.
 

 По същия начин, като използвате динамичните сонди, които добавихме по-рано, следете xlog активността по време на изпълнение на pgbench:
 
$ sudo perf stat -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlush -a -- /usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000 vacummending. тип транзакция:TPC-B (вид) коефициент на мащабиране:100 режим на заявка:прост брой клиенти:2 брой нишки:1 брой транзакции на клиент:10 000 брой действително обработени транзакции:20 000/20 000 tps =715.854663 (включително) 16 т/сек. с изключение на установяване на връзки) Статистики за брояча на производителността за '/usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000':64 probe_postgres:XLogFileInit [100.00%] 0 probe_postgres:XLogFile:XLogFile:0 probe_postgres:XLogFile. XLogFlush 27,987364469 секунди изтекло време
 

 Има много повече, които можете да направите, включително улавяне на състоянието на локални променливи с perf probe . Ще напиша някои полезни примери за това по-късно. Междувременно играйте, изследвайте и се забавлявайте с нов инструмент за диагностика.
 

 Актуализация: Michael Paquier наскоро написа свързана статия за проследяване на PostgreSQL със systemtap, която може да представлява интерес за читателите на тази. Трябва да прекомпилирате Pg, за да използвате този подход, но синтаксисът е по-добър и предлага някои други предимства.