madf

Вобще говоря вопрос странный. Я бы еще понял если бы это были требования QA дистрибутива (как, например, в ALT Linux), но когда речь идет о персональном пользованиии, еще и под Windows... Не поймите меня неправильно, я тоже считаю что предупреждений компилятора быть не должно. Но это точка зрения программиста, а судя по вашему вопросу вы не программист. Ладно. Переменная цикла i в обоих случаях объявлена как знаковое целое, а std::vector::size() возвращает тип size_t который, обычно, unsigned int - т.е. беззнаковый. О чем, собственно, и предупреждает компилятор. Верхняя граница значений этой переменной будет примерно 2 миллиарда, а верхняя граница значений std::vector::size() примерно 4. Теоретически возможно переполнение и, как результат, некорректная работа этого цикла. На практике... На практике у пользователя вряд-ли когда-нибуть в обозримом будущем накопится 4 млрд. сообщений. Но если напрягает - смените тип на size_t.

Расскажите поподробнее про эту практику. У меня на работе по 2000-2500 онлайн пользователей на каждом из 3 серверов. Один из каналов на следующей неделе расширяем до 10 Гбит. Биллинги стоят как вкопанные с зимы. Никаких проблем.

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

Спасибо, буду смотреть.

Проблемы в системе. Либо с libstdc++, либо с компоновщиком. Еще в гугле говорят что такое может быть когда часть программы собрана gcc-3.*, а часть gcc-4.*. Сделай make clean и пересобери снова.

Проблемы в системе. Либо с libstdc++, либо с компоновщиком.

apt-get install libmysqlclient-dev

Это не ошибки

На Java? Это абону кроме авторизатора еще и целый JRE ставить?! Мне тут коллега один уже предлагал переписать авторизатор на Jave аргументируя это мягким и незаметным удобным обновлением. Я так себе и представил все эти мегабайты медленну кушающие мою оперативку и не выполняющие никаких полезных действий. Нафиг-нафиг!

Ага, точно. Стоит в кроне обновление системы, захочет оно подтянуть пакетик свежий по http, а тут бац - а вместо пакетика какая-то хрень неясная. Я бы возмутился! Или, скажем, запускаюя я браузер с 30-60 вкладками и на всех вместо нужной мне инфы грузится провайдерская фигня. А 60 адресов я не помню наизусть! Абон должен сам за своими средствами следить. А провайдер должен предоставлять качественную и надежную услугу а не задалбывать абона дурацкими сообщениями

За принудительный редирект надо пальцы тупой ножовкой отрезать. Ме-е-едленно

Сообщения в Stg работают просто. Из конфигуратора попадают в сам Stargazer. Если пользователь в данный момент авторизован и его авторизатор поддерживает отправку сообщений то оно немедленно доставляется пользователю в авторизатор. Если он не авторизован или его авторизатор не поддерживает прием сообщений то оно (сообщение) ложится в базу. При авторизации сообщения из базы доставляются и удаляются.

Не совсем понятно что делать мне ? Как это может влиять на работу стг и авторизатора? Люди жалуются что вродибы в игре толи лагает в это время толи дисконектит... Вложил сам файлик (из папки messages в инетаксесе) с самим сообщением на всякий случай. (расширение сменил) По идее короткий дисконнект

Радио-сигнал передается через электромагнитное поле, квантами которого выступают... фотоны! Все равно распространяются через отражение, но затухание слишком велико. Но вообще да, либо шутка либо шарлатанство.

Параметр FreeMb. Но есть одна тонкость: если у абона на счету есть деньги то по истечении FreeMb он будет продолжать пользоваться инетом пока не закончатся деньги.

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

id назначается пользователю в порядке чтения. А порядок чтения ни для файловой системы, ни для СУБД не определен (в запросах я не делаю сортировку).

А при чем тут Stargazer? Ограничение скорости это задача шейпера.

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

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

15-20 kpps - это абсолютно нормальный рейт у нас, иногда больше иногда меньше. как раз в то время когда стг жрет ЦПУ - pps падает (и то незначительно), но это скорее следствие, чем причина. а нормально ли что вызовы localtime проходят порядка нескольких десятков, а может и сотен раз за секунду? когда этот процесс не жрет ЦПУ - такой активности не наблюдается. осталось только понять это - причина, или следствие... а если следствие - то чего? 15-20 kpps на одного юзера. Это разве нормально? Тем более эффект будет только если эти 15-20 kpps принадлежат разным сессиям TCP и UDP. Т.е. мощный портскан или еще какая-то фигня. localtime вызывается при обработке каждой сессии (при тарификации). Если их много то и вызовов много. Но проц они не жрут, проверено. Собственно на случай 15-20 тыс. сессий от одного юзера я уже нашел решение. Осталось только протестировать. Вот после его внедрения, возможно, localtime и выйдет на передний план.

Печаль Радость

Простите, это проблема СТГ или системы в целом? Например фаерволла? Я о загрузке процессора, не о своём случае. Если загрузка по softirq то это проблемы системы (в т.ч. может быть файрвол). К стати, обсуждали уже в соседней ветке какой-то. Если загрузка по CPU то это поблемы Stargazer'а.

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

Т.е. сунуть туда скрипт, делающий накопление данных в каком-то файле для конкретного юзера, например? Я так понимаю именно эти данные СТГ дублирует в /var/log/stargazer.log и лог-файл юзеров? При изменении какого либо параметра юзера "снаружи" происходит вызов OnChange с данными юзера, именем параметра, старым и новым значением и запись в лог об изменении этого параметра.