22.06.2006 23:27
OlegON
 
Я, к сожалению, не силен в MySQL, кто как оптимизирует и настраивает базу? Вот у меня есть тут, в форуме процедура оптимизации, ужимает базу раз в 10, еще не разбирался, что делает. Может в мускуле перепаковка удаленных записей есть? Или еще что? Короче, кто что делает?
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
 
мегавещь! Кстати, ходят слухи о переводе на Oracle серверной части УКМ4
23.06.2006 09:14
alex_auto49
 
Слышал и про, что сервак под ЛИНУКС тестят.....
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, может кто-то еще что менял, поделимся?
Часовой пояс GMT +3, время: 15:22.

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