суббота, 21 апреля 2012 г.

fork vs pthread

Попытка построить ядро моего диплома, включающего сбор ip, tcp и http заголовков с отправкой их в mysql для последующего анализа на базе одного процесса провалилась - инсерт сильно дольше приёма очередного пакета при большом трафике, в БД каша получается.
Попытался делать так - форкать отдельный процесс под отправку данных в БД и передавать ему обработанный пакет через пайп - тот же эффект.
Стал одним процессом собирать запросы в shared memory,  дочерним зеркалировать участок памяти и из зеркала слать. Синхронизацию делал через posix semaphores. Что получил - при большом трафике тот процесс, что загребает трафик, постоянно заходит в свою критическую зону, а отсылающий процесс просто висит в ожидании, отжирая целое ядро.

Уже было отчаился, но решил переписать с тредами - и, о диво! Оно заработало!!!
Механика такая: создаём 2 треда - для сбора трафика и для отправки.
Первый в pcap_loop callout раздирает пакет и формирует VALUE список, добавляя его в своей критической секции в шаренный через анонимный mmap участок.
Второй тред в своей критикал цепляет содержимое вышеуказанного участка в свой буфер и после выхода из критикала спокойно инсертит одним запросом. Сегодня вечером выкатил на продакшн, было около 3 тыс. инсертов в секунду.
Вот сам код, непричёсанный ещё, правда:
 https://github.com/speedcorezombie/pget/blob/master/pget.c

среда, 11 апреля 2012 г.

Настольный Horus Heresy

Не удержался и заказал себе на амазоне настольник Horus Heresy )
Уже приехал в шипито )
Собственно, сама игрулька:


Где-нибудь в начале мая отправлю )

Ещё прикол с аллиедом

Клиент жалуется - на двух железках входящая скорость нормальная, под 50 Мбит/сек, исходящая скорость низкая, около 3х Мбит/сек. На третьей всё ок. Все железки разные, оси - на 2х фряха, на одной винда. Проблемы у виндового и фряшного серваков. Свич - AT8000GS-48 с прошивкой 2.0.0.26.
Смотрю - либо на серверах косяк, либо свич неисправен, ибо шейперов нет.
В конце концов нашли засаду - выключенный negotiation на портах свича. Вырубал в своё время с целью переключения портов принудительно в режим 100f. Врубил негоциэйшн - и пошла скорость )
Скорость до сотни пришлось зарезать rate-limit.

Итого: по-дефолту лучше negotiation оставлять.
Хотя был случай, когда клиент наоборот просил вырубить его.

понедельник, 9 апреля 2012 г.

github

Для удобства синка сделал ключик и секцию в конфига ssh:

Host github.com
        User speedcorezombie
        HostName github.com
        IdentityFile /home/accessd/.ssh/id_rsa

Теперь процесс выглядит так:

git clone http://github.com/speedcorezombie/pget.git
поработали, git add file
git commit -m 'some fixes'
git remote add speed git@github.com:speedcorezombie/pget.git
git push -u speed master

пятница, 6 апреля 2012 г.

Международные посылки

Прикинул тут, у меня уже примерно 23-24 отправки. Из них 18 - шипито, US, 1 - хандтек, UK, остальное штейнар, DE. Ещё было несколько с тинидила - чайна, но там всякая мелочёвка, типа кабелей.

Проблем, по сути было 3:
2 с немецкими посылками, связаны с особенностями работы конкретного почтового отделения.
В первом случае посылка месяц висела в состоянии "Покинула место МО", на почте мне этот месяц говорили, что у них ничего нет, пока я не узнал в отделе претензий валовый номер мешка, ушедшего с сортировки. Когда они сверили с мешком, то заявили, что посылку отправили обратно.
Еле перехватил на Нагатинской.
Второй случай - 3 недели висит в том же "Покинула место МО". Сегодня пошёл на почту - они нашли мою коробку. Оказалось, что таможенники себе все документы оставили и типа как коробка таможню прошла, в отделение прибыла, но без бумажки с печатью. А тётушки не знали, что с ней делать и извещение посылать не стали. Но отдали в руки.
А вот третья проблема - подвисание на 2 недели в состоянии прибытия на сортировку в Лос Анжелес похоже была связана с тем, что в коробке были эпоксидные глины и всякие краски. Видимо, в связи с этим задержали.
После этого зависания посылка оказалась на просторах этой страны и через неск. дней её привезли.

Итого - в среднем, проблемы возникают с каждой 8 посылкой. Это если смотреть в отрыве от способа доставки.

четверг, 5 апреля 2012 г.

билайн и блокировка айпишников

эти болваны из билайна по писульке или звонку неизвестного представителя силовых структур заблокировали адрес сервака, на котором сидит около тысячи акков и 3 тысячи доменов.
При этом никаких абуз нам не писали, просто взяли и заблокировали.
Когда нам хлынул потом обращений от клиентов, стали разбираться - как так?
Что характерно, клиенты сначала звонили провайдеру с жалобой - через вас сайт не работает, через другого прова работает. А билайн им и говорит - "мы никогда не блокировали и не блокируем адреса, звоните хостеру". И это при том, что интернеты завалены постами "билайн блокирует ip адрес".
На второй день телефонных разговоров с этими недоумками выяснилось наконец, что проблема не в аварии, про которую они нам весь прошлый день твердили, а да, по предписанию от ментов заблокирован адрес, потому что на нем домен, который этому менту не понравился.
Убирать блокировку, равно как и сообщать домен, из-за которого адрес заблокирован, они не хотят. Что за предписание - тоже не говорят.
При этом клиентам они продолжают говорить, что проблема у хостера, т.к. билайн белый и пушистый никогда блять ничего не блокирует.
Придётся менять для всех клиентов айпишник и вдобавок каждому доказывать, что билайн им наврал.

Что характерно - это единственный такой больной на голову пров. Больше таких выкрутасов ну у кого не видел.

И да, кстати, в прошлом году они уже такое делали с другим сервером. Благо, на нём было несколько человек всего.

вот, кстати, пара статей на тему:
http://tsapel-man.livejournal.com/15146.html
http://vorugamnet.livejournal.com/635.html