nallien

интересуют БП в любом состоянии (можно нерабочие, подгоревшие и т.д.) без внешних повреждений. мощностью от 300 Вт. сгодятся от HP пролиантов, компаков, IBM, DELL. нужны для ремонта, запчастей и не профильного использования обращайтесь в асю 293874748, скайп nallien и мыло - nallien(собака)neveru.com

продано

950 грн

ап, ждет хозяина. доставка в любой город Украины, можно наложенным платежом "новой почты" или аналог

фото:

Почти новая, поработала 2-3 месяца. Цена - 1000 грн. связаться можно мылом - nallien AT neveru.com

http://neveru.com/2010/11/kak-proverit-svoyu-skorost-interneta/ вот писал по этому поводу не так давно. на всеобъемлемость не претендую, но вродь все основное расписал.

мне казалось что последние реализации нашумевшего у оператров uTP (мюТП) протокола от разработчиков uTorrent'a очень даже может генерировать огромные количества пакетов. тем более что речь не идет о одном пользователи, и такое количество пакетов может генерироваться одновременно многими пользователями. то что это ненормально - это понятно, но то что это происходит - это факт. многие (в том числе и мы) боремся АЦЛами на роутерах и шлюзах. с переменной успешностью, так как сам протокл тоже видоизменяется. кроме того генерация большого количества соединений с большим количеством разных айпи и по произвольным портам - как раз стандартное поведение торрент-клиентов. и, как мне кажется, при онлайне в 500 человек сгенерить они могут очень приличный ппс даже в штатном режиме работы... если же обнаруженная Вами проблема наблюдается только в случае более 200000 соединений по разным направлениям в течении 30 секунд (что приблизительно равно более 6500 соединений в секунду) - то такое их (соединений) количество можно выгрести и на 1-2 активно работающем торрент-клиенте... в принципе я не мониторил именно количество соединений во время проблемного роста нагрузки - так как тому не было даже косвенных предпосылок. теперь гляну, но, все же, сдается мне проблема не тут... надеюсь вместе разберемся все же. после выходных попробуем выложенную Вами версию на тестовом сервере.

эээмммм... я кажется нигде не упоминал о 200000 разных соединений за 30 сек. вы ничего не путаете?

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

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

+1 на биллинг, как бы, ни скорость каналов, ни нагрузка....

хм. понятно, спасибо разъяснения, есть ли способы (кроме очевидных ограничений количества соединений, или, предположим, по SYN-пакетам)? ну а в целом - у нас проблемы выходит в другом... но, возможно, косвенно связано...

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

уточняю 15-20 kpps - это на всех юзверей средняя норма. я к тому что зависимости проблемы от pps или количества трафика - вообще нет.

15-20 kpps - это абсолютно нормальный рейт у нас, иногда больше иногда меньше. как раз в то время когда стг жрет ЦПУ - pps падает (и то незначительно), но это скорее следствие, чем причина. а нормально ли что вызовы localtime проходят порядка нескольких десятков, а может и сотен раз за секунду? когда этот процесс не жрет ЦПУ - такой активности не наблюдается. осталось только понять это - причина, или следствие... а если следствие - то чего?

да, пардон - линух, сетевухи не самые обычные (собственно машина - HP-шный DL380 g3) и проблем с softirq нет, 3-й и 4-й цпу обрабатывают прерывания от сетевых. а сетевые там BCM5703X. пробовал и на 2.6.35 - там где софтовые очереди от гугла - честно говоря с разбрососм по всем процам ставало только хуже - но это и понятно - есть тому причины, узкое место тут не трафик и не пакеты изучая на протяжении месяца структуру трафика - ничего аномального выявить не удалось да в том-то и проблема - нет зависимости от трафика и ппс - так бы можно было грешить на упирание в планку возможностей железа. к примеру 150 мбит и около 15k pps - нагрузка бешеная, ЛА доходит до 2,5 и в другой день 300 мбит, 25k pps - нагрузка как и положено 0,3-0,5... кто бы мне далекому объяснил что это такое? stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2057, ...}) = 0

собстно ситуация - обычно с стг все впорядке, нареканий не вызывает, ЛА на железяке где он стоит порядка 0,3-0,4. но периодически (при чем прямой зависимости от каких-то внешних факторов отселить не удалось) один из тредов стг съедает 100% ЦПУ. на долго. На часы, иногда на сутки. потом попускает и все снова нормально. такое поведение обычно происходит при достаточно высокой нагрузке и ближе к часам-пик, но никаких ДДОС, паразитного трафика или чего прочего нет. нет ни больших ппс (они даже немного меньше в это время), ни большого трафика. ничего. счетчиком используем нетфлоу, с недавних пор он живет на другой машине - но проблему это тоже не решило. замечено что если стг не передавать информацию о трафике (например прибить агента нетфлоу) - нагрузка через какое-то время нормализуется. но отнюдь не сразу стрейсом посмотрев отжирающий ресурсы ЦПУ процесс - вижу что он постоянно генерит stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2057, ...}) = 0 может кто подскажет почему так происходит? и что не менее важно - как полечить... ни в каких логах никаких ненормальностей нет. стг в логе обзывается как 2.406, ядро 2.6.31-5

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

вот тоже как раз тестируем 2.6.35+ (RPS+RFS) - у нас лучше нигде не стало, я бы даже сказал хуже ( возможно не те задачи жрут большую часть времени, и разброс очередей по процам ничего не дает. ну и инфы пока мало... понятно что фишка оч полезная, но толк от нее будет только при определененных проблемах. железо - двухпроцессорный (2хXeon 2.8) 6Гб.

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

ну, по моим данным в сети на 1к сегодня обычно 200-300 мбит. а такого канала достаточно, с учетом процентного распределения по тарифам, дабы продать относительно говняный, но тариф. и не факт что мелкие плюсы этой сети в 1к пользователей не переплюнут "большие плюсы" билайна. на рынок пришел серьезный игрок - с ним придется считаться, возможно что-то уступить и в чем-то проиграть. но абонентов достанется всем при должном качестве предоставления услуг (и это далеко не в первую очередь качество самого доступа к Интернету)

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

эти тариф на наге описывались лет шесть назад, тогда их никто не захотел. сейчас быдлайны и прочие их запустили - и теперь их захотели и сделали все. для пользователя - тарифы удобные, для оператора - тоже что и было. на таком тарифе (ну скажем 100 мбит, по 10 гиг каждый день или 300 гиг в месяц, потом скорость падает - и стоит это 60 грн, к слову это релаьный тариф) трафика качающий абонент потребляет столько же столько и на "честном" безлимите 2 мегабита (за те же 60 грн). а если учесть что средний абонент потребляет порядка 50 гиг - то 80% пользоватлей до лимита и не дойдут. и получат высокую скорость за 60 грн. все довольны, кроме тех у кого нету хотя бы 200-300 мбит каналов... увы - так большие вытесняют малых.

поковыряем с удовольствием )