03.12.2009 08:05, Гусев В.Ю. пишет:
> День добрый!
>
> Помогите побороть постоянную блокировку таблиц коллектором netflow nfacct.
> Настроено следующее:
> ------------nfacctd.conf--------------------------
> daemonize: true
> syslog: daemon
> interface: breth0
> aggregate: tag, src_host, dst_host, src_port, dst_port, proto
> nfacctd_time_new: true
> plugins: mysql[10m], mysql[h]
> sql_host: data-serv
> sql_db: pmacct
> sql_table[10m]: acct_10mins
> sql_table[h]: acct_hourly
> sql_table_version: 2
> sql_passwd: acct
> sql_user: acct
> sql_refresh_time[10m]: 600
> sql_refresh_time[h]: 3600
> sql_history[10m]: 10m
> sql_history[h]: 1h
> sql_history_roundoff[10m]: mh
> sql_history_roundoff[h]: h
> sql_optimize_clauses: true
> pre_tag_map: /etc/pmacct/pretag.map
> ------------nfacctd.conf--------------------------
>
> Ситуация такая. После запуска сервиса через указанное в sql_refresh_time время
> таблицы mysql блокируются и начинаются транзакции insert и update.
> Транзакции идут, идут и через следующие sql_refresh_time появляются следующие 
> блокировки таблиц, предыдущие при этом ещё не снялись.
> В итоге через день имеем целую цепочку блокировок (порядка десятка).
> nfacct при этом работает, ошибок в логах нет, но со стороны подлезть в таблицы 
> уже не получается. Любой запрос виснет "наглухо" пока не прервёшь блокировки.
> К тому же при этом в процессах висит множество процессов "nfacctd: MySQL 
> Plugin -- DB Writer", которые не завершаются по команде "service nfacctd 
> stop". Для того чтобы перезапустить nfacct приходится вручную прибивать эти 
> процессы.
> Подскажите, где я неправильно сконфигурил nfacct.
Конечно.
Если
sql_refresh_time[10m]: 600
sql_history[10m]: 10m
То тогда какой смысл делать update?
Добавьте тогда
sql_dont_try_update[10m]: true
Это на порядок быстрее.

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


И настоятельно рекомендую почитать документацию. В частности хоть
http://www.pmacct.net/FAQS-0.12.0rc3

Вот советы по оптимизации
Q18: I find interesting store network data in a SQL database. But i'm
actually hitting
     poor performances. Do you have any tips to improve/optimize things ?
A: Few hints are summed below in order to improve SQL database
performances. They are
   not really tailored to a specific SQL engine but rather of general
applicability.
   Many thanks to Wim Kerkhoff for the many suggestions he contributed
on this topic
   over the time:

   * Keep the SQL schema lean: include only required fields, strip off
all the others.
     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.
   * Don't rely automagically on standard indexes but enable optimal
indexes based on
     clauses you (by means of reports, 3rd party tools, scripts, etc.)
and pmacct use
     the most to SELECT data. Then remove every unused index.
   * Run all SELECT and UPDATE queries under the "EXPLAIN ANALYZE ..."
method to see
     if they are actually hitting the indexes. If not, you need to build
indexes that
     better fit the actual scenario.
   * Sometimes setting "SET enable_seqscan=no;" before a SELECT query
can make a big
     difference. Also don't underestimate the importance of daily VACUUM
queries: 3-5
     VACUUMs + 1 VACUUM FULL is generally a good idea. These tips hold
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.
   * Disabling fsync() does improve performance. This might have painful
consequences
     in case of unsecured shutdowns (remember power failure is a
variable ...).


-- 
WBR,
Dubrovskiy Vyacheslav