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 очень даже может генерировать огромные количества пакетов. тем более что речь не идет о одном пользователи, и такое количество пакетов может генерироваться одновременно многими пользователями. то что это ненормально - это понятно, но то что это происходит - это факт. многие (в том числе и мы) боремся АЦЛами на роутерах и шлюзах. с переменной успешностью, так как сам протокл тоже видоизменяется. кроме того генерация большого количества соединений с большим количеством разных айпи и

эээмммм... я кажется нигде не упоминал о 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 - там где софтовые очереди от гугла - честно говоря с разбрососм по всем процам ставало только хуже - но это и понятно - есть тому причины, узкое место тут не трафик и не пакеты изучая на протяжении месяца структуру трафика - ничего аномального выявить не удалось да в том-то и проблема - нет зависимости от трафика и ппс - так бы можно было грешить на упирание в планку возможностей желез

собстно ситуация - обычно с стг все впорядке, нареканий не вызывает, ЛА на железяке где он стоит порядка 0,3-0,4. но периодически (при чем прямой зависимости от каких-то внешних факторов отселить не удалось) один из тредов стг съедает 100% ЦПУ. на долго. На часы, иногда на сутки. потом попускает и все снова нормально. такое поведение обычно происходит при достаточно высокой нагрузке и ближе к часам-пик, но никаких ДДОС, паразитного трафика или чего прочего нет. нет ни больших ппс (они даже немного меньше в это время), ни большого трафика. ничего. счетчиком используем нетфлоу, с недавн

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

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

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

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

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

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

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