FET CJ жрет серверный траф

В этом месяце получил счет за хостинг больше чем обычно. Полез разбираться почему так, попросил админа посмотреть что именно выжрало стока трафа. При этом по вебалайзеру все было как всегда ровно. Оказалось tradeschecker.php от FET CJ (скрипт который проверяет трейдеров на вшивость) делал херову тучу запросов. Насколько я могу предположить, сервера одного или нескольких трейдеров повисли (тот сидж где у меня фет стоит старый и давно уже заброшен) и скрипт повторял запросы к ним бесконечно. В процесс-листе обнаружилось несколько процессов tradechecker'a, висящие уже несколько суток. Видимо по крону запускается скрипт, повисает, так как пытается достучаться до какого то трейдера, висит день, на следующий день по крону опять запускается он же, тоже повисает, потом еще, какие-то процессы потом все таки отваливаются, но все равно несколько копий висит. Вобщем вроде бы чего там: запрос-ответ, входящий траф на сервере не считается, ан нет - за месяц на одних только исходящих запросах накопилось 300-400 гигов, что помноженное на стоимость по тарифам перерасхода вылилось мне в 40 долларов. Кусок трафа который выжрал фет составляет почти 1/2 от обычно расходуемого мной трафа.

Вобщем, претензий ни к кому нет, сам должен был смотреть, просто хочу предупредить юзеров скрипта - проверьте, как себя чувствуют процессы tradeschecker.php, сколько копий, какое время жизни каждого процесса, а разработчиков прошу обратить внимание на проблему, чтобы как то все таки была добавлена корректная обработка ошибок и контроль выжираемого трафа.

webboxxx писал:

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

хуйня получается. запросы к _мертвым_ хостам траф не жрут, только syn пакет, что за траф в нынешнее время не считается

Для начала обновитесь до новой версии. tradeschecker.php уже давно носит другое название и запускается иначе.
И дальше: скрипт использует cURL для HTTP запросов, если он не отваливается через 25 секунд (время в параметрах скрипта) - видимо что-то с cURL, так как должен.
Дальше - в php должен был быть выставлен timeout в 30 секунд для работы скрипта.
Дальше - если скрипт повис в процессе запроса, откуда там траффик?
Он же висит, что он может кушать кроме процессорного времени?

Посчитаем исходящий траффик на мертвые хосты (хотя заголовки за траффик не считаются обычно), примерно.
Представим вес заголовка 256 байт (обычно поменьше).
Берем (по-простому) 150.000.000.000 байт "потраченного" скриптом траффика, и делим на 256, потом на 30 (дней) потом на 24 часа, потом на 60 минут и получаем 13563 запроса в минуту. Сдается мне, ваш сервер просто бы перманентно был в дауне при таком количестве запросов.

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

webboxxx писал:

попросил админа посмотреть что именно выжрало стока трафа...за месяц на одних только исходящих запросах накопилось 300-400 гигов

Похоже админ решил тебя полечить - 300-400 Гигов это уже небольшой сидж ) Наверное чекер на галеры ходил подрочить...

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

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



В тот момент когда резко снижается количество входящего трафа (зеленый) - это мы прибиваем все процессы tradeschecker. Ощутимая разница, да? Почти в 5 раз. Здесь же заметна тенденция к уменьшению и исходящего, хотя мне честно говоря непонятно, почему он не упал также резко как входящий. Поэтому я теперь сомневаюсь, что фет виноват в перерасходе, однако то, что он виноват в неоправданной загрузке входящего канала (пусть и бесплатного) - не вызывает никаких сомнений. В причинах этого мне не интересно разбираться, но факт есть - процессы работают -> канал засран, процессы прибиты -> канал свободен.
Также непонятно почему до июня все было ок:



Draft, еще раз: не воспринимай как обвинения, возможно что то на сервере у меня сбоит, я предоставил только ту инфу которая не вызывает сомнений, есть проблема - есть причины, тут уж никуда не деться.

могу только сказать - посмотрите cURL, может с ним что -
именно он отвечает за HTTP запросы в скрипте, и все от его работоспособности зависит. И еще, чекер правильно запускается, может слишком часто и из-а этого он как ошалелый ломится проверять все подряд и постоянно? По идее должен раз в час, проверить всех трейдеров и отвалиться. В нормальных условиях на минуту работы.

Draft писал:

могу только сказать - посмотрите cURL, может с ним что - именно он отвечает за HTTP запросы в скрипте, и все от его работоспособности зависит.

предположим, что какой-то из трейдеров ради интереса вычислил запросы данного чекера и выдает в ответ своп =)
бороться можно через CURLOPT_RANGE, если сервер умный.
а если с той стороны вообще хитрец и делает медленную отдачу, то бороться CURLOPT_LOW_SPEED*.
но вообще слабо представляю, чтобы в реальной жизни такие хитрожопцы нашлись, хотя с другой стороны - чего только в жизни не бывает =))

А может просто чекер не может сохранить результат проверки и каждый раз начинает все с нуля ?

Цитата:

А может просто чекер не может сохранить результат проверки и каждый раз начинает все с нуля ?

нет, он так не делает.