Время апдейта базы

Технические вопросы по UTM 5.0
Ответить
telesto
Сообщения: 9
Зарегистрирован: Ср ноя 05, 2014 21:43

Время апдейта базы

Сообщение telesto »

Ситуация следующая:
- переход с версии 5.2.1.008 на 5.3.002
- архивирование списаний проведено
- в таблице archives убраны все записи
- размер базы 3.3 гига
- восемь ядер AMD Opteron(tm) Processor 6128 - Base Speed (Mhz) - 2000
- HDD - SATA
- RAM - 6 GB
- Linux UTM5 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux

выполнение скрипта UTM5_MYSQL_update.sql занимает 18 часов 55 минут

Что можно сделать, чтобы сократить это время?
Последний раз редактировалось telesto Вт дек 09, 2014 14:36, всего редактировалось 1 раз.

telesto
Сообщения: 9
Зарегистрирован: Ср ноя 05, 2014 21:43

Re: Время апдейта базы

Сообщение telesto »

Сервер поменять возможности пока нет

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Re: Время апдейта базы

Сообщение Magnum72 »

telesto писал(а):Сервер поменять возможности пока нет
У биллинга обеспечивается обратная совместимость, поэтому можешь потихоньку в часы наименьшей нагрузки апдейтить архивные таблицы.

А дальше при апдейте сравниваешь UTM5_MYSQL_update.sql с предыдущей версией и заливаешь только дельту.

ЗЫ Время выполнения скрипта все таки неприлично большое, надо покурить настройки мускула.

Nik0n
Сообщения: 77
Зарегистрирован: Пн сен 14, 2009 13:53
Откуда: Екатеринбург
Контактная информация:

Re: Время апдейта базы

Сообщение Nik0n »

telesto писал(а): выполнение скрипта UTM5_MYSQL_update.sql занимает 18 часов 55 минут
Хм в начале ноября, когда мы обновлялись с такой же версии utm, то .sql файл бээкап был размером 2332 Мб (на диске, да с индексами понятно больше , я думаю как раз с Ваш размер)
Этот скрипт выполнялся меньше 5 минут.
Архивированы были данных до 1 сентября.

Смотрите на свой I/O (iotop) (я думаю что все дело в SATA дисках, возможно еще если есть то RAID5 их тормозит).
У нас БД MariaDB 5.5.40 default config, но диски SAS RAID1 :)

telesto
Сообщения: 9
Зарегистрирован: Ср ноя 05, 2014 21:43

Сообщение telesto »

поменяли винт на SSD
MySQL со стандартными параметрами.
Время выполнения скрипта стало 4 ч. 24 мин.
Терзают сомнения по надежности SSD в долгосрочной перспективе.
Кто-нибудь держит базу на SSD?

xxxupg
Сообщения: 457
Зарегистрирован: Вс май 02, 2010 10:00

Сообщение xxxupg »

держим, и самому интересно как узнать когда его менять :)

Shiva
Сообщения: 131
Зарегистрирован: Пт авг 28, 2009 12:39
Откуда: Россия, Тверь

Сообщение Shiva »

mysql репликация на нормальный винт, менять по прошествию времени...

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Сообщение Magnum72 »

telesto писал(а):поменяли винт на SSD
MySQL со стандартными параметрами.
Время выполнения скрипта стало 4 ч. 24 мин.
Терзают сомнения по надежности SSD в долгосрочной перспективе.
Кто-нибудь держит базу на SSD?
Вы самоубийца.

telesto
Сообщения: 9
Зарегистрирован: Ср ноя 05, 2014 21:43

Сообщение telesto »

Да, нет, мы не переводили боевой сервер на SSD именно по причине неясности в его стабильности и долгосрочности. Скорость SSD конечно радует, но долго ли это продлится.

Проводим эксперименты на тестовых серверах, собираем информацию.
Спасибо всем, кто откликнулся...

Shiva
Сообщения: 131
Зарегистрирован: Пт авг 28, 2009 12:39
Откуда: Россия, Тверь

Сообщение Shiva »

Мы кеш поставили, стало лучше, сдохнет - ничего не изменится.

telesto
Сообщения: 9
Зарегистрирован: Ср ноя 05, 2014 21:43

Сообщение telesto »

что-то не врубился, поясните, плиз, куда кеш поставили и почему ничего не изменится если сдохнет

Shiva
Сообщения: 131
Зарегистрирован: Пт авг 28, 2009 12:39
Откуда: Россия, Тверь

Сообщение Shiva »

http://www.raid6.com.au/posts/SSD_caching/
Сейчас ZFS с SSD cache и ZIL тестируем...

Ответить