- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
![Зачем быть уникальным в мире, где все можно скопировать](https://d.searchengines.guru/20/96/frame_27_600x314__b353b658.jpg)
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день.
Засомневался в правильности настройки параметра innodb_thread_concurrency.
Процессор 4 ядра + 4 потока всего 8 потоков у камня, диск на котором база лежит nvme Intel DC P4510 1 Тб
Сейчас параметр innodb_thread_concurrency = 16, количество потоков камня * 2
Местами есть нагрузка 100% на процессор.
Что думаете?
Рекомендую переезжать на более современную SQL или последнюю MariaDB или MySQL8. Это чтобы быстрее работало всё.
А этот параметр лучше не трогать, ибо может снижаться производительность: https://www.percona.com/blog/2016/03/17/percona-server-5-7-performance-improvements/
Одна Pecrona что-то там сделала, чтобы у них этот параметр работал нормально, сама Mysql забила на него. Но 5.7 в любом случаи устарела.
Даже в старых темах: https://dba.stackexchange.com/questions/81204/hyperthreading-mysql-innodb-thread-concurrency-performance
Везде пишут, не трогать этот параметр. Никакой скорости он не прибавит.
Я лично не трогаю его и не настраиваю своим клиентам.
Также и innodb_buffer_pool_instances не настраиваю. Он по умолчанию работает как надо.
Рекомендую переезжать на более современную SQL или последнюю MariaDB или MySQL8. Это чтобы быстрее работало всё.
А этот параметр лучше не трогать, ибо может снижаться производительность: https://www.percona.com/blog/2016/03/17/percona-server-5-7-performance-improvements/
Одна Pecrona что-то там сделала, чтобы у них этот параметр работал нормально, сама Mysql забила на него. Но 5.7 в любом случаи устарела.
Даже в старых темах: https://dba.stackexchange.com/questions/81204/hyperthreading-mysql-innodb-thread-concurrency-performance
Везде пишут, не трогать этот параметр. Никакой скорости он не прибавит.
Я лично не трогаю его и не настраиваю своим клиентам.
Также и innodb_buffer_pool_instances не настраиваю. Он по умолчанию работает как надо.
При штатной, нормальной работы базы думаю по умолчанию подойдет innodb_thread_concurrency.
Но когда есть моменты кривых/тяжелых запросов, без ограничения innodb_thread_concurrency создаст узкие места процессора и диска.
Мое мнение.
При штатной, нормальной работы базы думаю по умолчанию подойдет innodb_thread_concurrency.
Но когда есть моменты кривых/тяжелых запросов, без ограничения innodb_thread_concurrency создаст узкие места процессора и диска.
Мое мнение.
Тесты тесты и ещё раз тесты. Какие могут быть места узкие если innoDB pool достаточный и диски SSD
Тесты тесты и ещё раз тесты. Какие могут быть места узкие если innoDB pool достаточный и диски SSD
Попробуем как нибудь по умолчанию innodb_thread_concurrency = 0.
При join выборок куча таблиц создается, а так же много joiun без индексно почему то используется.
Попробуем как нибудь по умолчанию innodb_thread_concurrency = 0.
При join выборок куча таблиц создается, а так же много joiun без индексно почему то используется.
Значит конструкция БД неудачная. И теперь надо или её переделывать или жить с этим. Кэши всякие там, разбивать на отдельные запросы без JOIN.
Значит конструкция БД неудачная. И теперь надо или её переделывать или жить с этим. Кэши всякие там, разбивать на отдельные запросы без JOIN.
Да вот же, руководству говорю что нужно избавляться от join запросов без индексных, это может снизить нагрузку сервера до 50%.
Но видать это дело затратное и руководство не спешит решать эту проблему.
Да вот же, руководству говорю что нужно избавляться от join запросов без индексных, это может снизить нагрузку сервера до 50%.
Но видать это дело затратное и руководство не спешит решать эту проблему.
В любом случаи innodb_thread_concurrency тут вообще никаким боком и не спасёт ситуацию.
Что думаете?
Апгрейдить БД однозначно.
5.7 от 8.0 по "разумности" отличается очень сильно.
Тем более сейчас как бы 2021 на календаре, давно пора.
Несовместимостей минимум.
Попробуем обновить битрикс до последней версии стабильной, накатим php 8 / mysql 8.
После отпишусь.