[ОТВЕТИТЬ]
22.06.2006 23:27
OlegON
 
Я, к сожалению, не силен в MySQL, кто как оптимизирует и настраивает базу? Вот у меня есть тут, в форуме процедура оптимизации, ужимает базу раз в 10, еще не разбирался, что делает. Может в мускуле перепаковка удаленных записей есть? Или еще что? Короче, кто что делает?
Изображения
Тип файла: jpeg eoq.jpeg (1.5 Кб, 1521 просмотров)
Тип файла: jpeg eoq.jpeg (1.5 Кб, 1519 просмотров)
23.06.2006 07:58
XsevenBeta
 
В мускуле на котором стоит УКМ нет паковки удалённых записей. Даже если дропать базу (именно базу а не таблицу!) - один хрен не изменится размер. Выход - иметь девственно чистую дб и периодически всасывать в неё из сделанного дампа.
Дамп as insert
mysqldump --opt -e -uLOGIN -PPORT -hHOST -pPASS DBNAME > dump.txt

осстановление из бэкапа
mysql -uLOGIN -PPORT -hHOST -pPASS DBNAME < dump.sql
А лучше зайти в консоль:
SET FOREIGN_KEY_CHECKS=0;
source dump.sql
SET FOREIGN_KEY_CHECKS=1;
Последняя строка не обязательна, ибо это настройка для твоей сессии.

-e в дампе очень важный параметр - восстанавливатся из дампа сделанного с этим ключом будет на порядок быстрее. Ибо он большими кусками будет такой дамп в базюку колбасить.
По идее ещё быстрей будет работать если автокоммит отключать. Но я не пробовал.
А вообще - лучше дампить так:
результат show tables выводишь в файл
mysql -uroot -hServerIP -e"show tables" >> tables

А потом пишем батник:
for /f "tokens=1" %%i in (tables) do (
C:\MYSQL\bin\mysqldump --opt -uroot -e -hServerIP ukmserver %%i >> D:\_ukmsrv\%%i
)

Восстановливать таким же образом. Если вдруг чё-то случится, не придётся запускать дамп или восстановление бэкапа по новой. Можно писать в скрипте перед дампом SET FOREIGN_KEY_CHECKS = 0.

Толковой доки по оптимизации самого сервера mysql (буферов там всяких) в общем-то и нету. Кое-что есть, но этого мало. Делается всё экспериментальным путём, долго и муторно.
А вообще, MySQL начинает очень колбасить когда много процессов на нём запущено. Когда у нас врубается репликация на шесть магазинов на сервере серверов - двухпроцевая тачка дико тормозит. С+ об этом знает и собирается сделать очередь репликаций (тут на самом деле не так всё просто как кажется - нужна ведь ещё и возможность задавать приоритеты на некоторые таблицы.)
В Оракле всё на порядок грамотнее и интереснее чем в MySQL. Оракл в плане оптимизации - мегавещь!
23.06.2006 09:08
OlegON
 
*05 мегавещь! Кстати, ходят слухи о переводе на Oracle серверной части УКМ4
23.06.2006 09:14
alex_auto49
 
Слышал и про, что сервак под ЛИНУКС тестят..... *06
23.06.2006 09:16
OlegON
 
В данном случае это поможет только в плане стоимости платформы, ибо переход с винды особых преимуществ не даст.
23.06.2006 09:48
alex_auto49
 
Мое мнение - сервак под ЛИНУХ должен быть. И тогда у всяких там ОБЭП не будет повода придраться, как это случается все чаще и чаще
23.06.2006 12:09
XsevenBeta
 
Цитата:
olegon В данном случае это поможет только в плане стоимости платформы, ибо переход с винды особых преимуществ не даст.
Такие вещи как Апач, MySql - были портированы с *nix. И MySQL уж точно быстрее виндового работать должен... Некоторые говорят в два раза. Да и пересобирать его под *никсом проще.
23.06.2006 12:18
OlegON
 
Приближаемся к вечному топику о преимуществах винды перед линуксом. Как сказал один товарищ:"Я не сплю с ними, я за них деньги получаю", несмотря на порт, вряд ли в 2 раза, только если использовать какие-то специфичные для платформы вещи. С тезисом, что сервер УКМ должен быть под Linux я не спорю. Должен быть. Ибо ОБЭПы и прочие русские щиты не спят, хотя жаль *05 Я сторонник свободного развития софта. Не бейте ногами, я дяде Биллу платил за винду раза два, кажется.
26.07.2006 12:22
OlegON
 
Процитирую кусок своего письма в тему... Ваши комментарии?
Ковырялся с настройками, если есть желание, почитайте мои рекомендации по настройке. Сам я еще чайник в MySQL, ориентируюсь просто на подобное в Oracle и надеюсь, что не будет путаницы версий.
Итак, исхожу, что то, что дали мне идентично тому, что ставится в магазах:
1) innodb_data_file_path=ibdata1:500M;ibdata2:150M:autoextend
кажется более выгодным (чем создание одного на 300, как у меня сейчас) в плане разделения их потом по дискам и возможности асинхронного чтения/записи, если таковое MySQL поддерживается. Кроме того, хорошо бы запрашивать у клиента, где именно лежит его драгоценный рейд. Диск С:, куда по умолчанию просится мускул, как раз не часто рейд, наоборот, какой-то винт для системы. Да еще и со свопом.
2) задавать бы innodb_autoextend_increment скажем метров в 100, слишком маленькое значение увеличения приведет к фрагментации, как файла данных, так и его внутренностей.
3) Логи были всего 5 метров, это маловато, у меня по умолчанию - 20Мб.
4) innodb_buffer_pool_size почему бы не выставлять в значение 80% от всей оперативки, как рекомендуется? Ну хотя бы в 250Мб, по умолчанию 80Мб, это уже морально устарело...
5) Сделал базе optimize по всем таблицам - 200-300 мс выполнение запроса. В штатные процедуры?
6) key_buffer_size увелить бы до 8Мб? На приведеной в пример базе размер всех индексов - 2Мб, ну, сделаем накидку на время и возможные ресурсы сервера...
7) думаю, set-variable=table_cache=64
8) При экспорте-импорте размер базы сократился с 1,6Гб до 300Мб (изначально заданного значения), понятно, что сканирование такого нехилого файлика при любых вывертах алгоритма поиска будет дольше. Т.е. подобная процедура должна стать штатной. Тем более, что я тоже не нашел другого способа для уменьшения размера базы.
9) innodb_file_per_table=1 ? Вместо одного гигантского файлика получаем кучу маленьких после экспорта-импорта? Доводы против?
10.08.2006 21:46
OlegON
 
Давайте настойками my.ini меряться? Я сегодня порядком док перешерстил, на кое-что взгляд свой поменял, обнаружил некоторые полезности, например
\mysql\bin\mysqlcheck -uroot -ppassword --repair --analyze --optimize --all-databases --auto-repair
Кое-что еще, поскольку новичок в этом деле, много для себя открытий сделал. Завтра приведу измененные параметры my.ini, может кто-то еще что менял, поделимся?
11.08.2006 11:49
OlegON
 
innodb_buffer_pool_size можно/нужно и больше поставить (до 768М бы, не забывая об ограничении на память процесса под виндой), я взял тот, что у меня на 512 еще живет.

set-variable=innodb_buffer_pool_size=256M
set-variable=innodb_additional_mem_pool_size=20M
set-variable=innodb_log_file_size=96M
set-variable=innodb_log_files_in_group=3
set-variable=innodb_log_buffer_size=96M
set-variable=innodb_file_io_threads=9
set-variable=innodb_flush_log_at_trx_commit=0
set-variable=key_buffer=16M
skip-name-resolve

кто что скажет?
28.01.2009 09:48
anderson
 
Быстрее-то стало?
02.02.2009 03:25
anderson
 
посмотрел у себя.
Обычно сервис MYSQL запускается со следующим путем для выполнения (path to executable):
"ПУТЬ\MySQL\bin\mysqld" --defaults-file="ПУТЬ\MySQL\my.ini" MySQL

На сервере УКМ у меня путь для старта сервиса следующий: "ПУТЬ\MYSQL\bin\mysqld-nt.exe"
Если не указывается путь к my.ini, то ищем его в c:\windows
Ок, файл my.ini действительно в системной директории.
Вообще это не принципиально, но кривовато. У всех так?

P.S. сервер mysql: 5.0.27-community-nt, сервер укм: 44 sp1
23.04.2009 09:56
roader
 
Для настройки и оптимизации БД MySql есть не плохая программа MONyog,
может мониторит сразу несколько БД и сравнивать их.
15.01.2010 14:22
XsevenBeta
 
В 42сп4 не было включено кэширование. В новых версиях возможно включили уже.
show status lile 'qcach%'
Если вывело всё по нулям - значит не кешируется. Врубаем кэш
set-variable=query_cache_size=4M
set-variable=query_cache_limit=4M

Тут всё зависит только от доступной вам памяти. Надо отбивать чеки и смотреть в переменной Qcache_free_memory как она расходуется.

Коэфцициент попадания в кэш считается так
qcache_hit_ratio = qcache_hits / (qcache_hits + qcache_inserts + qcache_not_cached)
Если 0,7 это 70% попадания в кэш.

Но вообще в 42сп4 просто уйма однотипных записей (20-30 запросов) при каждом считывании каждой позиции.
И те же input_template* и скидочные таблицы всегда будут в кэше.

Вот данные по серверу магазина, аптайм 78730, т.е 22 часа:
"Variable_name" "Value"
"Qcache_queries_in_cache" "2171"
"Qcache_inserts" "70424"
"Qcache_hits" "112967"
"Qcache_lowmem_prunes" "0"
"Qcache_not_cached" "139545"
"Qcache_free_memory" "131728504"
"Qcache_free_blocks" "536"
"Qcache_total_blocks" "4952"

Т.е % взятия из кэша порядка 30%. Жаль нельзя позырить что там в кэше хранится. Но вообще, на некоторые операциях кэш очень рулит.
17.05.2011 16:30
John Doe
 
Обнаружил интересный скриптик по тюнингу MySQL
Sundry MySQL Scripts and Docs
13.12.2012 17:38
Tiger
 
Хочу оптимизировать базу myqsl на кассе! Связано это с тем, что касса работает нормально, пока количество позиции в чеке не достигнет более 80! После чего касса начинает по страшному тормозить! Скачал с FTP C+ файл по оптимизации - , но как-то часть команда не получается выполнить, а именно
Цитата:
mysql -uroot --execute="flush tables"
mysql -uroot --execute="flush logs"
Как правильно выполнить эти команды? Не нашел у себя по эти путям эти файлы
Цитата:
/var/lib/mysql/ib_logfile0
/var/lib/mysql/ib_logfile0
Параметры, которые предлагают для установки они от чего зависят,не могут же они быть оптимальными для любой кассы? Может есть более понятный мануал? Стоит ли после этого оптимизировать базу mysql на сервере?

P.S Используется УКМ 49 sp5!
13.12.2012 20:40
vdm
 
Во время "страшных тормозов" неплохо бы processlist в mysql кассы посмотреть или перед этим slow query log включить. Опять же загрузку процессора глянуть.

По инструкции
mysql -uroot ... не выполнится без пароля (текст под старую базу без паролей)
Хотя эти команды необязательны, они для перестраховки от убиения базы некорректной остановкой.

/var/lib/mysql/ - похоже, этот каталог предлагается создать и в него убрать старые логи (ib_logfile0 и ib_logfile1) из /usr/local/mysql/var/

Параметры в основном определяют количество RAM отъедаемой mysql, соответственно подгонять нужно под объем на конкретной кассе.

В конце файла, после .../ukmclient start - мусор .../ib_logfile0
14.12.2012 07:48
Tiger
 
Цитата:
vdm Во время "страшных тормозов" неплохо бы processlist в mysql кассы посмотреть или перед этим slow query log включить. Опять же загрузку процессора глянуть.

По инструкции
mysql -uroot ... не выполнится без пароля (текст под старую базу без паролей)
Хотя эти команды необязательны, они для перестраховки от убиения базы некорректной остановкой.

/var/lib/mysql/ - похоже, этот каталог предлагается создать и в него убрать старые логи (ib_logfile0 и ib_logfile1) из /usr/local/mysql/var/

Параметры в основном определяют количество RAM отъедаемой mysql, соответственно подгонять нужно под объем на конкретной кассе.

В конце файла, после .../ukmclient start - мусор .../ib_logfile0
Разобрался с командами! Теперь загвоздка как правило выставить параметры! Как определить количество RAM отъедаемой mysql и как правильно выставить относительно этого параметра требуемые для оптимизации праметры?
14.12.2012 08:13
OlegON
 
Обрати внимание на #17 сообщение в этой теме.
14.12.2012 09:55
Tiger
 
Цитата:
OlegON Обрати внимание на #17 сообщение в этой теме.
В моем случай нужно выполнить первый скрипт?

Цитата:
chmod +x путь до скрипта/tuning-primer.sh
Запуск: путь до скрипта/tuning-primer.sh
Подскажите правильно пытаюсь выполнить скрипт и в какую папку его нужно положить?
14.12.2012 14:10
OlegON
 
Вроде все правильно, в любую папку, посмотри, он там еще требует калькулятора, кажется, я не знаю, есть он в штатной поставке или нет.
24.12.2012 05:33
Tiger
 
Решил продолжить процесс оптимизации с помощь скрипта:



Скрипт положил по следующему пути /usr/opt/tuning-primer.sh! Выполнил команды
Цитата:
chmod +x /usr/opt/tuning-primer.sh
/usr/opt/tuning-primer.sh
Как и предположил Olegon калькулятора действительно не оказалось

Цитата:
which: no bc in (/usr/local/sbin:/usr/local/xorg/xinput_calibrator/bin:/usr/local/xorg/icewm/bin:/usr/local/xorg/xorg-deps/bin:/usr/local/xorg/xorg-main/bin:/usr/bin:/bin:/usr/sbin:/sbin:/root/bin)
Error: Command line calculator 'bc' not found!
Скачал bc-1.06! Пытаюсь его установить положил дистрибутив в папку по тому же пути /usr/opt/! Выполняю команды:

Цитата:
gunzip bc-1.06.tar.gz
tar xvf bc-1.06.tar
cd bc-1.06
./configure
После выполнения команды ./configure получил
Цитата:
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... no
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking for gcc... no
checking for cc... no
configure: error: no acceptable cc found in $PATH
Подскажите что не так и может существует какой другой способ установки данного калькулятора!

P.S И хотелось бы узнать, что является результатом выполнения скрипта tuning-primer.sh!
24.12.2012 07:26
OlegON
 
про калькулятор - собери его еще где-нибудь, где такая же платформа...
сто касается скрипта - вот пример вывода:
скрытое
24.12.2012 11:12
vdm
 
rpm bc из дистрибутива redhat 9.0
https://storage.olegon.ru/supermag/u...12.i386.rpm.7z

Установка: rpm -ivh --nodeps bc-1.06-12.i386.rpm
25.12.2012 09:07
Tiger
 
Получил результат выполнения скрипта ! Как сделать анализ полученных данных, и какие если нужно поправить параметры и где?
25.12.2012 12:30
vdm
 
"Сделать анализ полученных данных" - это для начала минимально знать технический английский. Там все написано, читайте.

Специалистом не являюсь, все "рекомендации" следуют из вывода скрипта.

Uptime = 0 days 0 hrs 0 min 31 sec
Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations


Нужно поработать хотя бы несколько часов под нагрузкой, и с теми операциями где тормозит.

SLOW QUERIES
The slow query log is NOT enabled.


Если интересны долго выполняемые запросы, в my.cnf
log_slow_queries=query-slow.log

INNODB STATUS
Current InnoDB index space = 86 M
Current InnoDB data space = 72 M
Current InnoDB buffer pool free = 94 %
Current innodb_buffer_pool_size = 640 M

MEMORY USAGE
Max Memory Ever Allocated : 743 M
Configured Max Per-thread Buffers : 468 M
Configured Max Global Buffers : 737 M
Configured Max Memory Limit : 1.17 G
Physical Memory : 1.96 G


C таким размером БД, она вся в кэше должна лежать и тормоза со стороны БД маловероятны, скорее приложение косячит.

QUERY CACHE
Query cache is supported but not enabled


Можно добавить в конфиг
query_cache_size = 16M
query_cache_limit = 2M

JOINS
Current join_buffer_size = 132.00 K
You have had 5 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.


Можно добавить в конфиг
log-queries-not-using-indexes
и смотреть запросы, не использующие индексы.
Если проблема в них (а переписать их нельзя), можно попробовать увеличить join_buffer_size, до 4M например

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 454 tables
You have 64 open tables.
Current table_cache hit rate is 3%
, while 100% of your table cache is in use
You should probably increase your table_cache


Можно увеличить
table_cache = 512

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 201 temp tables, 9% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.


Можно увеличить
max_heap_table_size = 32M
16.06.2015 09:40
OlegON
 
Помимо скрипта в 17 сообщении могу предложить еще один.
Код:
wget http://mysqltuner.pl/ -O mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl
на всякий случай прикладываю и сюда скрипт...
Вложения
Тип файла: 7z mysqltuner.7z (12.4 Кб, 72 просмотров)
Опции темы


Часовой пояс GMT +3, время: 19:00.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.