Высокая нагрузка на CPU

[nallien 3]

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

 

 

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

 

стрейсом посмотрев отжирающий ресурсы ЦПУ процесс - вижу что он постоянно генерит

 

stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2057, ...}) = 0

 

 

может кто подскажет почему так происходит? и что не менее важно - как полечить...

 

ни в каких логах никаких ненормальностей нет. стг в логе обзывается как 2.406, ядро 2.6.31-5

[Небесный 26]

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

СТЖ при этом пригал где-то порядка до 70-80%. Сейчас практически ЦПУ на одном месте 12-20%. В основном 15-16%.

 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
9300 root       1 -19  283m  18m 3548 S   19  0.5   1741:03 stargazer

 

Ну, это мой случай, а что может быть у вас, остается только гадать, чуть побольше нужно давать инфы, что за ОС, ну из ядра я уже понял, что это Linux. Какой при этом трафик идет, сколько абонентов онлайн.

[nallien 3]

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

СТЖ при этом пригал где-то порядка до 70-80%. Сейчас практически ЦПУ на одном месте 12-20%. В основном 15-16%.

 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
9300 root       1 -19  283m  18m 3548 S   19  0.5   1741:03 stargazer

 

Ну, это мой случай, а что может быть у вас, остается только гадать, чуть побольше нужно давать инфы, что за ОС, ну из ядра я уже понял, что это Linux. Какой при этом трафик идет, сколько абонентов онлайн.

 

да, пардон - линух, сетевухи не самые обычные (собственно машина - 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

[Kucher2 122]

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

СТЖ при этом пригал где-то порядка до 70-80%. Сейчас практически ЦПУ на одном месте 12-20%. В основном 15-16%.

Точно такая же хрень - вырастают пинги (иногда с 1 до 70) при трафике всего-то 50/30Мбит и менее 5000pps. Стоят две дешёвые сетевушки на дешёвой десктопной материнке с простеньким двухядерным целерончиком. interrupt 40-55%, в такие моменты наблюдается даже дроп пакетов. Пока надеюсь на сетевую от Intel, а то может и материнку придётся сменить. Ось FreBSD 8.1 релиз.

[madf 279]

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

СТЖ при этом пригал где-то порядка до 70-80%. Сейчас практически ЦПУ на одном месте 12-20%. В основном 15-16%.

 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
9300 root       1 -19  283m  18m 3548 S   19  0.5   1741:03 stargazer

 

Ну, это мой случай, а что может быть у вас, остается только гадать, чуть побольше нужно давать инфы, что за ОС, ну из ядра я уже понял, что это Linux. Какой при этом трафик идет, сколько абонентов онлайн.

 

да, пардон - линух, сетевухи не самые обычные (собственно машина - 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

Это вызов localtime. Я профилировал это место, оно почти не "кушает" CPU. Проблема может быть в "паразитном" трафике от юзера: 10-20 kpps вида IP-юзера -> случайный-IP создаст такую картинку (проц будет занят FlushAndRemove, а точнее именно Remove). Буквально вчера это выяснил и сейчас занимаюсь решением этой проблемы. Прошу только подтвердить условия возникновения: 10-20 kpps непосредственно перед возникновением проблемы. Я, в принципе, своими средствами это почти подтвердил, но дополнительный факты лишними не будут.

[Kucher2 122]

А не, у меня проц грузится макс на 5%, у меня просто interrupt зашкаливает. Вот сейчас например нагрузка по трафику невысокая, а такая фигня.

Это вызов localtime. Я профилировал это место, оно почти не "кушает" CPU. Проблема может быть в "паразитном" трафике от юзера: 10-20 kpps вида IP-юзера -> случайный-IP создаст такую картинку (проц будет занят FlushAndRemove, а точнее именно Remove). Буквально вчера это выяснил и сейчас занимаюсь решением этой проблемы. Прошу только подтвердить условия возникновения: 10-20 kpps непосредственно перед возникновением проблемы. Я, в принципе, своими средствами это почти подтвердил, но дополнительный факты лишними не будут.

Простите, это проблема СТГ или системы в целом? Например фаерволла? Я о загрузке процессора, не о своём случае.

[madf 279]

А не, у меня проц грузится макс на 5%, у меня просто interrupt зашкаливает. Вот сейчас например нагрузка по трафику невысокая, а такая фигня.

Это вызов localtime. Я профилировал это место, оно почти не "кушает" CPU. Проблема может быть в "паразитном" трафике от юзера: 10-20 kpps вида IP-юзера -> случайный-IP создаст такую картинку (проц будет занят FlushAndRemove, а точнее именно Remove). Буквально вчера это выяснил и сейчас занимаюсь решением этой проблемы. Прошу только подтвердить условия возникновения: 10-20 kpps непосредственно перед возникновением проблемы. Я, в принципе, своими средствами это почти подтвердил, но дополнительный факты лишними не будут.

Простите, это проблема СТГ или системы в целом? Например фаерволла? Я о загрузке процессора, не о своём случае.

Если загрузка по softirq то это проблемы системы (в т.ч. может быть файрвол). К стати, обсуждали уже в соседней ветке какой-то.

Если загрузка по CPU то это поблемы Stargazer'а.

[nallien 3]

Это вызов localtime. Я профилировал это место, оно почти не "кушает" CPU. Проблема может быть в "паразитном" трафике от юзера: 10-20 kpps вида IP-юзера -> случайный-IP создаст такую картинку (проц будет занят FlushAndRemove, а точнее именно Remove). Буквально вчера это выяснил и сейчас занимаюсь решением этой проблемы. Прошу только подтвердить условия возникновения: 10-20 kpps непосредственно перед возникновением проблемы. Я, в принципе, своими средствами это почти подтвердил, но дополнительный факты лишними не будут.

 

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

 

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

[madf 279]

Это вызов localtime. Я профилировал это место, оно почти не "кушает" CPU. Проблема может быть в "паразитном" трафике от юзера: 10-20 kpps вида IP-юзера -> случайный-IP создаст такую картинку (проц будет занят FlushAndRemove, а точнее именно Remove). Буквально вчера это выяснил и сейчас занимаюсь решением этой проблемы. Прошу только подтвердить условия возникновения: 10-20 kpps непосредственно перед возникновением проблемы. Я, в принципе, своими средствами это почти подтвердил, но дополнительный факты лишними не будут.

 

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

 

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

15-20 kpps на одного юзера. Это разве нормально? Тем более эффект будет только если эти 15-20 kpps принадлежат разным сессиям TCP и UDP. Т.е. мощный портскан или еще какая-то фигня.

 

localtime вызывается при обработке каждой сессии (при тарификации). Если их много то и вызовов много. Но проц они не жрут, проверено.

 

Собственно на случай 15-20 тыс. сессий от одного юзера я уже нашел решение. Осталось только протестировать. Вот после его внедрения, возможно, localtime и выйдет на передний план.

[nallien 3]

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

[madf 279]

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

По результатам экспериментов я получил что удаление данных о 50000 сессий проходит за приемлемое время (менее 10 сек), а вот 120000 - уже затык (более 10 минут). В обычном режиме за интервал срабатывания FlushAndRemove накапливается для удаления порядка 10000 сессий (при чем каждая сессия аггрегирует в себя кучу пакетов, суммарный pps может быть довольно высок). Проблема в том что алгоритмическая сложность алгоритма FlushAndRemove O(N^2*log(n)). Время работы его растет очень быстро.

И на фоне и так большого pps на всех юзеров прибавка 15-20 kpps на одного почти не заметна. Я смотрел по объемам NetFlow-трафика - есть небольшое увеличение, но на общем фоне абсолютно незаметное.

[nallien 3]

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

 

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

[nightfly 1 221]

Kucher2

сетевухи нормальные ткните и fastforwarding=1

[Kucher2 122]

Kucher2

сетевухи нормальные ткните и fastforwarding=1

Ткнул.

[madf 279]

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

 

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

У нас на общем фоне незаметно.

 

Stg получает информацию о пакетах (или уже аккумулированные данные о сессии в случае NetFlow). Из этих пакетов он строит сессии, идентифицируя их по двум парам: адрес:порт -> адрес:порт. С периодичностью в 30 секунд он удаляет неактивные сессии. Нормальная ситуация это когда пользователь генерирует много пакетов, но они попадают в небольшое число сессий. Например может быть 10 kpps, но они принадлежат одной сессии. Ненормальная ситуация это когда каждый новый пакет от юзера начинает новую сессию. Удаление 100000 сессий нагружает систему.

[nallien 3]

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

[nightfly 1 221]

Kucher2

сетевухи нормальные ткните и fastforwarding=1

Ткнул.

igb? никогда не пылал к нему любовью но всеже лучше чем рилтек

 

У меня такая картина приблизительно на НАСах с ~350-400Mbit + 170-200Kpps что считаю вполне нормальным в силу недорогих карточек которые использую (типа HP NC360T)

[nallien 3]

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

 

вот еще немного strace, возможно прольет свет? что собственно сделать, чтобы отследить чем этот процесс занят?

 

[madf 279]

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

 

вот еще немного strace, возможно прольет свет? что собственно сделать, чтобы отследить чем этот процесс занят?

 

Это цикл, но это не подвисание. Я эти трейсы видел уже сто раз, и даже трассировал отладчиком.

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

[nallien 3]

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

[madf 279]

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

Более 200000 разных ip-port за 30 секунд? Мне кажется, это не нормально. А примерно при такой нагрузке проблемы и начинаются.

git://madf.dyndns.org/stg.git

Но предупреждаю, что там изменения в траффкаунтере серьезные, может трафик неправильно считать. Надо за ним следить внимательно.

[nallien 3]

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

[madf 279]

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

Это я про то что торрент к этому отношения не имеет.

[nallien 3]

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

 

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

 

если же обнаруженная Вами проблема наблюдается только в случае более 200000 соединений по разным направлениям в течении 30 секунд (что приблизительно равно более 6500 соединений в секунду) - то такое их (соединений) количество можно выгрести и на 1-2 активно работающем торрент-клиенте... в принципе я не мониторил именно количество соединений во время проблемного роста нагрузки - так как тому не было даже косвенных предпосылок. теперь гляну, но, все же, сдается мне проблема не тут...

 

надеюсь вместе разберемся все же. после выходных попробуем выложенную Вами версию на тестовом сервере.

[madf 279]

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

 

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

 

если же обнаруженная Вами проблема наблюдается только в случае более 200000 соединений по разным направлениям в течении 30 секунд (что приблизительно равно более 6500 соединений в секунду) - то такое их (соединений) количество можно выгрести и на 1-2 активно работающем торрент-клиенте... в принципе я не мониторил именно количество соединений во время проблемного роста нагрузки - так как тому не было даже косвенных предпосылок. теперь гляну, но, все же, сдается мне проблема не тут...

 

надеюсь вместе разберемся все же. после выходных попробуем выложенную Вами версию на тестовом сервере.

Обычно у торрент-клиентов все-таки стоит ограничение поменьше. Тут проблема в том что на общем фоне pps одиночного пользователя почти незаметен. Я пришел к таким выводам по косвенным факторам: небольшому росту объемов NetFlow-трафика (считанные проценты) и резким увеличением количества записей в дереве пакетов TRAFFCOUNTER. При чем для "зависания" нужно чтобы все эти 200000 записей принадлежали одному пользователю и были сгенерированы примерно в одно время.