В сообщении от 3 декабря 2009 13:54:50 автор Slava Dubrovskiy написал:
> > Подскажите, где я неправильно сконфигурил nfacct.
> 
> Конечно.
> Если
> sql_refresh_time[10m]: 600
> sql_history[10m]: 10m
> То тогда какой смысл делать update?
Если я правильно понял английскую инструкцию, то sql_history - это размер 
отрезка времени, за который данные аккумулируются. Т.е. в пределах этого 
отрезка не вставляются новые строки, а данные добавляются к уже существующим 
(командами update).
Это как раз сделано, чтобы сократить количество строк.
В документации написано, что параметр sql_history совершенно не связан (is 
fully disjoint) с sql_refresh_time, т.к. второе это просто промежутки времени 
через которые производится запись в mysql. 


> Добавьте тогда
> sql_dont_try_update[10m]: true
> Это на порядок быстрее.
Я попробую, хотя предупреждают, что это может привести к потере данных.
Как я понял в данном случае nfacct будет аккумулировать данные на собственных 
счётчиках и потом генерить одну команду insert.

> 
> Также вы посчитали какого размера у вас будут таблицы если вы будете ВСЕ
> это писать в базу (я так понимаю трафик с циски)?
Пока помещаюсь. Потом буду фильтровать ненужное.

> Вот советы по оптимизации
> 
>    * Keep the SQL schema lean: include only required fields, strip off
> all the others.
Ага, я первым делом удалил ненужные поля (vlan,mac,...)
nfacct сразу разорался, где они. Видимо не такие уж они ненужные...

>      Set the 'sql_optimize_clauses' configuration key in order to flag
> pmacct you are
>      going to use a custom-built table.
Это я тоже сразу включил.

>    * Avoid SQL UPDATEs as much as possible and use only INSERTs. This
> can be achieved
>      by setting the 'sql_dont_try_update' configuration key. A
> pre-condition is to let
>      sql_history == sql_refresh_time. UPDATEs are demanding in terms of
> resources and
>      are, for simplicity, enabled by default.
Включил - блокировок пока не наблюдается

>    * If the previous point holds, then look for and enable
> database-specific directives
>      aimed to optimize performances ie. sql_multi_values for MySQL and
> sql_use_copy for
>      PostgreSQL.
Тоже включил.

>    * MyISAM is a lean SQL engine; if there is no concurrence, it might
> be preferred to
>      InnoDB. Lack of transactions can reveal painful in case of
> unsecured shutdowns,
>      requiring data recovery. This applies to MySQL only.
Таблицы у меня innodb


-- 
С уважением,                          mailto: gusev.v.u@pkb.ru
 Влад Гусев                              icq: 153452402
начальник сектора телекоммуникаций и ТО   
отдела автоматизации                     тел: (8442) 562024 (вн.2121)
ФКБ "Петрокоммерц" в г.Волгограде        тел: +7-904-774-0333