Добрый день!
Ставил ли кто нить на 7ую ветку? А то предстоит замена машины, возникла мысль, сразу на 7ку или по старинке на 6.2?
2ой вопрос: Что включить в ядро (options) сразу, чтобы потом не пересобирать по 10 раз? И выложим в FAQ
FreeBSD & netup
Сам жду седьмого релиза. Нет привычки ставить на рабочие сервера бету. И не мешало бы в sysctl подкрутить число файловых дескрипторов, размер буфера сокета и число тредов на процесс. Бывает полезно. Фаер само собой. Стоит также зафильтровать порт 9996 udp (netflow) по табличке с адресами железяк, равно как 1812 udp и 1813 udp (это радиус) и 11758 tcp и 12758 tcp (это ядро биллинга). Как именно это делать и делать ли вообще - вам виднее, но радиуса и netflow я бы прикрыл. Насчет опций в ядре - оно будет и на GENERIC работать, единственно там можно подкрутить максимальный размер сегмента данных, на серверах с гигом памяти и более. Сверх этого я никаких особых опций не заметил, которые нужны были бы именно биллингу. Если кто может добавить по теме, пишите.
sysctl vfs.read_max по дефолту 8.
Увеличение до 32 даёт заметный выигрыш скорости дисковой подсистемы. Стоит поиграться со значениями вплоть до 1024 на реальной нагрузке. Контролировать эффективность - systat -v. Изменения на лету - абсолютно безболезненны, проверено. ;)
Ну и файловую систему в /var/db/mysql стоит форматировать с максимальным размером блока (65536). Выигрыш заметен.
PS: если будет 7-ка, и особенно в паре с SMP, то options sched_ule.
Увеличение до 32 даёт заметный выигрыш скорости дисковой подсистемы. Стоит поиграться со значениями вплоть до 1024 на реальной нагрузке. Контролировать эффективность - systat -v. Изменения на лету - абсолютно безболезненны, проверено. ;)
Ну и файловую систему в /var/db/mysql стоит форматировать с максимальным размером блока (65536). Выигрыш заметен.
PS: если будет 7-ка, и особенно в паре с SMP, то options sched_ule.
Итого имеем по советам пользователей:
Тюнинг FreeBSD:
Жесткий диск:
Создаем отдельную партицию для /var/db/mysql
с размером блока 65536:
newfs /dev/партиция_для_mysql -b 65536
console:
vfs.read_max 32
В некоторых случаях понадобится увеличить максимально допустимый размер приемного буфера в операционной системе. (C) Netup
kern.ipc.maxsockbuf=10485760
net.inet.udp.recvspace=10485760
net.local.dgram.recvspace=10485760
net.inet.udp.maxdgram=100000
ядро:
options DEVICE_POLLING
options IPFIREWALL
options IPDIVERT
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
options DUMMYNET
options TCP_DROP_SYNFIN
Давайте обсудим какие параметры Вы бы еще включили и надеюсь это когда нибудь войдет в документацию
Сам заинтересован, т.к. предстоит собирать новую машинку. В принципе по defaultу всё работало на ура.
Может будут какие либо комментарии и по mysql?[/i]
Тюнинг FreeBSD:
Жесткий диск:
Создаем отдельную партицию для /var/db/mysql
с размером блока 65536:
newfs /dev/партиция_для_mysql -b 65536
console:
vfs.read_max 32
В некоторых случаях понадобится увеличить максимально допустимый размер приемного буфера в операционной системе. (C) Netup
kern.ipc.maxsockbuf=10485760
net.inet.udp.recvspace=10485760
net.local.dgram.recvspace=10485760
net.inet.udp.maxdgram=100000
ядро:
options DEVICE_POLLING
options IPFIREWALL
options IPDIVERT
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
options DUMMYNET
options TCP_DROP_SYNFIN
Давайте обсудим какие параметры Вы бы еще включили и надеюсь это когда нибудь войдет в документацию
Сам заинтересован, т.к. предстоит собирать новую машинку. В принципе по defaultу всё работало на ура.
Может будут какие либо комментарии и по mysql?[/i]
Забыто одно из самых главных.
По дефолту, на freebsd лимит памяти на данные процесса - 512 мег.
options MAXDSIZ="(2100000000UL)"
options MAXSSIZ="(2040*1024*1024)"
options DFLDSIZ="(1024*1024*1024)"
Даёт такую картину использования памяти:
Насколько я понимаю, для i386 это потолок в рассчёте на процесс.
С mysql всё просто (*):
sort_buffer_size = 96M
read_buffer_size = 96M
read_rnd_buffer_size = 16M
myisam_sort_buffer_size = 128M
thread_cache_size = 16
query_cache_size = 96M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
max_heap_table_size = 128M
innodb_buffer_pool_size = 1700M
# WARNING! Dangerous without battery on raid cache
innodb_flush_method=O_DIRECT
Внимательно читаем формулу, которую нам пишет сервис при старте в лог. Иначе при излишнем увеличении потребляемой памяти - вылетим за пределы лимита. Фря при этом проста как валенок - молча грохает процесс.
Ещё, на 6-ках у меня везде:
[mysqld]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
PS: Когда придёт время пора апгрейда, я буду-таки делать отдельную машину под i386 под ядро, и отдельную машину под amd64 под основную базу. Sql slave машину так и оставлю под i386, чтобы иметь возможность запустить там в авральном режиме ядро при смерти основного. В режиме обычной репликации нагрузка там копеечная.
(*) - Данные с боевого slave с 4-мя гигами памяти, под i386. Из них доступно для ОС - 3.0Г. Лимиты ядра - указаны выше. Средняя нагрузка на двухядерник - в районе 4%. Бодро поднимается до 160 в момент дампа, и уверенно держится на 200% при запуске самописных аналитик в 4 экземплярах.
По дефолту, на freebsd лимит памяти на данные процесса - 512 мег.
options MAXDSIZ="(2100000000UL)"
options MAXSSIZ="(2040*1024*1024)"
options DFLDSIZ="(1024*1024*1024)"
Даёт такую картину использования памяти:
Код: Выделить всё
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
47949 mysql 38 96 0 2202M 2043M ucond 27.8H 5.71% mysqld
С mysql всё просто (*):
sort_buffer_size = 96M
read_buffer_size = 96M
read_rnd_buffer_size = 16M
myisam_sort_buffer_size = 128M
thread_cache_size = 16
query_cache_size = 96M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
max_heap_table_size = 128M
innodb_buffer_pool_size = 1700M
# WARNING! Dangerous without battery on raid cache
innodb_flush_method=O_DIRECT
Внимательно читаем формулу, которую нам пишет сервис при старте в лог. Иначе при излишнем увеличении потребляемой памяти - вылетим за пределы лимита. Фря при этом проста как валенок - молча грохает процесс.
Ещё, на 6-ках у меня везде:
[mysqld]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
PS: Когда придёт время пора апгрейда, я буду-таки делать отдельную машину под i386 под ядро, и отдельную машину под amd64 под основную базу. Sql slave машину так и оставлю под i386, чтобы иметь возможность запустить там в авральном режиме ядро при смерти основного. В режиме обычной репликации нагрузка там копеечная.
(*) - Данные с боевого slave с 4-мя гигами памяти, под i386. Из них доступно для ОС - 3.0Г. Лимиты ядра - указаны выше. Средняя нагрузка на двухядерник - в районе 4%. Бодро поднимается до 160 в момент дампа, и уверенно держится на 200% при запуске самописных аналитик в 4 экземплярах.
Угу, забыл, сенькс. 8)
Ещё доли процента может дать монтирование каталогов var/db/mysql и каталогов с деталкой с флагом noatime.
Вообще, по тюнингу mysql рекомендую сайтик с длинным урлом: http://www.mysqlperformanceblog.com/
Ещё доли процента может дать монтирование каталогов var/db/mysql и каталогов с деталкой с флагом noatime.
Вообще, по тюнингу mysql рекомендую сайтик с длинным урлом: http://www.mysqlperformanceblog.com/
У самого тоже реолизовано - UTM работает на FreeBSD i386, mysql на FreeBSD amd64. Плюс на amd64 поднят NFS сервер и файлы детальной статистики перегоняются на его массивы. Благо, get_nf_direct работает под amd64. Но читал что Solaris очень хорошо работает на многопроцессорных машинках с mysql... Может кто-то заморачивался, а то очень хочется попробовать...
А это куда в ядро? А что за цифры? Можно поподробнее?atdp03 писал(а):Забыто одно из самых главных.
По дефолту, на freebsd лимит памяти на данные процесса - 512 мег.
options MAXDSIZ="(2100000000UL)"
options MAXSSIZ="(2040*1024*1024)"
options DFLDSIZ="(1024*1024*1024)"
Вот маленький итог общей работы, всем спасибо за участие:
viewtopic.php?p=31190#31190
Если будут еще добавления - описывайте в этой теме...буду добавлять.
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
В общем так =)
sysctl.conf:
## kernel
# Maximum socket buffer size
kern.ipc.maxsockbuf=1048576
# Maximum pending socket connection queue size
kern.ipc.somaxconn=4096
# Maximum number of sockets avaliable (portrange?)
kern.ipc.maxsockets=16424
# Maximum number of files
kern.maxfiles=65536
# Maximum files allowed open per process
kern.maxfilesperproc=32768
# mbuf (65k = 144m memory in kernel)
kern.ipc.nmbclusters=65536
# Some versions of MySQL make frequent queries of the system time, which on FreeBSD
# returns a very accurate but somewhat expensive to gather time stamp.
# MySQL performance can be improved by reducing the accuracy (and increasing the performance)
# of the time query mechanisms in FreeBSD. For example, the TSC-based time counting mechanism,
# which can be used on some systems, is substantially cheaper. You can use the
# kern.timecounter.choice sysctl to specify which timecounter to use. See kern.timecounter.hardware
# sysctl to query the available time counters. TSC may be unsafe on some (older) SMP configurations,
# and in most power-saving modes, as the rate of the time counter can change. RobertWatson is currently
# investigating exposing cheaper time mechanisms with lower resolution appropriate for use by applications.
#kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware=TSC
Прошу обратить внимания на последний параметр.
За счет уменьшение точности ответов при запросах времени, получаем существенный выигрыш скорости работы mysql.
У меня выигрыш был примерно 30%.
Причем очень явно: ставим параметр - есть прирост, ставим старый - нет прироста.
Смотрим kern.timecounter.choice и выбираем из имеющихся вариант.
И ставим его в kern.timecounter.hardware.
Потом, ядро.
# Поддержка многопроцессорности
options SMP
options IPI_PREEMPTION
Можно попробовать
options SCHED_ULE
# no debugging
nooptions WITNESS
nooptions INVARIANTS
nooptions DIAGNOSTIC
nooptions INVARIANT_SUPPORT
# Для mysql
#options MAXDSIZ="(1024*1024*1024)" # max memory for process
options MAXDSIZ="(2*1000*1000*1000)" # max memory for process
На i386 MAXDSIZ не ставится в 2 гига (2*1024*1024*1024)
Потом, /etc/make.conf
# Сразу говорю, это для core 2 duo
CPUTYPE=prescott
CFLAGS=-march=prescott -mtune=prescott -O2 -pipe
CXXFLAGS+=-march=prescott -mtune=prescott -O2 -pipe
COPTFLAGS=-march=prescott -mtune=prescott -O2 -pipe -fomit-frame-pointer
PTHREAD_LIBS=-lthr
.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
PTHREAD_LIBS=-lthr
CFLAGS+= -O6
CONFIGURE_ARGS+= \
--disable-profiling \
--with-pthread \
--with-big-tables \
--with-innodb \
--with-named-thread-libs='-lpthread -D_THREAD_SAFE' \
--enable-assembler \
--disable-shared \
--with-mysqld-ldflags="-all-static" \
--with-client-ldflags="-all-static" \
--with-unix-socket-path=/tmp/mysql.sock \
--enable-static \
--disable-dependency-tracking
.endif
Потом, /etc/malloc.conf
Очень интересно сделан конфиг для malloc.
Чтобы его сделать, надо выполнить команду
ln -s ajHRuz /etc/malloc.conf
=)
Это убирает debugging в malloc вызовах.
Потом /boot/loader.conf:
vm.kmem_size="536870912"
vm.kmem_size_max="536870912"
Потом /etc/libmap.conf
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.1 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2 libthr.so.2
Ну и часть конфига mysql, отвечающая за innodb:
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 1G
innodb_data_file_path = innodb_file.db:10M:autoextend
innodb_file_io_threads = 4
innodb_force_recovery=0
innodb_thread_concurrency = 8
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 4M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 120
innodb_file_per_table = 1
Все это проверялось на FreeBSD 6.2
В результате super-smack выдает:
foreach a ( 1 2 3 4 5 6 7 8 9 0 )
foreach? super-smack select-key.x 10 1000 | grep select_index
foreach? end
select_index 20000 0 0 56859.37
select_index 20000 0 0 47745.35
select_index 20000 0 0 49197.10
select_index 20000 0 0 48037.78
select_index 20000 0 0 50594.10
select_index 20000 0 0 43978.47
select_index 20000 0 0 52968.77
select_index 20000 0 0 51359.09
select_index 20000 0 0 56371.54
select_index 20000 0 0 50922.33
sysctl.conf:
## kernel
# Maximum socket buffer size
kern.ipc.maxsockbuf=1048576
# Maximum pending socket connection queue size
kern.ipc.somaxconn=4096
# Maximum number of sockets avaliable (portrange?)
kern.ipc.maxsockets=16424
# Maximum number of files
kern.maxfiles=65536
# Maximum files allowed open per process
kern.maxfilesperproc=32768
# mbuf (65k = 144m memory in kernel)
kern.ipc.nmbclusters=65536
# Some versions of MySQL make frequent queries of the system time, which on FreeBSD
# returns a very accurate but somewhat expensive to gather time stamp.
# MySQL performance can be improved by reducing the accuracy (and increasing the performance)
# of the time query mechanisms in FreeBSD. For example, the TSC-based time counting mechanism,
# which can be used on some systems, is substantially cheaper. You can use the
# kern.timecounter.choice sysctl to specify which timecounter to use. See kern.timecounter.hardware
# sysctl to query the available time counters. TSC may be unsafe on some (older) SMP configurations,
# and in most power-saving modes, as the rate of the time counter can change. RobertWatson is currently
# investigating exposing cheaper time mechanisms with lower resolution appropriate for use by applications.
#kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware=TSC
Прошу обратить внимания на последний параметр.
За счет уменьшение точности ответов при запросах времени, получаем существенный выигрыш скорости работы mysql.
У меня выигрыш был примерно 30%.
Причем очень явно: ставим параметр - есть прирост, ставим старый - нет прироста.
Смотрим kern.timecounter.choice и выбираем из имеющихся вариант.
И ставим его в kern.timecounter.hardware.
Потом, ядро.
# Поддержка многопроцессорности
options SMP
options IPI_PREEMPTION
Можно попробовать
options SCHED_ULE
# no debugging
nooptions WITNESS
nooptions INVARIANTS
nooptions DIAGNOSTIC
nooptions INVARIANT_SUPPORT
# Для mysql
#options MAXDSIZ="(1024*1024*1024)" # max memory for process
options MAXDSIZ="(2*1000*1000*1000)" # max memory for process
На i386 MAXDSIZ не ставится в 2 гига (2*1024*1024*1024)
Потом, /etc/make.conf
# Сразу говорю, это для core 2 duo
CPUTYPE=prescott
CFLAGS=-march=prescott -mtune=prescott -O2 -pipe
CXXFLAGS+=-march=prescott -mtune=prescott -O2 -pipe
COPTFLAGS=-march=prescott -mtune=prescott -O2 -pipe -fomit-frame-pointer
PTHREAD_LIBS=-lthr
.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
PTHREAD_LIBS=-lthr
CFLAGS+= -O6
CONFIGURE_ARGS+= \
--disable-profiling \
--with-pthread \
--with-big-tables \
--with-innodb \
--with-named-thread-libs='-lpthread -D_THREAD_SAFE' \
--enable-assembler \
--disable-shared \
--with-mysqld-ldflags="-all-static" \
--with-client-ldflags="-all-static" \
--with-unix-socket-path=/tmp/mysql.sock \
--enable-static \
--disable-dependency-tracking
.endif
Потом, /etc/malloc.conf
Очень интересно сделан конфиг для malloc.
Чтобы его сделать, надо выполнить команду
ln -s ajHRuz /etc/malloc.conf
=)
Это убирает debugging в malloc вызовах.
Потом /boot/loader.conf:
vm.kmem_size="536870912"
vm.kmem_size_max="536870912"
Потом /etc/libmap.conf
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.1 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2 libthr.so.2
Ну и часть конфига mysql, отвечающая за innodb:
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 1G
innodb_data_file_path = innodb_file.db:10M:autoextend
innodb_file_io_threads = 4
innodb_force_recovery=0
innodb_thread_concurrency = 8
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 4M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 120
innodb_file_per_table = 1
Все это проверялось на FreeBSD 6.2
В результате super-smack выдает:
foreach a ( 1 2 3 4 5 6 7 8 9 0 )
foreach? super-smack select-key.x 10 1000 | grep select_index
foreach? end
select_index 20000 0 0 56859.37
select_index 20000 0 0 47745.35
select_index 20000 0 0 49197.10
select_index 20000 0 0 48037.78
select_index 20000 0 0 50594.10
select_index 20000 0 0 43978.47
select_index 20000 0 0 52968.77
select_index 20000 0 0 51359.09
select_index 20000 0 0 56371.54
select_index 20000 0 0 50922.33