За последние 24 часа нас посетили 17854 программиста и 1571 робот. Сейчас ищут 1203 программиста ...

Мониторинг работы apache

Тема в разделе "Установка PHP", создана пользователем hated8, 10 окт 2013.

  1. hated8

    hated8 Активный пользователь

    С нами с:
    14 янв 2011
    Сообщения:
    50
    Симпатии:
    0
    Здравствуйте, на ХР стоит апач и там крутятся достаточно тяжелые пхп-скрипты.
    Всё нормально работает, но время от времени процесс httpd.exe начинает жрать ЦП до 100%...
    Скриптов очень много и работать им нужно непрерывно ибо автору(т.е. мне) станет не чего есть =) Поэтому методом слепого котенка, отключая на несколько дней по одному скрипту, найти баг не получится!
    От сюда и вопрос как можно нормально мониторить работу апача в реалтайме? Чтобы видеть какие скрипты вешают проц, а еще лучше какие функции этих скриптов сейчас выполняются...?

    пол интернет работает на апаче, не ужели нет нормальных инструментов отслеживания багов?
     
  2. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.108
    Симпатии:
    1.243
    Адрес:
    там-сям
  3. hated8

    hated8 Активный пользователь

    С нами с:
    14 янв 2011
    Сообщения:
    50
    Симпатии:
    0
    Забыл добавить, error.log - пуст, правда я там отключил php_notice, но думаю врят ли это может быть причиной подвисаний... А access лог выключен - так как основа работы - парсинг и вес его будет меряться в ГБ/час...
    Так же попробовал задействовать mod_stat глядя на него с помощью найденного в нете скрипта для визуализации(class.parse_server_status.php), но что-то как-то легче не стало, т.к.
    1)он далеко не всегда показывает адекватное время работы
    2)несёт информацию только о времени выполнения того или иного скрипта, а этого для выявления бага маловато
    3)висит вместе с апачем и мониторинг проблемы сводится на нет...

    Хотелось бы вооружиться более мощным инструментом мониторинга...
     
  4. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.108
    Симпатии:
    1.243
    Адрес:
    там-сям
    какую именно ситуацию ты хочешь поймать?

    1) если у тебя вечный цикл, то он вероятно создаст высокую нагрузку. обнаружить и вылечить просто: задать разумный max_execution_time, убрать из скриптов set_time_limit() и смотреть логи.

    2) я предпочитаю отлаживать скрипты с полным выводом предупреждений. даже в самом php.ini стоит камент
    # error_reporting
    # Development Value: E_ALL | E_STRICT
    очень, очень помогает! нет лишних предупреждений.

    3) ну и профилировать код, если он становится слишком медлительным. может быть одна глупая функция отжирает у тебя 90% времени
    https://www.google.ru/search?q=php+profiling

    ну а буквально "мониторить" можно через какую-нибудь пингующую службу. как перестал сервер аукаться - тебе письмо или месидж в джаббер
     
  5. hated8

    hated8 Активный пользователь

    С нами с:
    14 янв 2011
    Сообщения:
    50
    Симпатии:
    0
    К сожалению не имею такой возможности - он стоит на 10 минут, так как есть скрипты для которых 5-7 минут - это нормальное время работы... Не много - но есть...
    - я теперь тоже, когда что то новое пишу. но вот перекопать кучу имеющегося и что самое опасное функционирующего кода - это жуть по двум причинам:
    1) Огромный объём потраченного времени при смутных перспективах улучшения производительности
    2) Для исправления нотисов необходимо править работающий код, а учитывая что все мы человеки, возможность допуска ошибки очень велика. Ладно если ошибка даст о себе знать сразу, но если нечаянно зацепишь алгоритм работы - то ошибка может вскрыться и через месяцы - когда клиенты дающие тебе хлеб начнут разбегаться... поэтому в моём случае это неоправданный риск. И логи настроены только на варнинги и ошибки...

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