производительность от языка зависит сильно, т.к. если под веб писать на ruby, то это в разы быстрее чем оные будут писать на пехапе... так вот чем больше человек на этом языке писал, тем больше опыта реализации практических задач у него есть... ну а далее надо еще заметить, что старички программисты занимаются в основном тимлидерством, аналитикой, архитектурой и т.д...
Lupus, что?
ps. Кстати в Германии есть ребята с прямым каналом до РФ, через который пирят немцам всю РФ и почти всё СНГ... если так, о птичках... что решает задачу для них одной кнопкой.
Какая разница как достигать цели? И что такое админ? У нас админы и циски админят, но от этого мы их раут инженерами не зовем, т.к. для них это второстепенно. Админ может скинуть грамотную заявку в саппорт и все можно решить на уровне провайдера. Ну и из своего опыта могу сказать, что такое нужно либо мутным клиентам, которые имеют какие-то терки с зарубежными жителями, либо тем кому счета за зарубежный трафик рисуют... ну и ддос конечно же предовратить забугорный хотят. Да и какая разница network administator или server administrator? senior unix administator?
И надо бы еще напомнить про кучу контор со спутниковым инетом, которые через европу ходят, регионалы в основном... список их сеток смысла не имеет, т.к. они большие и ходит через них какая-то часть русских и приличное количество европейцев, в т.ч. и наземных... а айпишничек динамический из пулов по /20, открытие чего пропускает приличную часть европейцев и даже азиатов каких-то.
Выгрибать из RIPE сетки по RU и кодам СНГ конечно можно, но там шлака полно и надо искать колизии какие-то и работа эта не на одну неделю, т.к. по шлаку она ручная будет... а сеток там прилично. Проще найти хорошее место с хорошим присутсвием пиров по СНГ и попросить отфильтровать это на уровне BGP.
если на уровне маршрутизации, то как раз влияет, т.к. решается в итоге через задницу...
а там оказывается очень юморные люди работают...
если цисковские L2/L3 свичи не тянут, то доказывать это с помощью tcpdump является оригинальной затеей... к тому же по L2/L3 циска свитчит почти в полный рост, а достижение почти полного роста влечет за собой провалы в транспорте, т.к. шизеет все на уровне патчкордов и стандарта 1000Base-TX... выходом является переход на 10 гигабит, что есть выход, но влечет за собой дополнительные затраты по фрагментации... кстати внутри своей сетки очень замечательно спасают jumbo frames...
кстати о фрагментации, которая там очевидно пьет кровь... это есть типичная проблема сетки с сотошными и гигабитными портами... либо все на гигабит, либо все на сотку.... только вот если у себя все на гигабите, то это не значит что из-за проблем с фрагментацией где-то, твою сетку не будут подфлуживать ретрансмитами.... ларчик открывается выставлением правильного MTU на фронтах... как это доказать с помощью tcpdump я не знаю, вполне возможно и они тоже, но они ему верят, т.к. видят последствия и доп нагрузку на айпишный стек... если изучать трафик на низком уровне с помощью соответствующих средств от той же циски, то приличную долю проблем от этой фрагментации невозможно незаметить... эврика короче... на это кажется уже все кому только можно наступили, но всегда приятно пообщаться с людьми которые победили это самостоятельно.
и самое главное, что внутресетевую проблему можно лечить с помощью перехода с меди на оптику, что в принципе дороже чем переход на десятигиговую медь... победа неожиданного кризиса инфраструктуры есть позитив... респект им и уважуха... на за наезды на циску с помощью tcpdump надо ставить двоечку.
балансировка по кэшам...
тоже эврика конечно... подозреваю, что она у них не идеальная, т.к. более правильно использовать шареный индекс с hash ranges, т.к. только тогда достигается максимально эффективное и правильное заполнение кэшей... они про это не пишут, возможно у них так и есть, но подозреваю что если бы это было, то достижением похвастались бы... мы же яндекс типа... ладно, мы тоже до этого когда-то, давно причем, сами додумались, т.к. эту задачу более красиво решить нельзя... ну в плане для универсальных вещей, а не для какой-то конкретной специфики для которой вообще хэши не нужны и можно тупо математически обосновать равномерное распределение на базе какой-то простейшей функции...
imho распределение по кэшам у них отстой, т.к. распределение без дублирования слишком популярных объектов сами понимаете есть отстой... за кэширование им двоечку надо ставить, т.к. могли бы и додуматься... ну типа даже intel до этого додумалась и сделала кэши двух уровней в процах... эх... хотя в нашем случае можно все делать на одном, но на схеме отобразить и двумя.
ну и отстой еще потому, что в случае выхода одного кэша из строя вполне очевидно происходит шиза на уровне хэшфункции и вся система какое-то время курит пока все опять нормально заполнится... дайте мне бабла за консультацию - научу как надо... шареный индекс по hash range, рейтинг популярности объектов, дистрибуция популярных в востребованные места... хотя уже научил, бобла можно и не давать, но буду верить в натуральные респекты.
мониторим в RRD постоянно...
цепляться к словам не буду, т.к. RRD есть средство исключительно для построения графиков и если сливать с периодами в 5 минут, то толку от этого мониторинга иногда не бывает... усредняет все зараза... хотя как настроить... мониторить надо алярмингом в реальном времени при превышении выставленных значений полученных в результате тестирования... и как только в матюгальник закричит, то надо сразу залезать в проблемное место и смотреть.
если вернуться к жамбе, то выгоду в UDP для внутренней сетки конечно же придумать сразу можно, т.к. если предположить, что размер ответа пролезает в жамба пакет, то это просто ппц... а жамба у нас на наших любимых em до 16 кил, правда свичи зараза столько не тянут... ну если в девять кил пролезаем, то выгода на лицо... и сеточка сразу по pps-ам разгружается... так шо информируем... ну надо пистон гуру поисковым вставить, что бы они там все внутренние репли в 9 кил вписали и вот оно долгожданное счастье... тогда протокол взаимодействия туповатым получается - вместо запроса на ретрансмит пакета тупо посылаем еще один запрос... у меня кстати яндакс кошелек для респектов есть... смайлики не ставлю, т.к. много их надо... собственно надо бы еще заметить готовность ко всему этому нашей любимой freebsd, что вас не может не радовать...
Лоадбалансиг..
Двоечка мужики, чистая двоечка... в природе есть ospf, bgp, wccp... и балансить на уровне RR DNS уже совсем не модно, т.к. оно в случаях со слонами непредсказуемое иногда бывает... а балансеры тут ботлнек в чистом виде... поди с гигабитной дыркой наверное... нет, это не наш метод... мы бы внутри смаршрутизировали все на какой-то фейк, а на sfront-ы поставили либо wccp агенты либо ospf/bgp ... причем с последним, если коленка понимает что на ней собирают, можно получить нужное количество отказоустойчивых раздающих дырок... лоад шаринг виз кост екьюал патх.. как-то так... балансит ясен перенц по ксорке между src и dst айпи... экономия денег в чистом виде, т.к. делается все на наших любим свичах с гигабитными дырками и ни разу не в cpu... а если в URL добавить чуток поддоменов, то можно обойтись и без заглядывания в Host: и чо там в get пишут... если пересчитать на брендовые балансеры, то данный рецепт экономит пару сотен тыщ американских денег и во внешний мир смотрят честные гигабиты фронтов...
сейчас точно бабок буду просить...
ну если к слову, то балансеры по стейтам на синфлуде можно в ракообразную серьезно поставить, что сами понимате для бизнеса есть риск... пару-тройку похожих на валид mpps-ов и всё, алес, на графиках убытки и всё такое... а я вот предлагаю врагу 12 дырок с синкуками/синкэшем в лицо выставить... пускай мучаицо... ну там по accf_http еще напильничком чуть чуть и все нормально будет... а если там балансеры без стейтов, то см предыдущий абзац ибо они тогда вообще там не нужны... ну и синкуки главное подхачить надо и в секрете держать на что там хэш заменили...
ps. удачи... вот посмотрите, они рано или поздно так и сделают, т.к. лучше пока еще никто не придумал...
Банально на самом деле.
Ограничение в 32 мегабайта на скрипт считается слишком зверским.
при ддос атаках некоторые там и сидят...
при нагрузке на тяжелые php/cgi скрипты и т.д... легко может уйти... 100 httpd по 30mb и вот он родимый свап.
а sshный ttyp уже консолью не считается?
ssh пользователь работал в консоли и своими действиями вызвал подвисание сервера
crash туда пишет в незакрытые записи wtmp при след буте... а на wtmp вроде fsync делается и стартовая запись потеряться не может... но т.к. там в консоли никого не было, то и записей нет...
нет
вот пример крашей из-за хардварного зависалова, питания и т.д:
xxxxx ttyp0 83.237.x.x вт 6 ноя 15:10 - crash (03:02)
xxxxx ttyp2 91.76.x.x пт 2 ноя 11:00 - crash (03:52)
xxxx ttyp0 77.232.x.x чт 1 ноя 16:12 - crash (22:39)
