Jump to content
Калькуляторы

тюнинг mysql под windows

приветствую всех!

 

может кто подскажет есть windows server 2016

диски в нём SSD

оперативки 32Гб

 

нужно добиться максимальной производительности MYSQL

версия от 5,1 до 5,5

может кто подскажет есть ли аналог mysql тюнер? или что подкрутить чтобы стало хорошо? (грубо говоря готовый my.ini)

в основном INNOBD всё пишется в базу и из неё же и читается

Share this post


Link to post
Share on other sites
22 минуты назад, Artom_12 сказал:

или что подкрутить чтобы стало хорошо?

Такого не бывает.

Изучать, мониторить, профилировать, тюнить.

Поменять ОС на Linux, версию на 10+, а движок на MyISAM (или Aria с отключенными транзакциями).

 

Share this post


Link to post
Share on other sites

есть же "рекомендуемые" настройки? исходя из памяти и процессора минимум? нет?

Share this post


Link to post
Share on other sites

Рекомендации по настройке буферов одинаковы для Win и Lin, заимствуйте из туториалов с поправкой на большее потребление памяти на ОС. Более тонкий тюнинг - phpmyadmin дает некоторые советы на вкладках "Состояние" и "Переменные". В осталном - все упирается в то, что высоконагруженный MySQL на Win - терра инкогнита, потому что никому там не требуется, нет таких задач. Будете первопроходцем, огребая что-нибудь вроде http://www.dskims.com/mysql-innodb-insert-performance-windows/ , а лучше сделайте Hyper-V машину, вкатите Линь, Hyper-V integration, и настраивайте дальше как все порядочные красноглазые люди.

Share this post


Link to post
Share on other sites
13 часов назад, alibek сказал:

а движок на MyISAM (или Aria с отключенными транзакциями).

угу, и получить битую базу при первом же отключении питания :) не говоря уже о том, что myisam толком не тюнится, и при сколь-либо большой нагрузке встает раком.

Share this post


Link to post
Share on other sites

MyISAM всё-же годится под логи и справочники, на чтение быстр, компактен.

Share this post


Link to post
Share on other sites
6 часов назад, NiTr0 сказал:

получить битую базу при первом же отключении питания :)

У нас на MyISAM работает один из часто упоминаемых на этом форуме биллингов. Работает с 2010 года. Отключений по питанию за 8 с лишним лет было много, база ни разу не билась.

Share this post


Link to post
Share on other sites
46 минут назад, Andrei сказал:

Отключений по питанию за 8 с лишним лет было много, база ни разу не билась.

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

 

+ ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов.

Share this post


Link to post
Share on other sites
4 minutes ago, NiTr0 said:

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

 

+ ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов.

советую смотреть на drop-in-replacement mysql от percona mariadb

Share this post


Link to post
Share on other sites
13 минут назад, NiTr0 сказал:

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

Сорри, некоторое время назад оказывается тоже перешли на innodb :)

Share this post


Link to post
Share on other sites

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы.

Share this post


Link to post
Share on other sites

всем спасибо за инфу!

еще вопрос щас стоит всё на Version: '5.1.40-community' стоит пробовать перенакатить на как минимум 5.5 ?

Share this post


Link to post
Share on other sites
8 минут назад, Artom_12 сказал:

всем спасибо за инфу!

еще вопрос щас стоит всё на Version: '5.1.40-community' стоит пробовать перенакатить на как минимум 5.5 ?

на 5.5 точно не стоит ибо она eos. если уж перекатываться, то хотя бы на 5.6 

 

https://en.wikipedia.org/wiki/MySQL#Release_history

 

А вообще, зависит от задач. Если у вас не шаредная база для шаред-хостера, где каждый может дрючить вашу базу эксплойтами, то перекатываться смысла мало. И вообще, тут больше зависит от потребителей вашей БД. Если потребитель БД это какой-нибудь биллинг и он официально умеет работать с mysql 5.6, то перекатывайтесь, а иначе 5 раз подумайте

Share this post


Link to post
Share on other sites
4 часа назад, alibek сказал:

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

ломается крайне редко. в отличие от myisam, которая ломается при любом нештатном ребуте

 

4 часа назад, alibek сказал:

MyISAM обеспечивает большую производительность

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

Share this post


Link to post
Share on other sites
22 часа назад, alibek сказал:

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы.

Никогда не подходите больше ни к одной БД.

Не ваше оно.

Share this post


Link to post
Share on other sites

@GrandPr1de 

мне тоже не нравится совет alibek на тему защиты от потери данных (ибп+ecc+бэкапы как решение)

но нужно понимать что всё зависит от требований. допустим, это БД zabbix-а где он хранит свои "конфиги" (настройки что и как нужно мониторить) и данные мониторинга, а мониторит он сеть мухосранск-телекома на 2К абонов. предположим, что ибп+ecc не спасли, тогда разворачиваем из бэкапа - теряем до 1 дня (типичная периодичность бэкапа). ну внесли туда руками пару свитчей за этот день, ну внесут заново. ну не будет мониториться сеть пару часов - и ладно, всё равно реакция одного единственного админа-саппортёра-сварщика-подключальщика когда он в отпуске составляет больше этого времени

в данном случае те методы, которые предлагает alibek вполне допустимы

в принципе, даже БД радиуса потерять не страшно, если есть резервный план как раздать всем Интернет безусловно (а если ещё и статические ip-адреса сохранятся при этом, то вообще шикарно)

а вот например с БД всяких биллингов поинтереснее. к примеру, нужно поднять из бэкапа БД, сделали это за пару часов, начали фигачить новые записи в БД (подключать новых абонентов и т.д.), а через день вспомнили что надо всё-таки восстановить потерянные записи (договора, заключенные между падением БД и восстановлением) и тут началось - номера генерятся подряд, в результате части более новых абонов присвоили потерянные номера и что с этим делать и как дальше жить - хз, особенно если оплату принимаете по номеру договора и 2ух абонентов оказались договора с одним номером... 

т.е. нужно просто составить требования к надёжности данных (не просто от балды, а исходя из реальных потребностей) и дальше уже решать как её обеспечивать - с помощью ибп, рейда и ecc или с помощью онлайн-реплики, которая в любой момент может стать основной БД (вручную или автоматом - опять же зависит от потребностей и возможностей(наличия людей в смене и т.д.))

Share this post


Link to post
Share on other sites
26 минут назад, s.lobanov сказал:

в данном случае те методы, которые предлагает alibek вполне допустимы

В тех задачах, где обычно используется MySQL, надежное железо и регулярные бэкапы будут практичнее.

Если база небольшая, то развернуть ее из бэкапа будет быстрее, чем восстанавливать поврежденный innodb.

А если кто-то держит на MySQL терабайтные базы, то он должен и сам понимать, чем это может кончиться.

На более критичных задачах обычно используют другие СУБД.

 

У меня летом умудрилась повредиться биллинговая БД Oracle.

Но хоть и не без седых волос и потерь времени, но все получилось восстановить.

А будь это MySQL, то скорее всего пришлось бы про базу забыть и восстанавливаться из бэкапа, что для биллинга далеко не лучший выход.

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

На более критичных задачах обычно используют другие СУБД.

вы это уберу скажите) https://www.mysql.com/customers/view/?id=1269 . ну и вообще https://www.mysql.com/customers/

 

mysql очень старая (т.е. довольно вылизанная) и далеко не самая худшая БД

 

если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql

Share this post


Link to post
Share on other sites
8 минут назад, s.lobanov сказал:

mysql очень старая

Мудрость не всегда приходит с возрастом, иногда возраст приходит один.

Это как раз про MySQL, по крайней мере классический (5.x).

Если уж хочется эту СУБД использовать. то лучше смотреть на MariaDB.

Что касается того, где используется MySQL, то это не показатель качества, а наследственность.

Фейсбук формально вообще на PHP, но это не значит, что PHP эффективен на высоконагруженных проектах.

 

14 минут назад, s.lobanov сказал:

если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql

Да, но я имел ввиду другое.

Я не слишком большой специалист в Oracle, но в этой СУБД огромный практический опыт (практика) и надежность.

И с помощью статей и инструментов мне удалось восстановить физически поврежденную БД.

Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла».

Share this post


Link to post
Share on other sites
3 часа назад, alibek сказал:

Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла».

Ну после совета про MyISAM не удивительно. 

Share this post


Link to post
Share on other sites

У меня на трех серверах суммарно где-то полтора десятка баз MySQL есть, из них штук 5 MyISAM, остальные InnoDB.

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

На этом сервере было несколько баз данных, пара MyISAM, остальные InnoDB.

MyISAM восстановить удалось. InnoDB восстановить не удалось, не помогло даже  innodb_force_recovery=6.

Share this post


Link to post
Share on other sites

А данные то точно не побились ? А то был случай, что "ура, не побилось", а через неделю искали как накатить новонабитое в недельной давности бакап, ибо часть базы, как потом выяснилось, стало мусором.... и хорошо что через неделю, а не через пол года.

 

А еще была класная, небьющаяся "база" акцесс... опс, и все снова работает (ну фигня, от сих до сих контрольная сумма не бьется, значит тихо  выкидываем и не раздражаем пользователя сообщениями.. бросок по питанию и вуаля, база на 20% тоньше.)

Share this post


Link to post
Share on other sites
26 минут назад, st_re сказал:

А данные то точно не побились ?

да кого те данные интересуют, сказано же - база заработала, ну и отлично. а то, что какому-то абону пару лямов в биллинге на счет бонусом упало в момент краша - ну подумаешь, мелочь какая :)

Share this post


Link to post
Share on other sites
10 часов назад, NiTr0 сказал:

ну подумаешь, мелочь какая

А ведь и правда, нужно было проверить.

Как же это я не подумал.

Ладно, значит будет предварительным подарком на новый год.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now