Комментарии 72
А картинки очевидно для заманухи? Работает — к PHP отношения не имею, но пост проглядел)
Картинки — чтобы с ума не сойти, читая жесткий хардкор из смести юникса, С, gdb и терминов начала эпохи компьютеризации :-)
В таком случае, голые тётеньки смотрелись бы лучше :)
Хорошая идея, Миш :-) В следующей статейке сделаю иллюстрации в стиле легкой мотивирующей на кодинг эротики :-)
Pin up please!
В случае с PHP это должно быть что-то пожёстче.
Ну вы же знаете, что очень красивые девушки отвлекают от программирования, от паттернов проектирования и ООП — особенно при использовании слаботипизированного языка типа PHP :-) Коллеги просто не смогут сосредоточиться на статье :-)
С PHP лучше уж как-то так… ;)
serversupportforum.de/forum/attachments/smalltalk/1189d1176852116-hamachi-netzwerk-fuck-mod_perl.jpg
serversupportforum.de/forum/attachments/smalltalk/1189d1176852116-hamachi-netzwerk-fuck-mod_perl.jpg
Во!
для активно минусующих, лучше так
elephpantgettingsome.files.wordpress.com/2008/03/ashleyweb.jpg
и т.д. elephpantgettingsome.wordpress.com/
elephpantgettingsome.files.wordpress.com/2008/03/ashleyweb.jpg
и т.д. elephpantgettingsome.wordpress.com/
Факт, но и отвлекали бы больше :)
Сначала подумал, что это песец, но, наскольку уж я не разбираюсь в зоологии — это лисы :)
Я тоже думаю, что лисы :-) А кто они на самом деле… вопрос :-)
Он такой — встречать с улыбкой (и подобными статьями)
i298.photobucket.com/albums/mm265/uramarinka/42-15410690.jpg
i298.photobucket.com/albums/mm265/uramarinka/42-15410690.jpg
Это друг Маленького Принца.
Я думаю эти знания пригодятся и другим программистам python, java, erlang etc.
Дорога ложка к обеду. Как раз кстати.
Для меня всегда этот сегфол был черным ящиком. Теперь хоть стало понятно, что с этим делать :) И, кстати, это мне кажется или с каждой статьей стиль изложения все оттачивается? :)
Респект!
Респект!
Спасибо. Очень полезно. В закладки однозначно.
apache для PHP? А php-fpm Вы пробовали?
Ну конечно пробовали. Битрикс24 работает на php-fpm. Но…
1) Не всем подходит php-fpm по, назовем помягче, историческим причинам
2) Некоторым нужны модуля апача, которых нет в нгинксе.
И конечно php-fpm тоже сегфолтится, правда можно настроить его так, чтобы он релоадил упавший процесс. Да, клиенты почти этого не замечают, но причину ошибки то нужно найти? Для этого и статейка.
1) Не всем подходит php-fpm по, назовем помягче, историческим причинам
2) Некоторым нужны модуля апача, которых нет в нгинксе.
И конечно php-fpm тоже сегфолтится, правда можно настроить его так, чтобы он релоадил упавший процесс. Да, клиенты почти этого не замечают, но причину ошибки то нужно найти? Для этого и статейка.
Да, клиенты почти этого не замечают
Да-да и вообще ни разу не бывает заходя в свою CRM для работы видя интересные сообщения, что либо аккаунта такого нет, либо ничего не работает.
А вы пишите в саппорт? Да, иногда случаются проблемы у амазона или со стабильностью MySQL, постоянно решаем их. С PHP обычно все тихо — работает хорошо.
Для php-fpm проблем не меньше, он так же легко уходит в сегфолт, например, при дефолтных конфигах и рекурсивных регулярках (#([a-z])+# к примеру). Я бы сказал 50/50, уходя от монстроидального apache с его порой причудливыми конфигами (в более чем распространенных дистрах) к php-fpm ведет к проблеме его правильного приготовления, т.к. увы число системных администраторов способных на это пока остается в меньшенстве.
Вы сейчас про регулярки где? При дефолтных конфигах чего? Какой проблеме правильного приготовления?
Непонятно.
Регулярки в конфигах вебсервера? Или регулярки где-то в коде php? Как тут тогда конфиги php привязаны? Как там можно неправильно приготовить, параметров в конфиге чуть менее 10.
Непонятно.
Регулярки в конфигах вебсервера? Или регулярки где-то в коде 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, и будет меньше проблем.
Отличная статья, а проблемы к сожалению будут как с apache так и без него.
Не используем и сегфолтится. Вот перечень мест где:
1) Падают периодически все прекомпиляторы пхп: apc, eaccelerator, xcache и, что удивительно! zend optimizer+.
2) pcre — по идиотски падает при нехватке ресурсов
3) Экстеншены некоторые при определенных конфигурационных параметрах
1) Падают периодически все прекомпиляторы пхп: apc, eaccelerator, xcache и, что удивительно! zend optimizer+.
2) pcre — по идиотски падает при нехватке ресурсов
3) Экстеншены некоторые при определенных конфигурационных параметрах
Не спорю, Apache — «немного» устарел. Но все же, баги есть в каждом приложении, и желательно знать что делать, когда все плохо =)
Из всего моего более чем 10 летнего опыта разработки на PHP, сегфолты ловит только в самописных расширениях и однажды поймал в php_memcached о чем была статья на Хабре. После Гугления оказалось, что ситуация была не редкая.
А при внедрении платформы 1С-Битрикс у крупных клиентов типа eldorado.ru, euroset.ru и других — по причине большого числа PHP-файлов и кода разной сложности бывают нарушения сегментации при высокой нагрузке. И с ними нужно бороться. Раньше я помню падал прекомпилятор при освобождении указателя в движке зенда: efree(), сейчас круг причин стал пошире — приходится разбираться.
Хотел написать практически то же самое, слово в слово. Причём на тех проектах, которые я писал, нагрузка была намного больше, чем на упомянутый автором Эльдорадо — счётчик рамблера на их сайте говорит, что там всего миллион просмотров страниц за день.
Мне кажется, авторам надо поискать ошибки где-то в корне своего Битрикса.
Мне кажется, авторам надо поискать ошибки где-то в корне своего Битрикса.
Проблема в том, что код битрикса вылизан разработчиками достаточно хорошо, ребята очень опытные. А вот сказки начинаются уже с самим прекомпилятором PHP и его модулями или между PHP и апачем. Одна проблема есть, до сих пор спорим откуда она возникает:
1) Иногда, между nginx и apache внезапно скапливается тысячи незакрытых TCP-соединений
2) Спрашивал у Игоря Сысовева где может быть баг, предполагает что в линуксе :-)
1) Иногда, между nginx и apache внезапно скапливается тысячи незакрытых TCP-соединений
2) Спрашивал у Игоря Сысовева где может быть баг, предполагает что в линуксе :-)
Пример бы ещё более полный.
Отличная статья! Большое спасибо, Саш :)
От себя добавлю, что в 95% процентах случаев на моей практике segfault есть следствие кривых расширений PHP и может быть отловлен их поэтапным включением/выключением. Ещё 4,9999 процента — это кривая сборка исходников. Оставшиеся случаи — это как раз поле деятельности gdb :)
От себя добавлю, что в 95% процентах случаев на моей практике segfault есть следствие кривых расширений PHP и может быть отловлен их поэтапным включением/выключением. Ещё 4,9999 процента — это кривая сборка исходников. Оставшиеся случаи — это как раз поле деятельности gdb :)
НЛО прилетело и опубликовало эту надпись здесь
В точку! Не однократно вижу целые группы разработчиков, которые не в состоянии ответить нужен ли им какой либо php-модуль и приходтся открывать список функций и шерстить сорцы, а между тем их зоопарк это потенциальные баги, уязвимости и т.д. и т.п.
Да, да. У проекта должна быть спецификация, составленная девелоперами, какие экстеншены пхп им нужны.
выкинуть все ненужное нах. и работать будет лучше ;)
НЛО прилетело и опубликовало эту надпись здесь
Мы идем к тому, чтобы выкинуть php. Совсем не выкинешь, но многое.
Вот чейнджлог и он пугает слегка. Одни сегфолты и критикалс.
Вот чейнджлог и он пугает слегка. Одни сегфолты и критикалс.
В настоящее время, я работаю в проекте, где выкинули почти весь РНР, сделали, как модуль Апача (еще до меня).
Архитектура стала не лучше, недостаток: привязка к конкретной ветки апача (1.3). В скорости формирования страницы выиграли не много (раза в три-четыре), хотя на потоке 6-10М простмотров — это экономит железа раза в два-три.
Но в результате мы получили монолитный модуль. Сейчас часть логики выносим на отдельные удаленые сервисы в ввиде демонов.
Если бы я был архитектором и начал проект заново, то сделал бы несколько scgi приложений, каждый на свою небольшую задачу и разруливал роутинг по url через nginx. Код значительно упростился бы и работал бы быстрее.
Архитектура стала не лучше, недостаток: привязка к конкретной ветки апача (1.3). В скорости формирования страницы выиграли не много (раза в три-четыре), хотя на потоке 6-10М простмотров — это экономит железа раза в два-три.
Но в результате мы получили монолитный модуль. Сейчас часть логики выносим на отдельные удаленые сервисы в ввиде демонов.
Если бы я был архитектором и начал проект заново, то сделал бы несколько scgi приложений, каждый на свою небольшую задачу и разруливал роутинг по url через nginx. Код значительно упростился бы и работал бы быстрее.
опыт = сын ошибок трудных, еще со времен Пушкина
У нас обычно php обвязан полезными тулзами на проектах:
1) xhprof
2) pinba
3) мунин отрисовывает графики из пинбы
4) nagios на критичные сервисы
5) в php-fpm конечно используем режим бэктрейса медленных запросов и перегруз процесса при сегфолте
Если просто установить пхп и ничего более — как в темноте идешь :-)
1) xhprof
2) pinba
3) мунин отрисовывает графики из пинбы
4) nagios на критичные сервисы
5) в php-fpm конечно используем режим бэктрейса медленных запросов и перегруз процесса при сегфолте
Если просто установить пхп и ничего более — как в темноте идешь :-)
Профилирование? New Relic? Не, никогда не слышал.
Как вы боритесь с причинами впадания PCRE в рекурсию? Функциональное тестирование, 3-4 странных тяжелых вброса и вы бы увидели проблему. Не поможет? Интеграционное тестирование точно покажет проблемы в PCRE.
Тестировать нужно, а не бороться с проблемами на боевом сервере, когда уже поздно. Непрерывная интеграция — наше все.
Как вы боритесь с причинами впадания PCRE в рекурсию? Функциональное тестирование, 3-4 странных тяжелых вброса и вы бы увидели проблему. Не поможет? Интеграционное тестирование точно покажет проблемы в PCRE.
Тестировать нужно, а не бороться с проблемами на боевом сервере, когда уже поздно. Непрерывная интеграция — наше все.
Я так тоже раньше думал, что прочитав пару книжек Фаулера про непрерывную интеграцию надо все покрывать модульными тестами и ходить на работу программиста/админа без памперсов. Ошибался. Тесты все никогда не выявят, т.к. все покрыть тестами нереально — т.к. некоторые вещи не тестируются модульно :-)
В этом облаке вероятностной надежности остается обливаться прохладным душем по утрам и носить памперс. С годами — привыкаешь. У вас будет CI, 100% покрытые юнитами, куча интеграционных тестов, а на бою чик и линус умрет по kernelpanic из-за дохлого драйвера — и клиенты вас утром изнасилуют в твиттере :-) Все нужно уметь — и тесты писать, и корки толковать на бою.
В этом облаке вероятностной надежности остается обливаться прохладным душем по утрам и носить памперс. С годами — привыкаешь. У вас будет CI, 100% покрытые юнитами, куча интеграционных тестов, а на бою чик и линус умрет по kernelpanic из-за дохлого драйвера — и клиенты вас утром изнасилуют в твиттере :-) Все нужно уметь — и тесты писать, и корки толковать на бою.
Однако вы этого не упомянули. А зачастую можно избежать дебага просто прогнав get всех страниц сайта на IS.
Хороший врач должен уметь увидеть болезнь до того как она перейдет в фатальную стадию. Патологоанатомы умеют «толковать корки», и людей они спасают, но post factum и уже других.
100% покрытие кода тестами — фанатизм. Я вовсе не предлагают все-все-все тестировать. Однако профилирование — в крайней степени необходимая штука. Настройка профилирования — тривиальная задача, а результаты оно дает в первый же день после ввода в эксплуатацию.
Я, наверное, уже написал свое последнее приложение в котором нет тестов и профилирования. Испытывают от этого чувство уверенности. Надеюсь патологоанатомом мне придется работать все меньше и меньше.
Хороший врач должен уметь увидеть болезнь до того как она перейдет в фатальную стадию. Патологоанатомы умеют «толковать корки», и людей они спасают, но post factum и уже других.
100% покрытие кода тестами — фанатизм. Я вовсе не предлагают все-все-все тестировать. Однако профилирование — в крайней степени необходимая штука. Настройка профилирования — тривиальная задача, а результаты оно дает в первый же день после ввода в эксплуатацию.
Я, наверное, уже написал свое последнее приложение в котором нет тестов и профилирования. Испытывают от этого чувство уверенности. Надеюсь патологоанатомом мне придется работать все меньше и меньше.
Спасибо огромное за статью!
Здоровья вам и плюсов в карму побольше :)
Здоровья вам и плюсов в карму побольше :)
Кстати, для популярных бинарных дистрибутивов вовсе не обязательно «просить админа», чтобы сделал дебаговскую сборку. Покуда там обычно либо уже есть пакеты с суффиксом -dbg (их создаёт мэйнтейнер), либо сборочная фабрика автоматом кладёт нужное на отдельный сервер. (например, ddebs.ubuntu.com в случае убунты).
SIGSEGV можно перехватить. Нельзя перехватить только SIGKILL и SIGSTOP.
Но лисята милые :)
Но лисята милые :)
Для удобства сбора крэшей от других программ можно указать ядру где именно создавать дампы памяти, чтобы не рыскать по файловой системе в их поиске.
Например, указать в sysctl.conf:
kernel.core_pattern = /tmp/core/core-%e-%s-%u-%g-%p-%t
Например, указать в sysctl.conf:
kernel.core_pattern = /tmp/core/core-%e-%s-%u-%g-%p-%t
сделайте правильные тэги к посту!
во внутренности 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
другое дело, что иногда он и является прямым ответом на вопрос «что случилосб», а иногда даже его наличие никак не помогает.
достаточно положить себе в $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
другое дело, что иногда он и является прямым ответом на вопрос «что случилосб», а иногда даже его наличие никак не помогает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стабилизируем PHP на бою — что и почему «роняет» веб-сервер