Разместите свой проект бесплатно и начните получать предложения от фрилансеров-исполнителей уже спустя минуты после публикации!
500 ₴

Расшибленная настройка mysql

проект завершен


Имеется система Debian8 x64

Необходимо настроить mysql на максимальную производительность исходя из характеристик железа 

А именно Intel  i7-6700K , 32GB RAM DDR4 и диск Nvme 4Tb 

1/2k уников, настроить нужно удаленно через тв. 

Отзыв заказчика о сотрудничестве с Игорем Г.

Качество
Профессионализм
Стоимость
Контактность
Сроки

Получил рекомендации. Спасибо.



  1. ставка скрыта заказчиком
  2. ставка скрыта заказчиком
  • Евгений Тимонин
    11 февраля в 12:47 |

    My.cnf выставляете лимиты от количества оперативки и ядер

    )))

  • Виталий Грулин
    11 февраля в 12:48 |

    Проблема не в конфиге 100%

  • Дмитрий Артёменко — заказчик проекта
    11 февраля в 12:49 |

    Лимитов думаю мало) 

  • Евгений Тимонин
    11 февраля в 12:57 |

    если бд 20-25 гб то смело ставьте 28)) только я сомневаюсь что бд у вас такого размера 

  • Евгений Тимонин
    11 февраля в 13:29 |

    А вот интересно у заказчика узнать что значит 

    Расшибленная? расшибленной может быть голова лицо и еще много всяких частей человеческого тела ну уж ни как не 

    MySQL

  • Виталий Грулин
    11 февраля в 12:47 |

    А причем тут настройка Mysql? Тут проблема 100% в запросах с движка сайта!

  • Дмитрий Артёменко — заказчик проекта
    11 февраля в 12:49 |

    Ну не только ведь (просто стандартный конфиг мускуля стоит) 

  • Виталий Грулин
    11 февраля в 12:51 |

    Как правило это на производительность не влияет практически. А вот в оптимизации запросов и сокращение количества, очень даже. Говорю из опыта, так как работал с сервисами на которых по 100 000 в сутки было.

  • Евгений Тимонин
    11 февраля в 12:49 |

    Для того что бы мускул наиболее корректно работал и потреблял то что ему положено не зря придумали настройки всё зависит от того что ему укажут потреблять то он и будет

  • Виталий Грулин
    11 февраля в 12:51 |

    Сделай EXPLAIN для кривого запроса и играйся с настройками. Я гляну на сколько производительность увеличиться

  • Виталий Грулин
    11 февраля в 12:53 |

    innodb_buffer_pool_size вот разве что тут поставить 24-28G

  • Евгений Тимонин
    11 февраля в 12:55 |

    рекомендуется устанавливать (в идеале) размер innodb_buffer_pool_size немного больше, чем размер всех таблиц InnoDB на сервере

  • Виталий Грулин
    11 февраля в 12:57 |

    А вы знаешь что это за буффер? И почему нужно указывать примерно 75-80% от общей оперативки?

  • Евгений Тимонин
    11 февраля в 12:59 |

    по тому что мускул скажем кеширует запросы и что бы он корректно работал с памятью и обрабатывал буфер и придуман этот параметер innodb_buffer_pool_size 

  • Виталий Грулин
    11 февраля в 13:02 |

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

  • Евгений Тимонин
    11 февраля в 13:18 |

    хорошо что по вашему кеширование? я так подозреваю что как раз таки индекс для быстрого доступа втч то что и буфер

  • Евгений Тимонин
    11 февраля в 13:00 |

    название за себя само говорит

  • Евгений Тимонин
    11 февраля в 13:01 |

    чем больше база тем больше буфер устанавливается

  • Виталий Грулин
    11 февраля в 13:03 |

    Тоесть каждые 10 записей вы будете лезть и менять буфер?))))

  • Евгений Тимонин
    11 февраля в 13:10 |

    зачем? и для чего?

  • Евгений Тимонин
    11 февраля в 13:11 |

    допустим у вас база 1000мб ставте буфер 1500 мб и будет с него

  • Евгений Тимонин
    11 февраля в 13:14 |

    вот к примеру почитайте https://habr.com/ru/post/108418/ тут расписано по параметрам

  • Александр Белов
    11 февраля в 14:13 |

     А всегда ли такая мера будет полезной и оправданной или лучше посмотреть насколько переполняется существующее значения буфера и поставить рациональное значение, а сэкономленную память лучше отдать условному redis под объектное кэширование?
    Установка лошадиных значений точно не ухудшит ситуацию, но вот будет ли RAM использоваться рационально - это уже другой вопрос.

  • Евгений Тимонин
    11 февраля в 12:51 |

    запросы (то что отправляет сайт на сервер с мускулом) лимиты (то что выставлено в настройках мускула) если лимиты и запросы не совпадают по любому будет какая то бяка

  • Александр Белов
    11 февраля в 14:03 |

    Mysql оптимизируруется исходя из запросов которые прилетают в базу, а не просто "под железо". И оптимизацию желательно делать как со стороны кода так и со стороны сервера и это стоит слегка дороже и затратнее по времени чем вы рассчитываете. Но зато, возможно, будет много желающих поставить сходу свой универсальный конфиг и поправить размер буфера c значениям половина от RAM (о чем пишут на половине блогов по оптимизации для новичков, но это не является панацеей) + может еще запустят mysqltuner. Но это сложно назвать оптимизацией, хотя и скорее всего будет работать лучше чем полный дефолт.

  • Евгений Тимонин
    11 февраля в 14:08 |

    Совершенно с вами согласен нужно рассчитывать от размера запросов и от размера самих бд и даже от размера самих таблиц но физику и математику у нас похоже зря придумали)) достаточно заголовок тз внимательно прочитать))

  • Виталий Грулин
    11 февраля в 14:26 |

    То о чем я говорил в кратце)