Создаем dedicated Mysql server [FreeBSD 7.X / AMD64]

Технические вопросы по UTM 5.0
Ответить
Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Создаем dedicated Mysql server [FreeBSD 7.X / AMD64]

Сообщение kaN5300 »

Вобщем-то вопросов здесь я задавать особо не буду, просто поделюсь своим решением. Около месяца назад я тут бегал по темам и гуглил на предмет того, как уживается нетап и платформа AMD64. Вобщем, было принято такое решение. Приобрести мощный сервер на оптероне, при этом упор будет делаться на ОЗУ и дисковую подсистему (16 гигов ECC RAM и RAID 1+0).

В итоге получим связку из двух серверов, подключенных между собой по гигабиту. На одном i386 и крутятся основные компоненты биллинга (ядро, радиус, веб-морда), а на другом исключительно FreeBSD 7.X + Mysql. Ничем лишнем этот сервер не занимаем. Вместо фаервола просто грамотная настройка сервисов.

Теперь переходим к самому главному. Как выжать максимум из дорогого выделенного сервера СУБД?

Скажу сразу, что оптимизация из соседних веток, которая у нас использовалась на мускуле с i386 / 4G RAM не проканала. Сервис mysqld было невозможно остановить.

http://forum.sysadmins.su/index.php?showtopic=32120

Пришлось на этот раз не тупо воровать чужие конфиги, а вкурить каждую опцию и понять, что она значит. На данный момент make.conf выглядит вот так:

Код: Выделить всё

CPUTYPE=opteron

.if ${.CURDIR:N*/usr/ports/databases/mysql50-server} == ""
WITH_CHARSET=cp1251
WITH_XCHARSET=all
WITH_COLLATION=cp1251_general_ci
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes
BUILD_STATIC=yes
CONFIGURE_ARGS+= \
--with-innodb \
--enable-assembler \
--enable-community-features \
--enable-profiling \
--enable-static \
--without-debug
.endif
Кому есть что добавить - пишите, для этого тему и создал.

Теперь пару слов о sysctl и параметрах ядра.

sysctl.conf:

Код: Выделить всё

vfs.read_max=128 # должно повысить sequential read performance
kern.maxfiles=65536 # На всякий случай, но должно хватить и дефолта
kern.maxfilesperproc=32768 # Чтобы не получать "Too many open files..." но с нашей базой должно хватить дефолта
kern.timecounter.hardware=TSC # Советуют ставить, может дать прирост
kern.threads.max_threads_per_proc=15000 # Повышает планку для максимального числа тредов в libthr
kern.threads.max_groups_per_proc=15000 # Повышает планку для максимального числа тредов в libthr
Вобщем тут ничего особенного.

Раздел с /var/db/mysql маунтим вот таким образом:

Код: Выделить всё

/dev/da0s2d /var/db ufs rw,async,noatime 0 0
async: повышает file I/O, можно пользоваться только если вы уверены в защите сервера по питанию и в своих бекапах.

noatime: перестает маркировать время последнего обращения к файлам на ФС, дает незначительный прирост I/O

[0 0] Первый 0 дизейблит FS dump, второй убирает fsck и quoacheck

Также рекомендуется делать newfs с максимальным размером блока, чего я сразу не сделал при установки, а потом было уже влом переносить данные раздела чтобы его правильно проформатить.

Переходим к самому главному - mysql. Нетап вроде рекомендует юзать ветку 5.0, и к томуже в современных бенчах пишут, что 5.1 часто сливает 5.0. По этому экспериментировать не стали, установили из портов 5.0.90. На старом сервере была 5.0.45 - не обновляли, ибо "работает - не трогай".

my.cnf (напротив некоторых парамов оставлю коменты):

Код: Выделить всё

[mysqld]

port            = 3306
socket          = /tmp/mysql.sock

back_log = 100
max_connections = 32
max_connect_errors = 4294967295 #ноль здесь не означает "дизейбл", по этому гуглирование предложило установить максимально возможное значение connect error
table_cache = 5526
max_allowed_packet = 128M
max_heap_table_size = 256M
sort_buffer_size = 512M
join_buffer_size = 8M
thread_cache_size = 18
thread_concurrency = 18 # Число конкурентных тредов рекомендуют ставить число ядер * 2. Я поставил 18 имея 6 ядер
query_cache_size = 256M
query_cache_limit = 4M
ft_min_word_len = 4
thread_stack = 256K
transaction_isolation = REPEATABLE-READ # repeatable-read выигрывает у read-committed по тестам
tmp_table_size = 4G # Обязательно выделяем больше места из памяти для tmp-таблиц. Временные таблицы будут создаваться в групповых отчетах по трафику
long_query_time = 3
tmpdir = /var/db/tmp
innodb_file_per_table # Об этом много писали на этом форуме. Однозначно стоит ставить
log_warnings
skip-name-resolve # На всякий случай отрубили резолвинг, настроили гранты по IP. Всё равно пара учеток всего.

#*** MyISAM Specific options

key_buffer_size = 1G
read_buffer_size = 2M
read_rnd_buffer_size = 16M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
skip-federated

# *** INNODB Specific options ***

innodb_additional_mem_pool_size = 2G
innodb_buffer_pool_size = 8G
innodb_file_io_threads = 4 # Написано тут: http://mysqlha.blogspot.com/2008/10/more-background-io-threads-for-innodb.html
#innodb_force_recovery=1 # Придется включать если посыпется база
innodb_thread_concurrency = 18
innodb_log_buffer_size = 32M
innodb_log_file_size = 512M
innodb_log_files_in_group = 4
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
Вот как-то так. Немного обидно, что мы не реализуем полночтью дисковую подсистему. В какти я не научился диски мониторить, но на глазок в systat -v в дежурном режиме tps скачет (5 - 75). Получается, зеркало востребовано для отказоустойчовости, а стрипинг решает только при импорте и экспорте БД полностью. Основные процессы происходят в ОЗУ.

Также неожиданностью стал расход полосы канала. Средняя скорость передачи данных 11 килобайт, а мы готовились к каким-то бОльшим объемам.

Ниже приведу графики загрузок с комментариями:

LAN. Пик в 120кб хз откуда взялся.
Изображение

Всплеск lavg вызван генерацией группового отчета по трафику за апрель
Изображение

Памяти в запасе всегда остается около гига
Изображение

Активность буферного пула около 10 операций записи. Чтение иногда подскакивает до 40.
Изображение

Буферный пул постоянно растет
Изображение

Чекпоинт ейдж полезен для подбора размеров лога
Изображение

ИОпсы для InnoDB
Изображение

InnoDB Raw-риды
Изображение

Ну и счетчики основных команд
Изображение

PS:

Забыл сказать про ядро. Кернел GENERIC. Ничего в нем не меняли. В версии 7.3 шедуллер используется ULE, который лучше всего подходит для mysql. Гонял sysbanch, все ядра загружаются равномерно. К SMP подсистеме претензий нет.

AntonLemon
Сообщения: 55
Зарегистрирован: Вт авг 16, 2005 11:29

Сообщение AntonLemon »

Добрый день

Спасибо большое за интересную информацию. Однако, как мне кажется, результатт не достигнут. Одной из основных задач было правильно отдать 16Г пямяти под нужды мускуля обслуживаюшего БД ютэма. Почему-то мне кажется, что при данных настройках мускуль займет максимум 2-3G памяти. Каковы размеры таблиц discount_transactions* у Вас?

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

Код: Выделить всё

last pid: 54300;  load averages:  0.13,  0.07,  0.07    up 3+13:42:08  23:20:07
55 processes:  1 running, 54 sleeping
CPU:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 7729M Active, 5976M Inact, 1447M Wired, 600M Cache, 1647M Buf, 118M Free
Swap: 8189M Total, 20K Used, 8189M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
44769 mysql      29  44    0 12671M  7704M ucond   0   3:22  1.56% mysqld
discount_transactions_all: 60m
discount_transactions_iptraffic_all: 35m

dk
Сообщения: 424
Зарегистрирован: Чт авг 10, 2006 08:52

Сообщение dk »

Чем была вызвана необходимость использовать выделенный сервер БД, да ещё настолько мощный?

Размер базы у Вас вполне нормальный. Притормаживать могут только отчёты, но тут достаточно просто прикрутить свой ЛК.

Gezm0
Сообщения: 95
Зарегистрирован: Вт июн 24, 2008 22:00

Сообщение Gezm0 »

dk писал(а):Чем была вызвана необходимость использовать выделенный сервер БД, да ещё настолько мощный?

Размер базы у Вас вполне нормальный. Притормаживать могут только отчёты, но тут достаточно просто прикрутить свой ЛК.
Забавный вопрос. Сколько у вас суточного трафика и сколько пользователей?

Lord Kaho
Сообщения: 22
Зарегистрирован: Чт май 21, 2009 12:41

Сообщение Lord Kaho »

Настройки кеширования можно?

Весь query_cache

wingman
Сообщения: 136
Зарегистрирован: Чт дек 07, 2006 15:36
Контактная информация:

Сообщение wingman »

kaN5300 писал(а):

Код: Выделить всё

last pid: 54300;  load averages:  0.13,  0.07,  0.07    up 3+13:42:08  23:20:07
55 processes:  1 running, 54 sleeping
CPU:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 7729M Active, 5976M Inact, 1447M Wired, 600M Cache, 1647M Buf, 118M Free
Swap: 8189M Total, 20K Used, 8189M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
44769 mysql      29  44    0 12671M  7704M ucond   0   3:22  1.56% mysqld
discount_transactions_all: 60m
discount_transactions_iptraffic_all: 35m
Ыхыхыы...

discount_transactions_all = 1.4G
discount_transactions_iptraffic_all = 1.9G
за 20 дней...
Кто бы что тут посоветовал для волшебного "убыстрения" на ксеоне 16ядер 8гиг =)

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

kaN5300 писал(а):

Код: Выделить всё

discount_transactions_all: 60m
discount_transactions_iptraffic_all: 35m[/quote]
Илюх, ты правда думаешь что, чтобы разгрести 100Мб надо 8 процов и 16Гб памяти? Или ошибся?

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

каждая табличка по гигу. Индексы 360М просто списания, 290М - списания по трафику. Все шевелится достаточно шустро на тазу с двумя ядрами и 7ГБ ОЗУ. Из модификациев - отдельно SSD под /var для временных файлов.
Ну и тюнинг конфига мускула.

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

kirush писал(а):
kaN5300 писал(а):

Код: Выделить всё

discount_transactions_all: 60m
discount_transactions_iptraffic_all: 35m[/quote]
Илюх, ты правда думаешь что, чтобы разгрести 100Мб надо 8 процов и 16Гб памяти? Или ошибся?[/quote]

1) Дискаунты жестко чистились, там только последние 3 месяца сейчас
2) Откуда цифра 100Мб?
3) Процов не 8, а один, причем самый дешевый
4) Рассчетный срок службы сервера 5 лет. За это время база прилично подростет.

Единственное, за что обидно, дисковая подсистема мало востребована оказалась.

Ответить