[ОТВЕТИТЬ]
Опции темы
22.06.2006 23:27  
OlegON
Я, к сожалению, не силен в MySQL, кто как оптимизирует и настраивает базу? Вот у меня есть тут, в форуме процедура оптимизации, ужимает базу раз в 10, еще не разбирался, что делает *05. Может в мускуле перепаковка удаленных записей есть? Или еще что? Короче, кто что делает?
Изображения
Тип файла: 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 ? Вместо одного гигантского файлика получаем кучу маленьких после экспорта-импорта? Доводы против?
 
27.07.2006 14:17  
OlegON
Для тех, кто не заметил
https://olegon.ru/index.php?name=For...iewtopic&t=256
 
 


Опции темы



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

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