nightfly

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

тобишь нужен "биллинг но не биллинг" ниразу? дык тогда точно кастом же ЗЫ даже не знаю о какой такой "глюкавости стг" вы заявляете в данном контексте.

Ну у вас же какая-то видимо "волшебная специфика" под которую вам не подходят вышеназванные (стг,абилз,ноудинай) решения? Что нестандартно - то по определению кастом.

написать самому?

[sarcasm] У меня микроволновка работает на 2.4ггц, но ее почемуто не видно ни с телефона, ни с ноута, ни с нетбука... даже когда разогреваю суп не начинает светиться ssid zhrachka.... печаль печаль [/sarcasm]

С какой радости он на эту сеть смотреть должен? Цифры в частоте похожие?

Либо для начала отрубить нафиг в биосе звук, юсб, HT и в ядре отключить apic. Вот и узнаете в железе ли точно проблема.

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

Это собственно железная проблема с 98% вероятностью. На вид интеррапт сторм напоминает

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

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

В биллинг - наваять гибкий редактор PBR чтобы можно было делать в будущем с пользователями по любым критериям что захочется. Благо писанины там всего-ничего. У меня в свое время качки (if ($dayly_bandwidth>=tariff_bandwidth(35%)) {...) пресовались в резервный канал (а че добру простаивать?), потом пришли к мягкому шейпу, теперь таки ничего с ними не делаем учитывая ничтожные количества тех же качков. Собственно это довольно нужная фичка которая причем реализуется довольно просто и пригодится может не только для подавления качков. Банальнейший пример - пихнуть бизнес абонентов либо как

Посоветуйте сделать ipfw deny ip from any to user_IP - это точно решит все проблемы. Можно конечно и просто кабель выдернуть но это не так технологично...

Дык в чем проблема? Если в договоре предусмотрена максимальная позволенная вами нагрузка на полосу юзером (домашние тарифы принято как бы считать по 30-35% в разрезе суток) - давить. Если при составлении договора на домашних абонентов такое не предусмотрено - чего теперь рыпаться. У нас четко оговорено что на пользовательских тарифах рекомендуемой нагрузкой является до 35% загрузки на максимальной скорости предусмотреной тарифным планом. Далее качки в зависимости от текущей фазы луны могут попадать в общий пайп размером =(тарифная_скорость(35%)*количество пользователей). Получается довольн

Поросенок Петр как бы намекает.

А шо... кумедно От лиш не потрібно робити обличчя цеглиною і казати "ой у якій країні ми живемо" - так ніби не знали.

Тыкнуть инсерт с рандомными данными в цикл помагает чтобы получить заданные условия. Допустим это еще "более-менее", ну плюс еще можно нормально поальтерить индексы и получить что-то около полутора секунд. Теперь считаем на наглядном примере. У меня детальная статистика ведется только для пользователей "по траффику" которых где-то 0.1% от общего числа. На текущее число табличка detailstat_03_2011 весит всего-то 625 мег и имеет около 6М записей. Селект с веаром по индексным полям получается что-то около 10 секунд на дуальном зеоне. Теперь смотрим в топ и пугаемся при осознании того к

в памяти хранить в смысле "утечь"?

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

А что делать еще старгейзеру при невозможности почитать/пописать в базу?

а он цуко все живет и живет...

А вы попробуйте бенчмаркнуть выборку по одной табличке где скажем 50М записей или по табличке где 500к - думаю разницу очень хорошо прочувствуете =) Размазывание данных разной степени используемости, по разным табличкам - неплохой перфоменс ход, и называется нормализацией. Хотя детальная статистика которая там пишется черти-как и у 99.99% нормальных людей - отключена, она в этом модуле далеко не самая глобальная проблема. А prepared statements выглядит удачно в данном контексте, хотя подозреваю что просто так, мускуль не будет кешировать идущие не подряд /не всегда единообразные запрос

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

EPIC Fail!

еще с большим нетерпением ждем рц3