madf

Работа с БД тоже разная бывает. OLAP или OLTP? Вот об этом я и писал в своем посте, один сайт использует несколько БД (сейчас 3, постепенно добавлются) с таблицами больше 1М записей и постоянно растет (OLAP), а остальные используют таблицы с небольшим кол-вом данных (15-20к записей), но интенсивно (OLTP). OLTP и OLAP это не размер базы. Это принципиально разный характер нагрузки. OLTP подразумевает интенсивную заливку данных, без какого-либо процессинга. Сотни тысяч транзакций на запись - OLTP. OLAP наоборот, подразумевает практически персистентные данные, по корторым производятся

Но это же прекрасно! Надо еще один параметр - сумма после которой начинаем от абонента отмораживаться

Работа с БД тоже разная бывает. OLAP или OLTP?

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

По этому бекапы и UPS наше все!

Железо-то не сыпется? Может винты дохнут или оперативка?

Можно FreeRADIUS подружить с базой Stargazer.

В разных jail? Как там разруливается сеть? Используют ли они одну и ту-же message queue? Ну и общий вопрос: зачем надо держать два биллинга одновременно? Общесистемное. К сети отношения не имеет. Это один из вариантов IPC.

Если jail поддерживает Message Queues то можно. Если нет — теоретически можно, но только без локального выполнения скриптов. Сам я с jail никогда не работал.

Там же четко написано что не получилось создать Message Queue. Наверное надо еще конфигурировать jail.

У нас с тестами. А у вас?

Наличие модульных тестов и квалификация программистов слабо коррелируют. Равно как и качество продукта.

Не знаю как кто, но я прицепился к слову "Отныне" а не ко вспышкам на Солнце.

Ох уж эти журналисты... „Отныне у админов появилась хорошая отмазка: Интернет "тупит" из-за космических бурь“ — эта отмазка существовала еще со времен BOFH

Не позорьтесь. Послушайте, я вам не кретин и не новичок зеленый. Я этими языками зарабатываю себе на жизнь последние 7 лет. Я на них писал биллинговые системы (не только Stargazer), системы управления автоматикой, мониторинг для АЭС и огромную финансовую систему. Мне есть на чем их сравнивать. То что на плюсовый проект нельзя набрать 400 индусов чтобы они пилили код за миску риса - это, в конечном итоге, даже плюс. Я знаю плюсы и минусы обоих языков, и в C++ их больше. Я не преподношу C++ как единственно верное решение. Мне он самому во многом не нравится. Но выбор невелик. Писать сейчас ч

Нашли чем гордиться..Каждый раз, когда приходится править C++ код не покидает мысль "каким идиотом надо быть, чтобы вообще начать проект на С++?". ответ очень банальный ) каждый второй заказчик всегда спрашивает, аочему у Вас не на C/C++ это ж производительней так же всюду пишут в интернете но почемуто не пишут что некоторые системы не на C/C++ работают с базами аболнентов в 10-20 раз больше чем у тех кто такие вопросы задаёт C++ используют не только из-за быстродействия. И еще, размер базы абонентов больше относится к быстродействию СУБД, нежели бизнес-логики.

Нашли чем гордиться..Каждый раз, когда приходится править C++ код не покидает мысль "каким идиотом надо быть, чтобы вообще начать проект на С++?". Во-первых, я этим не горжусь. Но C объективно хуже. Во-вторых, есть причины писать на C++. Из мейн-стрима это наиболее вменяемый кросс-платформенный язык. А на не-мейн-стрим будут ругаться пользователи проекта.

Ну учитывая контекст, надеюсь ты же понимаешь, что ни о каких нормальных решениях виртуализации/паравиртуализации типа xen/esx речи идти тут не может в принципе? В лучшем случае можно предположить что-то типа vbox на винде который будет тушиться на ночь, с мотивацией "мамка за електричество заругает" либо "крузис чтобы не тормозил". Мне как-то OpenVZ и KVM больше по душе Я раньше тоже был против виртуализации, но тут вот с товарищем развернули одну систему - очень даже удобно и гибко вышло, чем если все на одном сервере держать. ProxMox на хост, базу в KVM, все остальное в OpenVZ - с десято

На C++, не оскорбляйте!

За что? ... А что так? Нормальное же решение!

sFlow — протокол с потерями. Точнее єто протокол для сбора статистики а не для точного подсчета трафика. Можно отдавать. Через плагин захвата. Запретить обновлять нельзя.

Покупайте лицензию. Через cap_nf, через зеркалирование трафика или через свой плагин. Нет.

Функция TRAFFCOUNTER::Process. Как кормить — можно посмотреть в одном из множества cap-плагинов. Например в cap_nf.

Ну почему люди никогда не ищут легких путей? Если надо собирать трафик вне биллинга — используйте NetFlow и cap_nf. Если нельзя использовать NetFlow — напишите свой модуль захвата, благо там делов — сформировать штуку похожую на IP-пакет и скормить ее одной единственной функции. Если надо вести учет трафика offline, „задним числом“ — свяжитесь со мной и я добавлю еще одно поле с меткой времени в эту функцию. Нет, надо нагородить костылей и начать писать прямо в базу совершенно не читая документацию, в которой сказано что Stargazer базу читает только при старте а потом только пишет.

Читая эту историю я вспоминал похожий случай со мной, произошедший примерно 3 года назад. Как-то обнаружил дикие потери при пинге на шлюз провайдера. Выждал немного (мало ли, может техничесие работы какие проводятся), потом позвонил в ТП и начал объяснять проблему. Мне тоже рассказывали про "Вы пробовали выключить и включить? А колесо пинали? А какой у вас код ошибки?" на что я гордо заявлял что я крутой перец и вообще у меня линукс и предлагал им логов заслать. Как же мне было стыдно, когда за пол часа до прихода ихнего инженера я выяснил что это у меня подгоревшая сетевушка была. ТП уваж