[Sysadmins] nfacct блокирует mysql

[Sysadmins] nfacct блокирует mysql

[Гусев В.Ю.]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

День добрый!

Помогите побороть постоянную блокировку таблиц коллектором 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. Может быть вешать баги в 
багзиллу?

Спасибо.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Sysadmins] nfacct блокирует mysql

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 5215 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

Re: [Sysadmins] nfacct блокирует mysql

[Гусев В.Ю.]

[-- Attachment #1: Type: Text/Plain, Size: 3796 bytes --]

В сообщении от 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]