Видео смотреть бесплатно

Смотреть русское видео

Официальный сайт terra-z 24/7/365

Смотреть видео бесплатно

uscr 17.02.2012 09:45

Talks!Теория очередей.

Здравствуйте. Позвольте, в порядке пятничного мыслебреда, немного загрузить вас. Если скучно, идите под кат. Там много текста.


Работал я в одной компании, которая разрабатывала некую систему обработки трафика. Система работала так:

трафик валится на интерфейс, где dumpcap'ом собирается в дампы по 10Мб
готовый дамп переносится в каталог-хранилище, и сразу же начинается сбор следующего дампа
из каталога-хранилища дампы по одному забирает скрипт и скармливает их tshark'у, который благодаря самописному сишному модулю успешно нарезает дамп на кучу файлов по принципу: один файлик - один пакет из дампа
готовый файлики переносятся в другой каталог-хранилище, где перловый парсер тупо регулярками смотрит файлики-пакетики и выдирает оттуда то, что нужно
результат работы парсера пишется в lightSQL, откуда по крону последние записи утекают в postgreSQL.

Очевидно, что такой адский механизм не может работать без сбоев. Образуются очереди. Причём, как ни странно, очередь если и образовывалась, то на стадии обработки парсером файлов-пакетов, и исключельно редко (и незначительно малая) очередь собиралась на стадии нарезки дампов.

А очередь к парсеру выстраивалась всегда по одному принципу: очередь стремительно растёт с нуля файлов до 10-20 тысяч (цифра прямо зависит от производительности машины). А далее колеблется в пределах 1-2 тысяч, но остаётся стабильной. Сколь угодно долго: неделю, месяц, полгода (дольше не наблюдал). Ночью трафик спадает - очередь рассасывается, днём приходит лавина трафика - очередь растёт.

Вопрос мой вот в чём:

Почему очередь стабильна? Ведь если бы не хватало ресурсов, то очередь так и продолжила бы расти...



P.S.

Уточнения:
парсер работает в один поток и обрабатывает не более 10000 файлов за один запуск
в секунду парсер может обработать от 10 (десять) до 1000 (тысяча) файлов
если парсер отвалится в процессе обработки, то новый процесс поднимется не сразу, а только после прихода очередной порции файлов
если сортировать файлы по 4 каталогам (каждый раз добавлять файлы только в самый пустой) и запускать одновременно 4 парсера в каждом из каталогов, то очередь гарантированно исчезает при любых начальных условиях


Тэги: очередь парсер
+ 1 -
Похожие Поделиться

cppmm 17.02.2012 10:38 #
+ 0 -
Какая файловая система? Дело в том, что в ext при удалении файла, его индекс сохраняется, а новосозданному файлу присваивается следующий в очереди. При чтении директории система просматривает все индексы вне зависимости от того, ведут они к реальным файлам или нет. Так что вполне возможно, что задержка идёт не при работе парсера, а просто при открытии директории парсером. Можно, конечно, попробовать переформировать индексы(e2fsck -D -f /dev/sdb1), но даже если это поможет, такой подход с тысячами файлов - это явное извращение. Как временное решение, можно создавать какую-нибудь tmp-директорию, в неё закидывать эти тысячи файликов, парсить их, удалять директорию, создавать новую и так далее. Это спасёт от того, что в рабочей директории парсера будет куча неиспользуемых индексов. Но это костыль.
Что мешает обрабатывать выхлоп tshark'а на лету?
А лучшее вообще какой-нибудь tcpdump натравить. Он умеет дампить в свой формат, спецификации на который открыты. При знании Си, можно разбирать его напрямую. Если неохота, сам же tcpdump умеет приводить свой бинарный дамп в читабельный вид, который опять же можно скармливать напрямую perl'овому скрипту.
Так или иначе, тому, кто проектировал эту систему и придумал тысячи файликов, надо руки оторвать.
cppmm 17.02.2012 10:39 #
+ 0 -
Пока писал, подумал, что можно на cpan.org сходить и поискать модули для парсинга. Хотя бы так. Как видно поссылке, perl'ом можно напрямую обрабатывать дампы в формате libcap. Без всяких костылей.
uscr 17.02.2012 11:12 #
+ 0 -
Костыль - сама эта система. Это типа DLP. Нам нужно получать письма, посты вконтакте, сообщения в аське, на форумах и кучу всего. Поэтому под каждый конкретный тип события пишется свой кусок кода в парсере. А систему проэктировали "на коленке" совершенно не думая о масштабировании, многопоточности и прочих прелестях. Я, собственно, потому и покинул компанию, что поддерживать эту хрень - бесконечно унылое занятие.
cppmm 17.02.2012 14:33 #
+ 0 -
Т.е. опыты провести не получится?
И код парсера тоже нет возможности показать?

Я просто уверен, что проблема либо с нагрузкой на работу с фс, либо в самом парсере. Но, что в первом, что во втором случае, узкое место именно в том, что создаётся очень много промежуточных файлов.
uscr 17.02.2012 14:55 #
+ 0 -
Да. Я там не работаю уже.
Парсер вы смотреть не хотите, я вас уверяю. Там миллиард if/then/elif. От тупит-тормозит, тут спору нет.
Проблемы очевидны. Я понимаю, откуда образуется очередь, меня волнует вопрос: почему же она становится стабильной в определённый момент?!
cppmm 17.02.2012 23:45 #
+ 1 -
Как я и говорил выше, затык скорее всего в тысячах файлов.
Первый вариант, почему именно на оперделённом моменте тормозит - набирает критическую массу созданных/удалённых файлов и при заходе в директорию с ними, пока не прочитает их всех, ждёт. За это время набегает очередь. После этого работает в штатном режиме, пока очередь не разберёт.
Второй вариант - при старте скрипта он криво собирает информацию об этих файлах(например, заносит их все в один огромный хеш, который начинает обрабатывать). Отсюда зависимость от производительности системы.
В общем, сейчас только гадать можно.
jh 17.02.2012 11:32 #
+ 0 -
задачка хорошо подпадает под теорию массового обслуживания. парсер обрабатывает с более-менее постоянной скоростью, а трафик идет не равномерно. то что не успевает обработать помещается в очередь (вроде буфера), при снижении трафика система обрабатывает из очереди, таким образом сглаживая нагрузку.
про четыре парсера. а на скольки ядрах их запускают?
jh 17.02.2012 11:37 #
+ 1 -
в качестве аналогии можно взять кассы в супермаркете. кассир - это парсер, клиенты - пакеты. к обеду набежали покупатели, образовалась очередь, к ночи разошлись. октрыли четыре кассы - покупатели обслужились быстрее.
uscr 17.02.2012 12:53 #
+ 0 -
Непонятки именно в этом моменте. Почему количество "покупателей" сначала равномерно растёт, а достигнув критического значения, остаётся стабильным. Такая картина наблюдается всегда: даже если выгнуть всех "покупателей" (rm -f *), то они опять с той же динамикой набегут к "кассам". Получается, неравномерность трафика тут не при чём.

То есть да, в обед, например, все лезут на фишкинет, очередь быстро растёт, но после обеда опять медленно возвращается к своим "стабильным" значениям.
jh 17.02.2012 13:22 #
+ 0 -
возможно дело в настройках системы.
как вариант: пока маленькая нагрузка система понижает частоту проца, нагрузка возросла - частота повысилась, обработка пошла быстрее
думаю вариантов может быть много, может быть сочетание разных факторов.
uscr 17.02.2012 13:29 #
+ 0 -
Дык нагрузка не меняется... Да и потом такие очереди появляются только у больших клиентов, а им ставится HP Proliant G7 с 10 рейдом, двумя ксеонами и 16 киллограммами оперативки - так что маловероятно, что машина "загибается"...
jh 17.02.2012 13:47 #
+ 0 -
ну тогда х.з.:-)
а вообще, так можно долго гадать.
uscr 17.02.2012 13:51 #
+ 0 -
а вообще, так можно долго гадать.

В этом и состоит священная цель данного топика.
jh 17.02.2012 14:44 #
+ 0 -
лучше, конечно, иметь возможность поковырять систему на предмет сбора статистики. по трафику, по обработке его и т.д.
P.S. не факт что выйдет каменный цветок, чисто для интереса...
P.S.S всех с наступающей пятницей:-)
uscr 17.02.2012 14:56 #
+ 1 -
Это да. Но я уволился оттуда.
le087 18.02.2012 11:22 #
+ 0 -
У меня подобная ситуация с работой, все разработчики потихоньку разбегаются, а поддерживать неведомую х..ню, напсанную на коленке становится некому. Тоже надо бежать.
uscr 18.02.2012 13:54 #
+ 0 -
А если не куда бежать, есть ещё шанс остаться последним из "помнящих" и стать неким лидером для новой команды. а там и до карьерного левелапа не далеко.

Мне бежать было куда :)
uscr 18.02.2012 13:54 #
+ 0 -
*не куда
uscr 18.02.2012 13:55 #
+ 0 -
АГРХХХХХХХХ!!!!!!!
Ну вы поняли.

Смотреть видео онлайн

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн