Как стать автором
Обновить

Комментарии 72

А картинки очевидно для заманухи? Работает — к PHP отношения не имею, но пост проглядел)
Картинки — чтобы с ума не сойти, читая жесткий хардкор из смести юникса, С, gdb и терминов начала эпохи компьютеризации :-)
В таком случае, голые тётеньки смотрелись бы лучше :)
Хорошая идея, Миш :-) В следующей статейке сделаю иллюстрации в стиле легкой мотивирующей на кодинг эротики :-)
Pin up please!
В случае с PHP это должно быть что-то пожёстче.
Ну вы же знаете, что очень красивые девушки отвлекают от программирования, от паттернов проектирования и ООП — особенно при использовании слаботипизированного языка типа PHP :-) Коллеги просто не смогут сосредоточиться на статье :-)
Во!
лучше так
Факт, но и отвлекали бы больше :)
Сначала подумал, что это песец, но, наскольку уж я не разбираюсь в зоологии — это лисы :)
Я тоже думаю, что лисы :-) А кто они на самом деле… вопрос :-)
Это друг Маленького Принца.
Я думаю эти знания пригодятся и другим программистам python, java, erlang etc.
Дорога ложка к обеду. Как раз кстати.
Да я сам сколько мучился, раньше постоянно тряс сисадминов в поисках причины. Оказалось проще самому было разобраться и решить проблему раз и навсегда.
Для меня всегда этот сегфол был черным ящиком. Теперь хоть стало понятно, что с этим делать :) И, кстати, это мне кажется или с каждой статьей стиль изложения все оттачивается? :)

Респект!
Спасибо. Очень полезно. В закладки однозначно.
apache для PHP? А php-fpm Вы пробовали?
Ну конечно пробовали. Битрикс24 работает на php-fpm. Но…
1) Не всем подходит php-fpm по, назовем помягче, историческим причинам
2) Некоторым нужны модуля апача, которых нет в нгинксе.

И конечно php-fpm тоже сегфолтится, правда можно настроить его так, чтобы он релоадил упавший процесс. Да, клиенты почти этого не замечают, но причину ошибки то нужно найти? Для этого и статейка.
Да, клиенты почти этого не замечают

Да-да и вообще ни разу не бывает заходя в свою CRM для работы видя интересные сообщения, что либо аккаунта такого нет, либо ничего не работает.
А вы пишите в саппорт? Да, иногда случаются проблемы у амазона или со стабильностью MySQL, постоянно решаем их. С PHP обычно все тихо — работает хорошо.
Ну разок как-то весь день ничего не работало решил написать, только чтобы написать нужно авторизоваться, а при авторизации типа логина не найдено. По телефону по выходным — выходные, так что у вас там весело) Давно уже съехали сами и никому не советуем.
Не было такого, чтобы весь день ничего не работало, вы что — ~500 тестов в nagios берегут стабильность системы. С авторизацией — был баг, поправили.
Для php-fpm проблем не меньше, он так же легко уходит в сегфолт, например, при дефолтных конфигах и рекурсивных регулярках (#([a-z])+# к примеру). Я бы сказал 50/50, уходя от монстроидального apache с его порой причудливыми конфигами (в более чем распространенных дистрах) к php-fpm ведет к проблеме его правильного приготовления, т.к. увы число системных администраторов способных на это пока остается в меньшенстве.
Вы сейчас про регулярки где? При дефолтных конфигах чего? Какой проблеме правильного приготовления?
Непонятно.
Регулярки в конфигах вебсервера? Или регулярки где-то в коде php? Как тут тогда конфиги php привязаны? Как там можно неправильно приготовить, параметров в конфиге чуть менее 10.
Я говорю про дефолтные конфиги непосредственно PHP, что при стандартном stack size в 8-10M и дефолтном pcre.recursion_limit в 100000 в сегфолт от подобных регулярок в КОДЕ php уходит одинаково хорошо как php-fpm так и php в виде модуля к apache. Неправильно приготовить php-fpm можно скорее не конфигами самого php-fpm (как вы правильно подметили о количестве параметров) а настройками php, к примеру не отключить user_ini.filename или cgi.fix_pathinfo или еще не одним параметр специфичный и важный непосредственно в контексте php-fpm.
Это все очень полезно большинству разработчиков и за это большое спасибо,
но соль всей темы: просто не используйте Apache, и будет меньше проблем.
Отличная статья, а проблемы к сожалению будут как с apache так и без него.
см коммент ниже…
ни кто не говорит обратное, а как дебажить корки, должен знать каждый разработчик. За что еще раз спасибо автору.
Не используем и сегфолтится. Вот перечень мест где:
1) Падают периодически все прекомпиляторы пхп: apc, eaccelerator, xcache и, что удивительно! zend optimizer+.
2) pcre — по идиотски падает при нехватке ресурсов
3) Экстеншены некоторые при определенных конфигурационных параметрах
НЛО прилетело и опубликовало эту надпись здесь
Есть еще zend optimizer+. Это настоящий прекомпилятор байткода, и вроде быстрее немного eaccelerator. Но тоже падает иногда, да так красиво, что приходится делать на баше автомат релоада апача.
Не спорю, Apache — «немного» устарел. Но все же, баги есть в каждом приложении, и желательно знать что делать, когда все плохо =)
Из всего моего более чем 10 летнего опыта разработки на PHP, сегфолты ловит только в самописных расширениях и однажды поймал в php_memcached о чем была статья на Хабре. После Гугления оказалось, что ситуация была не редкая.
А при внедрении платформы 1С-Битрикс у крупных клиентов типа eldorado.ru, euroset.ru и других — по причине большого числа PHP-файлов и кода разной сложности бывают нарушения сегментации при высокой нагрузке. И с ними нужно бороться. Раньше я помню падал прекомпилятор при освобождении указателя в движке зенда: efree(), сейчас круг причин стал пошире — приходится разбираться.
Хотел написать практически то же самое, слово в слово. Причём на тех проектах, которые я писал, нагрузка была намного больше, чем на упомянутый автором Эльдорадо — счётчик рамблера на их сайте говорит, что там всего миллион просмотров страниц за день.

Мне кажется, авторам надо поискать ошибки где-то в корне своего Битрикса.
Проблема в том, что код битрикса вылизан разработчиками достаточно хорошо, ребята очень опытные. А вот сказки начинаются уже с самим прекомпилятором PHP и его модулями или между PHP и апачем. Одна проблема есть, до сих пор спорим откуда она возникает:
1) Иногда, между nginx и apache внезапно скапливается тысячи незакрытых TCP-соединений
2) Спрашивал у Игоря Сысовева где может быть баг, предполагает что в линуксе :-)

Какое отношение PHP имеет к соединениям между апачем и нжинксом?
Ещё раз повторюсь, за годы разработки нагруженных систем на PHP я сегфолты встречал исключительно в самописных модулях.
Правда мы никогда не занимались сексуальными извращениями и использовали только PHP из репозиториев Debian.
Не имеет отношения, а баг проявляется. ПХП и apc, апач и нгинкс из репозиториев, centos — тоже. На дебиане тоже такое ловили, кстати.
так а почему только на битриксе проявляется?
Пример бы ещё более полный.
Да хотел вставить последнюю сессию отладки, но там много данных конфиденциальных было. Как поймаю сегфолт несекьюрный, выложу обязательно.
Отличная статья! Большое спасибо, Саш :)

От себя добавлю, что в 95% процентах случаев на моей практике segfault есть следствие кривых расширений PHP и может быть отловлен их поэтапным включением/выключением. Ещё 4,9999 процента — это кривая сборка исходников. Оставшиеся случаи — это как раз поле деятельности gdb :)
НЛО прилетело и опубликовало эту надпись здесь
В точку! Не однократно вижу целые группы разработчиков, которые не в состоянии ответить нужен ли им какой либо php-модуль и приходтся открывать список функций и шерстить сорцы, а между тем их зоопарк это потенциальные баги, уязвимости и т.д. и т.п.
Да, да. У проекта должна быть спецификация, составленная девелоперами, какие экстеншены пхп им нужны.
выкинуть все ненужное нах. и работать будет лучше ;)
НЛО прилетело и опубликовало эту надпись здесь
Мы идем к тому, чтобы выкинуть php. Совсем не выкинешь, но многое.
Вот чейнджлог и он пугает слегка. Одни сегфолты и критикалс.
В настоящее время, я работаю в проекте, где выкинули почти весь РНР, сделали, как модуль Апача (еще до меня).
Архитектура стала не лучше, недостаток: привязка к конкретной ветки апача (1.3). В скорости формирования страницы выиграли не много (раза в три-четыре), хотя на потоке 6-10М простмотров — это экономит железа раза в два-три.
Но в результате мы получили монолитный модуль. Сейчас часть логики выносим на отдельные удаленые сервисы в ввиде демонов.
Если бы я был архитектором и начал проект заново, то сделал бы несколько scgi приложений, каждый на свою небольшую задачу и разруливал роутинг по url через nginx. Код значительно упростился бы и работал бы быстрее.

опыт = сын ошибок трудных, еще со времен Пушкина
У нас обычно php обвязан полезными тулзами на проектах:
1) xhprof
2) pinba
3) мунин отрисовывает графики из пинбы
4) nagios на критичные сервисы
5) в php-fpm конечно используем режим бэктрейса медленных запросов и перегруз процесса при сегфолте

Если просто установить пхп и ничего более — как в темноте идешь :-)
Профилирование? New Relic? Не, никогда не слышал.
Как вы боритесь с причинами впадания PCRE в рекурсию? Функциональное тестирование, 3-4 странных тяжелых вброса и вы бы увидели проблему. Не поможет? Интеграционное тестирование точно покажет проблемы в PCRE.
Тестировать нужно, а не бороться с проблемами на боевом сервере, когда уже поздно. Непрерывная интеграция — наше все.
Я так тоже раньше думал, что прочитав пару книжек Фаулера про непрерывную интеграцию надо все покрывать модульными тестами и ходить на работу программиста/админа без памперсов. Ошибался. Тесты все никогда не выявят, т.к. все покрыть тестами нереально — т.к. некоторые вещи не тестируются модульно :-)

В этом облаке вероятностной надежности остается обливаться прохладным душем по утрам и носить памперс. С годами — привыкаешь. У вас будет CI, 100% покрытые юнитами, куча интеграционных тестов, а на бою чик и линус умрет по kernelpanic из-за дохлого драйвера — и клиенты вас утром изнасилуют в твиттере :-) Все нужно уметь — и тесты писать, и корки толковать на бою.
Однако вы этого не упомянули. А зачастую можно избежать дебага просто прогнав get всех страниц сайта на IS.
Хороший врач должен уметь увидеть болезнь до того как она перейдет в фатальную стадию. Патологоанатомы умеют «толковать корки», и людей они спасают, но post factum и уже других.
100% покрытие кода тестами — фанатизм. Я вовсе не предлагают все-все-все тестировать. Однако профилирование — в крайней степени необходимая штука. Настройка профилирования — тривиальная задача, а результаты оно дает в первый же день после ввода в эксплуатацию.
Я, наверное, уже написал свое последнее приложение в котором нет тестов и профилирования. Испытывают от этого чувство уверенности. Надеюсь патологоанатомом мне придется работать все меньше и меньше.
Спасибо огромное за статью!
Здоровья вам и плюсов в карму побольше :)
Кстати, для популярных бинарных дистрибутивов вовсе не обязательно «просить админа», чтобы сделал дебаговскую сборку. Покуда там обычно либо уже есть пакеты с суффиксом -dbg (их создаёт мэйнтейнер), либо сборочная фабрика автоматом кладёт нужное на отдельный сервер. (например, ddebs.ubuntu.com в случае убунты).
Да, да. Спасибо что добавили про это.
SIGSEGV можно перехватить. Нельзя перехватить только SIGKILL и SIGSTOP.
Но лисята милые :)
Спасибо, поправил. Забыл :-)
Для удобства сбора крэшей от других программ можно указать ядру где именно создавать дампы памяти, чтобы не рыскать по файловой системе в их поиске.
Например, указать в sysctl.conf:
kernel.core_pattern = /tmp/core/core-%e-%s-%u-%g-%p-%t
сделайте правильные тэги к посту!
сделал
Какой-то опять фейл… Зачем точка на конце «веб-разработки»? И куда пропал собственно PHP? Также наверное не помешло бы упоминание coredump и gdb.
а так? :-)
годится :)
во внутренности op_array не обязательно лезть чтобы получить PHP-шный бэктрэйс.
достаточно положить себе в $HOME файл .gdbinit из дистрибутива PHP и в GDB после этого появится команда dump_bt.
Выполнять так:
(gdb) dump_bt executor_globals.current_execute_data
[0xf5625a20] strlen() /home/local/dev/php/5_3/run-tests.php:1067
[0xf561b3a8] system_with_timeout() /home/local/dev/php/5_3/run-tests.php:1651
[0xf561ad18] run_test() /home/local/dev/php/5_3/run-tests.php:1103
[0xf5616080] run_all_tests() /home/local/dev/php/5_3/run-tests.php:909

другое дело, что иногда он и является прямым ответом на вопрос «что случилосб», а иногда даже его наличие никак не помогает.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий