Pull to refresh

Comments 116

Я сделал простенький скрипт на php, который плюется числами, а потом его наш админ вывел в заббикс через «внешнюю проверку».

Была цель — получить время, за которое выполняются 80%, 90%, 99% самых быстрых запросов. ИМХО эта метрика гораздо более значима, чем среднее время выполнения.
если вы прикрепите к посту ещё и скрипт, то хуже точно не будет, а людям может и пригодится ;-)
В текущем виде не могу, к сожалению, там есть кусок бизнес-логики.
Я вот здесь писал мост к нашему фреймворку, может в свободное время закончу github.com/Wapstart/onphp-framework/tree/1.0-wapstart/main/Monitoring

Пример скрипта есть в вики, кстати pinba.org/files/scripts/pinba_scripts_stats.php.txt
<img src="" alt=«image»/>
Как-то так.
Действительно хороший подарок для пинбы. Попробую и я сделать что то полезное, а именно отказаться от zabbix и использовать highcharts
А нет у вас оценки, сколько оно добавляет нагрузки на сервер (сравнительный бенчмарк или что-то типа того)?
Если мы говорим про клиент, то там включение pinba даже не удалось отследить. Нагрузки она добавила меньше, чем погрешность измерений.

Сервер пинбы у нас стоит на виртуалке:
dovg@pinba:~$ w
 18:53:41 up 50 days,  6:31,  1 user,  load average: 0.22, 0.14, 0.10
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
dovg     pts/0    192.168.1.203    15:36    0.00s  0.01s  0.00s w

dovg@pinba:~$ free
             total       used       free     shared    buffers     cached
Mem:       1424000    1175020     248980          0          0          0
-/+ buffers/cache:    1175020     248980
Swap:            0    
А вы выполните 'ab -n 1000 -c 10 yoursite.com/somepage.here' два раза, один раз с отключенным пимбом, второй раз с включенным, и покажите нам результаты.
Ближе к рабочему времени, ОК ;)?

Какие-нибудь предложения по составу скрипта будут?
Я бы предложил использовать один из самых сложных скриптов с вашего production сервера, доступного по публичному URL. ;)
Обычно самая загруженная инфой страница это стартовая, попробуйте ее и страницу, которую вы минимально кешируете
Какой долгий тест получился ) Скоро можно будет год отметить.
Чуть ниже автор говорит, что бенчмарки бессмысленны, т.к. оверхеда нет. У меня нет оснований ему не доверять.
Предположим, у вас есть скрипт, который шлёт на сервер N таймеров (у нас в Badoo, например, N в среднем около 30-ти).
В каждом таймере есть два-три тага (операция, сервер, результат операции или что-то около того).
В результате оверхед выходит: обработать N таймеров, сделать уникальный набор строк (для экономии на размере UDP-пакета), добавить это всё в пакет Google Protobuf и послать результат по UDP (и да, всё это на C, в экстеншене).

Сами эти операции совсем мизерные, а если принять во внимание, что таймеры в 99% случаев измеряют общение с внешними сервисами, то на фоне всего скрипта они вообще теряются.
Кроме того, все эти операции делаются во время request shutdown, когда сам скрипт уже закончил работу.
Так что я не вижу смысла даже начинать делать бенчмарки.
Есть ли смысл прикручивать pinba для измерения работы демонов?
Да, с ее помощью очень удобно мониторить кол-во запросов и время ответа в реальном времени
Иногда нужно узнать узкие места любого кода
Сорри, не заметил ответ :(
Да ничего страшного. Мы пинбу используем для качественных оценок — не выросло ли число запросов, в различных точках кода. Абсолютные цифры не очень достоверны. Например число sql запросов по Pinba сильно не совпадает с числом, который отдает Mysql
А из-за чего разница в цифрах?
udp не гарантирует доставку, например ;)
UDP, конечно, не гарантирует доставку, но так быть не должно.
проверьте, что у вас буферов хватает и пакеты не теряются:
в выводе этой команды должен быть ноль: netstat -s | grep «receive errors»
А нету обработки для munin'а, чтобы всё на одной странице видеть?
UFO just landed and posted this here
Насколько я понял, XHProf — для профилирования конкретного запроса.
Pinba же полезна для онлайн мониторинга
просто отличная вещь! Спасибо.
/me пошел ставить на све серво
Все же интересно узнать в цифрах какой она добавляет оверхед
А что в случае с пинбой вы подразумеваете под оверхедом?
Отсылка UDP пакета с счетчиками вообще не заметена.
Единственная проблема — утечки памяти на хранении кастомных счетчиков во время выполнения cli скриптов. В теории эту проблему решает pinba_flush, но на практике оно отваливается с какими-то жуткими ворнигами. Поэтому мы используем пинбу только на web front-end`е.
у нас pinba_flush() в продакшене активно используется для долгоиграющих скриптов.
расскажите мне про жуткие варнинги подробней, плз, я посмотрю.
> Это не анализ логов apache, это профайлинг и мониторинг прямо на продакшене!

Думаю этот инструмент нужно ставить все таки на девелопмент сервер. Для продакшена это в любом случае это оверхед.
а смысл мониторить нагрузку на девелопмент сервере? гораздо полезнее посмотреть как это будет выглядеть в реальных условиях и в случае чего предпринимать какие-то действия в плане оптимизации
для продакшена и апачевские логи — оверхэд.
Но как часто их выключают?
Имелась ввиду вторая часть предложения: «это профайлинг и мониторинг прямо на продакшене!»
Ага! Для Продакшена, и апач — оверхед
Ну да. Они как минимум дисковую нагрузку создают ;)
Пинба как раз заточена, чтобы мониторить продакшен, а оверхед, как уже было сказано выше, находится в пределах погрешности измерения.
это мониторинг проекта, на девелоперском сервере нет смысла его ставить, интересует именно текущее состояние проекта и сервисов, которые в нём используются.
а зачем оверхедить на продакшене, если можно выполнить нагрузочные тесты на девелоперском сервере?
тесты != мониторинг.
Ну это и так понятно. Имелось ввиду: выполнить нагрузочные тесты на девелоперском сервере с включенным пинбой. Пинба промониторит работу скриптов во время нагрузочных тестов. Потом команда сможет проанализировать мониторинг и внести коррективы в работу скриптов (при необходимости).

А так вы оверхедите на продакшене, а это как то не очень фей-шуйно.
ИМХО вы путаете мониторинг и профайлинг.
Любая система мониторинга — это в любом случае оверхед, но спокойный сон того стоит. Плюс к этому процессы на проде и в тестах все же отличаются, как бы мы не пытались сделать их идентичными.
> ИМХО вы путаете мониторинг и профайлинг.

Ну раз так Вы считаете, то не могли бы Вы описать отличия понятий «мониторинга» и «профайлинга»? С точки зрения эти процессы похожи тем что они оба выполняют сбор информации о выполнении скрипта/программы. Поэтому я не считаю что я в чем то путаюсь, скорее Вы ;)

> Плюс к этому процессы на проде и в тестах все же отличаются, как бы мы не пытались сделать их идентичными.

Приведите пример дискретного PHP процесса, который выполняется пользователем и не может быть идентично реализован в нагрузочных тестах?
Профайлинг дает сильно больше информации о процессе. Мониторинг же показывает только общую картину. Не будете же по LA во время нагрузочных тестов говорить чему равен LA на продакшене.

А самое главное отличие в них достаточно простое. У мониторинга постоянная величина — время выполнения кода. Но переменная величина — количество и поведение пользователей.

У профайлинга во время тестирования наоборот. Количество и поведение тестовых полльзователей ( роботов ) — одинаково. А время выполнения кода — разное.

Хотя конечно бывают и случаи, когда код профилируется, «чтобы было», а не чтобы оптимизировать.
Спасибо за развернутый ответ. Но контекст темы все таки про сбор информации о работе PHP скриптов, а так как и профайлинг и мониторинг собирают некую информацию о работе программы, то эти процессы можно считать условно идентичными в пределах данного контекста.
LA к ним же приравняем?
По-моему, нельзя их считать условно идентичными. Профайлинг выдаст вам информацию по вашим тестовым сценариям в лабораторных условиях, а мониторинг по реальным сценариям в реальных условиях. Например, профилируется обычно один скрипт, а в реальности может возникнуть гонка за ресурсами у двух. Если не предвидели такую ситуацию в тестах и не мониторите время ответа, то можно очень долго недоумевать, почему пользователи не остаются на сайте при пиковой нагрузке.
Очень простой пример, с которым мы столкнулись. В деплое разложился бесконечный редирект, при некоторых редких условиях (этот редирект не удалось отловить на тестах до раскладки). После раскладки резко скакануло кол-во запросов к ПХП скриптам. Заметили, начали внимательно искать — нашли. А теперь скажите мне — без мониторинга когда бы вы поняли что у вас в бесконечный редирект в редких случаях существует? Пока пользователи вам писать не стали? Пока сами бы не напоролись (настолько редкий, что ну вряд ли бы напоролись)? Или бы так и жили бы.
У вас что тестировщиков нет? Или они не тестируют функциональность перед деплоем новой версии?

«Редкий бесконечный редирект»? Извините меня, но надо очень постараться что бы такое нагородить. И каким образом он может быть таким редким что даже разработчики вряд ли бы напоролись?

К тому же вопрос был в другом. Я не просил приводить примеры ваших злостных багов, а просил привести пример дискретной процедуры выполняемой пользователем, которая не может быть воспроизведена в нагрузочных тестах.
Тестировщики есть и они прекрасно тестируют, но 100% кейсов ловить это потратить невообразимо много времени, которое как известно деньги — или вы этого не знали?

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

«Гонка за ресурсами».
Как раз тестировщики и должны протестировать 100% кейсов, и не важно сколько это времени займет, потому что если выкладывать не качественно протестированный продукт себе дороже — или вы этого не знали? ;)

Заведите им документ в котором будут описаны все «use case»-ы и требуйте 100% тестирования их, всеми возможными тестами.

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

Ну а так пинба вам помогла :)
Да… вы идеалист. 100% и неважно сколько времени… Ну ваши конкуренты уже выкатили сырую версию и обогнали вас. И ваша 100% рабочая версия никому уже не нужна, а все подсели на 90% рабочую версию конкурентов. Да 10% не работает вначале, но в процессе они починят. А вы за бортом.

Вы реально представляете проект на 1кк строк, пишушийся 6 лет что бы в нём были все use case и при минимальном изменении ядра надо всё пробегать? Ну это примерно 1000 человеко часов. Вперёд.

Предусмотрели на тот момент всё, но вот пришли 0,5% пользователей с очень странными данными и на них такое получилось — такие данные были получены вообще впервые. Их никто не знал. Как такое предусмотреть?

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

Всем спасибо, в эту ветку больше не постю :)
КО?

Пинба — мониторит работу PHP скриптов. Какая разница кто будет дергать тест — пользователь или тест? Вы же не работу с интерфейсом мониторить будете.
Полагаю что автор, под мониторингом продакшен-сервера, подразумевал возможность отслеживания нагрузки в реальном времени, для оперативных действий в случае её внезапного резкого увеличения.
Или, хотя бы, для диагностики узких мест, в сценариях, которые сложно реализовать в тестах. Или которые не сумели предусмотреть.
Для тех, кто пишет про оверхед рекомендую потестировать самим, насколько быстро пхп работает с сетью.

В моих тестах на ноутбуке мне удалось достичь скорости около 5000 тсп запросов-ответов в секунду при 100% загрузке одного ядра моего ноута. Это значит, что отправка одного юдп пакета займет около 0.1 мс. Что составляет 0.25% времени выполнения быстрого пхп-скрипта ( 40мс ).

И да. Я привожу цифры для ядра в 1.6Ггц и 100Мбит сеть.
Приведите пожалуйста показатель «Request per second» с включенной и выключенной «пинбой». Я думаю этот параметр будет более актуален чем время выполнения скрипта.
А, да, вы написали про UDP. Но логика вычислений все равно неясна.
Она отправляет данные по завершению скрипта, когда пользователь уже получил что хотел. Поэтому она может осуществлять отправку сколь угодно долго, и это никак не повлияет на время отклика.
в случае фиксированного количетва процессов-воркеров, которые обрабатываю запросы, это будет означать, что следующий запрос скрипт выполнит позже, чем обычно
Думаю, в такой ситуации, когда машины забиты под завязку, в первую очередь стоит задуматься об оптимизации или расширении парка. Поставить пинбу будет вполне логичным решением, для поиска узкого места :)
не всегда. Фиксированное количество воркеров полезно в случае, когда нужно лимитировать макимальную отжираемую память. Чтобы в случае высокой загрузки сайт тупил, но не падал с кодом 503
>насколько быстро пхп работает с сетью.

Я понимаю откуда берется эта логическая связь, но вы всё-таки сами подумайте:
экстеншен шлёт UDP пакет с помощью sendto(), PHP в данном случае — это обёртка для пользователя.

Можно сколько угодно тестить TCP-коннекты в PHP, но здесь идёт речь:
1) не о PHP, а о С;
2) не о TCP, а о UDP.

>Это значит, что отправка одного юдп пакета займет около 0.1 мс. Что составляет 0.25% времени >выполнения быстрого пхп-скрипта ( 40мс ).

вы где-то пропустили логическое обоснование формулы «скорость работы TCP = скорость работы UDP * 4».
Насколько я помню, работа с сокетами в пхп практически напрямую работает с сишным кодом. То есть разница по скорости выполнения не превышает двух раз.

Я надеюсь никто не считает что UDP будет медленнее TCP?
В остальном я беру коэфициент 4, исходя из следующих моих установок: В своем коде я считал приём запроса и отправку ответа. Пинба не принимает входщий запрос, а только отправляет одно сообщение. Это уже коэфициент 2.
TCP для отправки сообщения сначала устанавливает соединение ( это самое долгое событие в данном сценарии, исходя из моих знаний о особенностях работы сети), а UDP это без надобности. Соответсвенно я условно считаю что UDP отработает быстрее. Тут стоит особо отметить, что я считаю реальное время, а не время процессора. По процессору это будет примерно аналогично — время на скидывание данных в буфер. И ещё одна оговорка — я исхожу из того, что пинба работает с сетью в синхронном режиме, поскольку асинхронный режим в сценарии сбора статистики в момент завершения скрипта не поможет добиться увеличения производительности.

Конечно это писалось ночью с оценками на глаз. Так что я не буду отстаивать эти цифры до последнего издыхания. Но в любом случае считаю свой результат достаточно близким к правде. Пинба даст оверхэд менее процента в случае быстрых скриптов. И менее десятой или даже сотой доли процента в случае использования тяжелых движков.
>Насколько я помню, работа с сокетами в пхп практически напрямую работает с сишным кодом.

если говорить про ext/socket — да, там всё напрямую почти.
если говорить про PHP streams — там всё сложнее.

>В остальном я беру коэфициент 4

Непонятно почему коэффициент 4, а не 8 или не 16, например.
Если следовать вашей логике, то можно просто придумать некий коэффициент, посчитать в уме некие числа базируясь на тестах, которые проведены на ноуте, и вывести в результате что угодно.

На данный момент у вас выходит, что послать 1 UDP пакет в С/PHP занимает 0.05 секунды, я ничего не путаю? (коэффициент теперь 2, а не 4).
Это просто проверить:
pastebin.com/Uxi8T0XG
Этот скрипт у меня на ноуте =) выполняется за:
real 0m3.741s
user 0m0.622s
sys 0m0.465s

Итого: около 0.00003741 сек на один вызов sendto().
не совсем.
5000 пар запрос-ответ в секунду при коэфициенте 4 превращаются в 20000 юдп запросов в секунду. это 0.00005 секунд на один вызов.

А исходя из аналогичного времени выполнения вашего скрипта:
real 0m3.766s
user 0m1.220s
sys 0m1.116s

Я ошибся менее чем в два раза. То есть можно было бы взять коэфициент 8 — это было бы даже ближе. А вот коэфициент 16 был бы уже менее точным, нежели коэфициент 4.
UFO just landed and posted this here
В pinba есть возможность переопределять имя скрипта. Если точка входа у вас одна, то сделать это надо ровно в одном месте.

Я так и делаю ;)
на самом деле оно показывает нагрузку по $_SERVER['REQUEST_URI']
вообще, я считаю, что в таких случаях всё как раз совершенно верно: мы мониторим код, а не УРЛы.
поэтому, если у вас index.php выполняется на каждый запрос, то он и является очевидным узким местом.
но для сбора статистики и/или разделения запросов на какие-то логические/виртуальные УРЛы, можно подменить имя скрипта, как у же написали ранее.
статья отличная, за что автору спасибо
но к сожалению опоздала эдак года на два…
пришлось много биться лбом об стену, чтоб разобраться что и как
www.dotdeb.org
пакеты pinba-mysql-engine и php5-pinba

действительно, надо добавить это в Вики…
SRPM для EL6 (centos 6, scientific linux 6) для pinba-engine, собираемого вместе с MySQL 5.5:
yum.aclub.net/pub/linux/centos/6/umask/SRPMS/mysql55-5.5.15-3.el6.src.rpm

Там же php-5.3.8 с pinba-extension:
yum.aclub.net/pub/linux/centos/6/umask/SRPMS/php-5.3.8-4.el6.src.rpm

Есть бинарная сборка для архитектуры x86_64.

Ставим репозиторий:
cd /etc/yum.repos.d/
wget yum.aclub.net/pub/linux/centos/6/umask/umask.repo
sed -i 's/gpgkey/#gpgkey/' umask.repo
rpm --import yum.aclub.net/pub/linux/centos/$releasever/umask/RPM-GPG-KEY-umask

Ставим пакеты:
yum install php-pinba
yum install mysql55-plugin-pinba

Сегодня собрал, проверил — всё работает.

P.S. естественно, что pinba-engine надо ставить на mysql55-server, что в общем-то очевидно и не конфликтует с пакетом mysql-libs, от которого зависит часть минимальной системы.
о, спасибо.
я помнил, что пакеты для CentOS где-то были, но найти их не смог.
Пожалуйста.

Я раньше только для SLES собирал, но забросил это дело. Это было года 3 назад, когда ещё не было публичной версии Pinba.

Для CentOS 5 пока сборку делать не планирую, но всё может случится, если по работе нужно будет. Возможно, что SRPM для EL6 соберётся и на EL5.
а кто может подробнее объяснить настройки плагина mysql?
в частности интересует что значит pinba_tag_report_timeout
поскольку обновление отчетов по тагам — дело затратное, то предполагалось, что отчеты через некоторое время после последнего чтения могут таймаутиться и переставать обновляться.
на практике этот функционал оказался _у нас_ не востребован, в основном потому, что перегенерация отчета «с нуля» на миллионах таймеров занимает неприлично много времени.
эта опция, как и все другие, описана в мануале: pinba.org/wiki/Manual:Configuration#pinba_tag_report_timeout
коротко говоря, можете игнорировать её.
ещё вопрос, что показывает колонка req_time_per_sec
req_time_total — суммарное время работы скрипта, SUM(req_time)
req_time_percent — суммарное время работы скрипта поделенное на суммарное время работы всех скриптов, (SUM(req_time)/time_total)*100
req_time_per_sec — суммарное время работы скрипта, поделенное на интервал времени, за который у нас собраны данные, SUM(req_time)/time_interval

скажем так, это «сколько времени тратится на этот скрипт в секунду».
по правде говоря, там эта колонка только для единообразия — во всех остальных случаях per_sec имеет бОльший смысл.
Установка не такая уж и тривиальная, выдает ошибку:

INSTALL PLUGIN pinba SONAME 'libpinba_engine.so';

ERROR 1126 (HY000): Can't open shared library '/usr/lib/mysql/plugin/libpinba_engine.so' (errno: 2 libprotobuf-lite.so.7: cannot open shared object file: No such file or directory)

И хз что с этим делать, все библиотеки на месте.
Система врать не будет. Если она говорит, что «libprotobuf-lite.so.7: cannot open shared object file: No such file or directory», значит этот файл системе не известен.
Я могу предположить, что надо как минимум выполнить ldconfig.
Возможно, надо еще положить эту либу туда, где ldconfig её увидит или добавить путь к ней в /etc/ld.so.conf.
В любом случае `ldd /usr/lib/mysql/plugin/libpinba_engine.so` должен успешно находить все либы.
в том то все и дело, что `ldd /usr/lib/mysql/plugin/libpinba_engine.so` находит все либы, я в недоумении…
может быть, у юзера mysql нет прав на эту либу?
ldconfig -p | grep protobuf её показывает?
ага,
ldconfig -p | grep protobuf
libprotobuf.so.7 (libc6) => /usr/local/lib/libprotobuf.so.7
libprotobuf.so.5 (libc6) => /usr/lib/libprotobuf.so.5
libprotobuf.so (libc6) => /usr/local/lib/libprotobuf.so
libprotobuf-lite.so.7 (libc6) => /usr/local/lib/libprotobuf-lite.so.7

а как права юзера на либу проверить?
ls -l?
попробуйте перегрузить MySQL сервер, может он после этого подхватит новый кэш ld…
Столкнулся также с проблемой установки плагина, но получаю другую ошибку:
mysql> INSTALL PLUGIN pinba SONAME 'libpinba_engine.so';
ERROR 1126 (HY000): Can't open shared library '/usr/lib/mysql/plugin/libpinba_engine.so' (errno: 2 undefined symbol: _ZN7handler5cloneEPKcP11st_mem_root)
Нужные файлы есть по указанному пути, mysql версии 5.1.54, pinba ставил из пакетов dotdeb'а. Куда стоит копнуть?
а MySQL тоже из dotdeb?
pinba должна быть собрана именно с той версией MySQL и с теми ключами, с которыми собран mysqld.
Переставил мускл из dotdeb — помогло, спасибо.
решили эту проблему? у меня аналогичная проблема. CentOS 6
Что вы понимаете под «вложенностью»?
Будет ли работать Pinba с PHP 5.4?
Заодно можно было бы протестировать столь расхваленное увеличение производительности 5.4 VS 5.3 в реальных улсовиях :) (конечно же, когда 5.4 станет стабильной)
>Будет ли работать Pinba с PHP 5.4?
серверу всё равно, а экстеншен собирается и работает с любой версией PHP.
Настраивать Пинбу довольно сложно. Вариант проще — использовать программу профайлер прямо в рабочей среде программера. Neor Profile SQL позволяет мониторить взаимодействие вашего сайта с Mysql.
image
Не путайте теплое с мягким.
для девелоперов решение аналогичное, но в разы проще.
для системщиков, конечно не одинаковое.
Перечитайте статью еще раз, пожалуйста.
Pinba — это не профайлер sql запрсоов, как вам показалось.
не хочу разводить полемику, но вот что написано на офф сайте программы:
Pinba is a realtime monitoring/statistics server for PHP using MySQL as a read-only interface.

и вот что такое профилирование с википедии:
сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д. Инструмент, используемый для анализа работы, называют профилировщиком. Обычно выполняется совместно с оптимизацией программы.
Учите английский
Pinba is a realtime monitoring/statistics server for PHP using MySQL as a read-only interface.

Пинба — это сервер мониторинга/статистики для php в реальном времени, который использует mysql в качестве интерфейса для чтения.


Он всего лишь хранит данные в чем-то похожем на mysql, но ни как не профайлит mysql, как вам могло показаться.
профилировать можно по разному, с разных точек. Получатся разные результаты, но косвенно ведут к одному и тому же. Так что не надо утверждать что Пинба не профайлер.

1. самая дальняя точка — смотреть на время выдачи страницы. Так делает 99% прогеров.
2. смотреть на взаимодействие php с mysql — более глубокая точка. Так привыкли делать. Пинба здесь же.
3. смотреть на то как именно работают запросы — чистый профайлинг mysql
1. pinba не профайлер
2. pinba не профайлер mysql

dixi
в таком случае чтобы не вводить php девелоперов заблуждение, четко напишите здесь и на сайте, что это сервис статистики
«Pinba is a realtime monitoring/statistics server for PHP using MySQL as a read-only interface.»
Предложите как написать это четче, чтобы никого не вводить в заблуждение.
Есть ли какие-нибудь особенности установки Pinba с Percona 5.5 из репозитория? (в смысле Percona из репозитория, Pinba — из сорцов)

Всё заканчивается так:
# mysql -D pinba < default_tables.sql
ERROR 1005 (HY000) at line 3: Can't create table 'pinba.request' (errno: 140)

Опции cmake, взятые отсюда www.percona.com/doc/percona-server/5.5/installation.html#installing-percona-server-from-the-bazaar-source-tree, применял к Pinba.
На просторах Интернета видел несколько подобных проблем без решения.

Уж очень не хотелось бы запускать второй бинарник mysqld только ради Pinba…
Исходники нужно сконфигурировать/собрать с такими же опциями, что и бинарник, включая CFLAGS/CXXFLAGS.
Судя по опыту людей, они всё-таки какие-то флаги добавляют, которые в документации отсутствуют:
groups.google.com/d/msg/pinba-engine-ru/mQDa18eup-c/8NUPyWoITpoJ

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

Пытался у них в твиттере об этом спросить: twitter.com/lu4e3ar/status/372686817256288256 — не ответили, хотя обычно отвечают оперативно. Непонятно, что такого секретного в этих опциях…

Нет ли какого-то другого способа выяснить эти опции?
Сейчас успешно поставил pinba на другой сервер с чистым MySQL. Но всё же хотелось бы добить Percona…
Здравствуйте! Проблема решилась? Вы бы объяснили им зачем Вам это надо, может Вы под шумок пытаетесь совершить что-то непристойное.
Sign up to leave a comment.

Articles