uscr 17.02.2012 09:45
Talks! — Теория очередей.
Здравствуйте. Позвольте, в порядке пятничного мыслебреда, немного загрузить вас. Если скучно, идите под кат. Там много текста.Работал я в одной компании, которая разрабатывала некую систему обработки трафика. Система работала так:
трафик валится на интерфейс, где dumpcap'ом собирается в дампы по 10Мб
готовый дамп переносится в каталог-хранилище, и сразу же начинается сбор следующего дампа
из каталога-хранилища дампы по одному забирает скрипт и скармливает их tshark'у, который благодаря самописному сишному модулю успешно нарезает дамп на кучу файлов по принципу: один файлик - один пакет из дампа
готовый файлики переносятся в другой каталог-хранилище, где перловый парсер тупо регулярками смотрит файлики-пакетики и выдирает оттуда то, что нужно
результат работы парсера пишется в lightSQL, откуда по крону последние записи утекают в postgreSQL.
Очевидно, что такой адский механизм не может работать без сбоев. Образуются очереди. Причём, как ни странно, очередь если и образовывалась, то на стадии обработки парсером файлов-пакетов, и исключельно редко (и незначительно малая) очередь собиралась на стадии нарезки дампов.
А очередь к парсеру выстраивалась всегда по одному принципу: очередь стремительно растёт с нуля файлов до 10-20 тысяч (цифра прямо зависит от производительности машины). А далее колеблется в пределах 1-2 тысяч, но остаётся стабильной. Сколь угодно долго: неделю, месяц, полгода (дольше не наблюдал). Ночью трафик спадает - очередь рассасывается, днём приходит лавина трафика - очередь растёт.
Вопрос мой вот в чём:
Почему очередь стабильна? Ведь если бы не хватало ресурсов, то очередь так и продолжила бы расти...
P.S.
Уточнения:
парсер работает в один поток и обрабатывает не более 10000 файлов за один запуск
в секунду парсер может обработать от 10 (десять) до 1000 (тысяча) файлов
если парсер отвалится в процессе обработки, то новый процесс поднимется не сразу, а только после прихода очередной порции файлов
если сортировать файлы по 4 каталогам (каждый раз добавлять файлы только в самый пустой) и запускать одновременно 4 парсера в каждом из каталогов, то очередь гарантированно исчезает при любых начальных условиях
Тэги: очередь парсер
Пока писал, подумал, что можно на cpan.org сходить и поискать модули для парсинга. Хотя бы так. Как видно поссылке, perl'ом можно напрямую обрабатывать дампы в формате libcap. Без всяких костылей.
Костыль - сама эта система. Это типа DLP. Нам нужно получать письма, посты вконтакте, сообщения в аське, на форумах и кучу всего. Поэтому под каждый конкретный тип события пишется свой кусок кода в парсере. А систему проэктировали "на коленке" совершенно не думая о масштабировании, многопоточности и прочих прелестях. Я, собственно, потому и покинул компанию, что поддерживать эту хрень - бесконечно унылое занятие.
Т.е. опыты провести не получится?
И код парсера тоже нет возможности показать?
Я просто уверен, что проблема либо с нагрузкой на работу с фс, либо в самом парсере. Но, что в первом, что во втором случае, узкое место именно в том, что создаётся очень много промежуточных файлов.
И код парсера тоже нет возможности показать?
Я просто уверен, что проблема либо с нагрузкой на работу с фс, либо в самом парсере. Но, что в первом, что во втором случае, узкое место именно в том, что создаётся очень много промежуточных файлов.
Да. Я там не работаю уже.
Парсер вы смотреть не хотите, я вас уверяю. Там миллиард if/then/elif. От тупит-тормозит, тут спору нет.
Проблемы очевидны. Я понимаю, откуда образуется очередь, меня волнует вопрос: почему же она становится стабильной в определённый момент?!
Парсер вы смотреть не хотите, я вас уверяю. Там миллиард if/then/elif. От тупит-тормозит, тут спору нет.
Проблемы очевидны. Я понимаю, откуда образуется очередь, меня волнует вопрос: почему же она становится стабильной в определённый момент?!
Как я и говорил выше, затык скорее всего в тысячах файлов.
Первый вариант, почему именно на оперделённом моменте тормозит - набирает критическую массу созданных/удалённых файлов и при заходе в директорию с ними, пока не прочитает их всех, ждёт. За это время набегает очередь. После этого работает в штатном режиме, пока очередь не разберёт.
Второй вариант - при старте скрипта он криво собирает информацию об этих файлах(например, заносит их все в один огромный хеш, который начинает обрабатывать). Отсюда зависимость от производительности системы.
В общем, сейчас только гадать можно.
Первый вариант, почему именно на оперделённом моменте тормозит - набирает критическую массу созданных/удалённых файлов и при заходе в директорию с ними, пока не прочитает их всех, ждёт. За это время набегает очередь. После этого работает в штатном режиме, пока очередь не разберёт.
Второй вариант - при старте скрипта он криво собирает информацию об этих файлах(например, заносит их все в один огромный хеш, который начинает обрабатывать). Отсюда зависимость от производительности системы.
В общем, сейчас только гадать можно.
задачка хорошо подпадает под теорию массового обслуживания. парсер обрабатывает с более-менее постоянной скоростью, а трафик идет не равномерно. то что не успевает обработать помещается в очередь (вроде буфера), при снижении трафика система обрабатывает из очереди, таким образом сглаживая нагрузку.
про четыре парсера. а на скольки ядрах их запускают?
про четыре парсера. а на скольки ядрах их запускают?
в качестве аналогии можно взять кассы в супермаркете. кассир - это парсер, клиенты - пакеты. к обеду набежали покупатели, образовалась очередь, к ночи разошлись. октрыли четыре кассы - покупатели обслужились быстрее.
Непонятки именно в этом моменте. Почему количество "покупателей" сначала равномерно растёт, а достигнув критического значения, остаётся стабильным. Такая картина наблюдается всегда: даже если выгнуть всех "покупателей" (rm -f *), то они опять с той же динамикой набегут к "кассам". Получается, неравномерность трафика тут не при чём.
То есть да, в обед, например, все лезут на фишкинет, очередь быстро растёт, но после обеда опять медленно возвращается к своим "стабильным" значениям.
То есть да, в обед, например, все лезут на фишкинет, очередь быстро растёт, но после обеда опять медленно возвращается к своим "стабильным" значениям.
возможно дело в настройках системы.
как вариант: пока маленькая нагрузка система понижает частоту проца, нагрузка возросла - частота повысилась, обработка пошла быстрее
думаю вариантов может быть много, может быть сочетание разных факторов.
как вариант: пока маленькая нагрузка система понижает частоту проца, нагрузка возросла - частота повысилась, обработка пошла быстрее
думаю вариантов может быть много, может быть сочетание разных факторов.
Дык нагрузка не меняется... Да и потом такие очереди появляются только у больших клиентов, а им ставится HP Proliant G7 с 10 рейдом, двумя ксеонами и 16 киллограммами оперативки - так что маловероятно, что машина "загибается"...
а вообще, так можно долго гадать.
В этом и состоит священная цель данного топика.
лучше, конечно, иметь возможность поковырять систему на предмет сбора статистики. по трафику, по обработке его и т.д.
P.S. не факт что выйдет каменный цветок, чисто для интереса...
P.S.S всех с наступающей пятницей:-)
P.S. не факт что выйдет каменный цветок, чисто для интереса...
P.S.S всех с наступающей пятницей:-)
У меня подобная ситуация с работой, все разработчики потихоньку разбегаются, а поддерживать неведомую х..ню, напсанную на коленке становится некому. Тоже надо бежать.
А если не куда бежать, есть ещё шанс остаться последним из "помнящих" и стать неким лидером для новой команды. а там и до карьерного левелапа не далеко.
Мне бежать было куда :)
Мне бежать было куда :)
Что мешает обрабатывать выхлоп tshark'а на лету?
А лучшее вообще какой-нибудь tcpdump натравить. Он умеет дампить в свой формат, спецификации на который открыты. При знании Си, можно разбирать его напрямую. Если неохота, сам же tcpdump умеет приводить свой бинарный дамп в читабельный вид, который опять же можно скармливать напрямую perl'овому скрипту.
Так или иначе, тому, кто проектировал эту систему и придумал тысячи файликов, надо руки оторвать.