vitalyb

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

accel-pptpd 11:55:13 up 1345 days, 21:47 и то, выключать пришлось когда в шкафу реорганизация была

Разве таблица rentcharge имеет отношение к периодическим услугам? Там же ни услуги, ни категории тарифа даже нет. Для usbox'а - usbox_charge. Как-то странно. Инструкцию смотрели?

(пальцем в небо) DNS?

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

Поднимайте как RX, перерасхода памяти или дополнительных глюков это не вызовет.

Давно туда не заглядывал. Если у вас последняя 006 и уже есть 007, то мне, похоже, стоит пересмотреть идею "никогда не обновляться на последнюю сборку" :) Вообще, основная у меня рабочая 1.9, и еще до того, как в нее начали тянуть архитектурные изменения из 2.0, меняя по ходу дела только номер минорной версии. Особенности есть, но непоняток нет вообще.

[юмор] Надо поставить второй такой же микторик и пропустить трафик через него, отправив на нем netflow на второй коллектор. [/юмор]

Это врядли. Например имеем 2 бонда по 4 интерфейса, в особых случаях пришедший с 4 интерфейсов трафик может быть отправлен в 1 физический интерфейс на другом бонде. И вне зависимости как быстро выполняется обработка окончания передачи, дескриптор будет висеть пока данные не будут отправлены. Кроме этого, при наличии scatter-gather даже на один пакет может быть приходиться несколько дескрипторов.

Веселая версия, выше мое "полгода" относится как раз к ней. Один из биллингов пришлось обновится на 006 январскую (с 003) и начался адский сюр до июня. И то, баги остались, но, вроде, не такие жестокие, ребут помогает, и знакомые баги лучше новых. По снятию абонки у нее было следующее. Редко (раз в 1-2 месяца), но случайно (могло повториться через день) во время обработки абонплаты происходил сбой, появлялась в логе ругня на пару строк и данные в БД оставалась в неверном состоянии - почти для всех абонентов на этот день в таблице rentcharge запись о снятии есть, фиксации баланса в balances нет, баланс не изменен. Соответственно на следущий день "перерасчета" не происходит т.к. в rentcharge всё верно и едем дальше как ни в чем не бывало. Как так можно было реализовать логику на БД с транзакциями и прочими ACID штуками, я совершенно без понятия. На 1.8-1.9 не сталкивался с на столько неадекватным поведением, но, само-собой, не все версии побывали в продакшене.

Некоторые коммутаторы довольно грубо полисят и результат работы TCP может не устроить, желательно все-таки предварительно проверить как оно "на самом деле".

там есть детальная статистика по трафику. И вообще, трафик - одни начисления, абонка - другие. Может у вас netflow коллектор врет, или NAS по радиусу криво отчитывается? Или не врет, а считает не тот трафик, который надо вам - вариантов может быть масса. Так и есть, без "полного погружения" в БД биллинга и в колекторы/NASы конкретно сказать что-то почти невозможно. Тут реально помочь может только поддержка биллинга. Не будете же вы давать доступ неизвестным людям с форума к биллингу? 8) Кстати, в логах биллинга и агентов ошибки есть?

списание у вас происходит за прошедшие сутки, т.е. списание за 26 появится "завтра". Точно нет превышения трафика? На мегабите с неудачным вирусом/торрентом/умной качалкой можно быстро-быстро стянуть положенные гигабайты. Можно попасть на куда более веселые глюки и полгода-год ждать стабильно работающую версию то теряя по пути, то восстанавливая разный функционал... Соответственно топикстартеру наверняка понаботится сразу и пакет поддержки подороже и стальные нервы :)

https://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg06429.html Выключайте VT-d и все сопутствующие навороты. Можно в биосе, можно не собирать драйвер, можно, наверно, опцией ядра. Вообще сходу и не скажу есть ли такая "волшабная фича", которую надо включить, чтобы стало лучше, а вот испортить всё - это пожалуйста. OK, SMP и NUMA - такие фичи, пожалуй всё :)

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

это о smp_affinity. Даже со включенным RPS надо прибивать прерывание только к одному ядру. Топик относится к 2.4 и драйверам без NAPI - такое поискать еще надо :)

http://standards.ieee.org/about/get/802/802.3.html - не оно?

логично, тогда можно сделать бридж и отфильтровать ebtables еще есть arptables, но использовать его не доводилось

/proc/sys/net/ipv4/conf/*/arp_* - особенно arp_ignore и arp_filter дока в linux/Documentation/networking/ip-sysctl.txt

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

micol можно еще txqueuelen на интерфейсах увеличить через ip link set до 10000 такой, который устроит спидтест и ваших абонентов )

micol от этого DCA зависит, можно оставить, а выключить CONFIG_NET_DMA, CONFIG_ASYNC_TX_DMA и драйвера к IOH DMA и подобным. Hardware IOMMU туда же. Хотя может и не с этим связано, perf top выше - это от нового ядра, когда оно тормозит или от старого? Как вариант еще - проверить, что на интерфейсах multiq очереди, а не sfq какой-нибудь...

micol интеловская виртуализация и VT-d выключены? DMA engine из той же оперы, надо выключать на роутере.

разграничивает доступ к общему ресурсу когда его хотят получить несколько CPU одновременно

IP Routes: 256,000 (IPv4); 128,000 (IPv6)