NetXMS Support Forum

День добрый!

Использую NetXMS для мониторинга довольно большой сети, на сегодня 680 узлов.
Есть такая проблема. Так получается что в случае внепланового отключения сервера, например
по питанию, или вис он пару раз, разрушается структура базы Mysql и появляются потерянные узлы.
Сейчас мы скидываем базу в бэкап и возвращаемся к бэкапу, теряя всякий раз день работы.

Но все-таки хочется стабильности. Что можно сделать для улучшения устойчивости базы.
Поможет ли переход на postgress? Или можно настроить существующий mysql? Версия сервера
5.1.61-4. Работаем под CentOS 6, ядро 2.6.32-279

Quote from: Alexey Sartakov on January 28, 2013, 12:20:05 PM
День добрый!

Использую NetXMS для мониторинга довольно большой сети, на сегодня 680 узлов.
Есть такая проблема. Так получается что в случае внепланового отключения сервера, например
по питанию, или вис он пару раз, разрушается структура базы Mysql и появляются потерянные узлы.
Сейчас мы скидываем базу в бэкап и возвращаемся к бэкапу, теряя всякий раз день работы.

Но все-таки хочется стабильности. Что можно сделать для улучшения устойчивости базы.
Поможет ли переход на postgress? Или можно настроить существующий mysql? Версия сервера
5.1.61-4. Работаем под CentOS 6, ядро 2.6.32-279

ну вы опишите конкретнее настройки мускуля, какой движок Используется? Пошаманьте над его настройками.

и вообще почему такой важный инфраструктурный элемент без упс?

то что сыпиться база при некорректном отключении больше вина самой базы данных и машины, вернее их настроек.

Посмотрите историю по двум DCI на самом сервере (они создаются автоматически):
* Database writer's request queue (DCI data) for last minute
* Database writer's request queue (other queries) for last minute

Quote from: SKYnv on January 28, 2013, 09:08:52 PM

ну вы опишите конкретнее настройки мускуля, какой движок Используется? Пошаманьте над его настройками.

и вообще почему такой важный инфраструктурный элемент без упс?

то что сыпиться база при некорректном отключении больше вина самой базы данных и машины, вернее их настроек.

Спасибо, Коллега! Где-то также я и подумал, поэтому и написал.

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

Что касается настроек - их на самом деле мало. Шаманство ради шаманства я не приветствую, а рекомендации с удовольствием выслушаю.
/etc/my.cnf

[mysqld]
datadir=/opt/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
tmpdir=/tmp
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
default-character-set=utf8
thread_cache_size=8
 

Также поднастроен и ext4 на котором крутится mysql

/dev/sda3 on /opt type ext4 (rw,noatime,barrier=0,data=writeback,nobh)


Quote from: Alex Kirhenshtein on January 28, 2013, 11:33:32 PM
Посмотрите историю по двум DCI на самом сервере (они создаются автоматически):
* Database writer's request queue (DCI data) for last minute
* Database writer's request queue (other queries) for last minute

Спасибо Alex,

После апгрейда до 1.2.5 все существующие internal DCI переключились в UNSUPPORTED
Пока не могу понять так надо или это у меня ошибка.

не настройки Netxms, а настройки самого мускуля, это скорее всего в
/etc/my.cnf искать или где у вас там его конфиг храниться.

Ну да, что я и показал.

Quote from: Alexey Sartakov on January 29, 2013, 06:58:55 PM
Ну да, что я и показал.

как то маловато, из этого непонятно ничего. у меня иннодб.
база растет на гигабайт за 4 часа картинка #1
общий размер порядка 400гб

статистика netxms

Quotenetxmsd: sh st
Total number of objects:     35237
Number of monitored nodes:   476
Number of collectable DCIs:  21295


[client]
port            = 3306
socket          = /tmp/mysql.sock
default-character-set=utf8

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
character-set-server=utf8
character-set-client=utf8
init-connect='SET NAMES utf8'
back_log = 50
max_connections = 100
max_connect_errors = 10
table_open_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 64M
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = MYISAM
thread_stack = 192K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
log-bin=mysql-bin
binlog_format=mixed
slow_query_log
long_query_time = 2
server-id = 1

#*** MyISAM Specific options

key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover

# *** INNODB Specific options ***

innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 2G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120


[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 8192


картинка 2 это загрузка базы в течении часа
картинка 3 это момент когда netxms начинает сбрасывать в базу данные.

по картинке 3 давно хотел разработчиком вопрос задать, да все времени не было. Это нормально? Netxms ровно каждый час сбрасывает информацию в базу видимо это Так отрабатывает dci poll или какой другой poll, может быть как-нибудь динамически распределить эти записи и опросы? Исходя из количества dci, равномерно на час.

Раз в час по умолчанию стартует housekeeper - он удаляет из базы устаревшие записи (из логов и собранных данных). Возможно есть смысл увеличить интервал между запусками - это регулируется параметром HouseKeepingInterval.

Quote from: Victor Kirhenshtein on January 30, 2013, 04:29:55 PM
Раз в час по умолчанию стартует housekeeper - он удаляет из базы устаревшие записи (из логов и собранных данных). Возможно есть смысл увеличить интервал между запусками - это регулируется параметром HouseKeepingInterval.

ну в принципе без разницы, железо справляется. но может "размазать" его по времени? отдельной настройкой конечно. потому что если увеличить интервал то нагрузка на базу наоборот возрастет.
из картинки видно что отрабатывает 3 минуты при текущем размере базы если увеличть то дело будет еще хуже, и это не подошли dci еще к своему Retention time тогда я думаю нагрузка возрастет еще больше.

Alex, Victor!

Как мне восстановить мониторинг самого сервера. Нужные DCI после апгрейда до 1.2.5 стали unsupported.
Любой другой нод я бы добавил вручную, но этот-то всегда  присутствовал в системе

Quote from: Alexey Sartakov on January 31, 2013, 11:16:30 AM
Alex, Victor!

Как мне восстановить мониторинг самого сервера. Нужные DCI после апгрейда до 1.2.5 стали unsupported.
Любой другой нод я бы добавил вручную, но этот-то всегда  присутствовал в системе

add dci->origin->internal

Тут скорее всего сложнее проблема. Если DCI есть, но стали UNSUPPORTED, это означает, что сервер больше не считает, что данный узел - это сам сервер. Скорее всего где-то в дереве появился его дубликат. Проверьте в Entire Network в соответствующем субнете. Если это так, то удалите неправильный узел и перезапустите сервер.