Совет по железу сервера

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

Но я бы все таки взял побольше ядер, и не побрезговал бы ядра Hyper-threading использовать.

Это лично мое мнение.

По хорошему конечно дать %;"?**:%ей кодеру и заставить его переписать запросы.

+ после этого переехать на один сервер, двойная экономия.

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

Т.е. манагеры за рабочий день подготавливают прайсы или что вы там делаете, а обновляется оно ночью.

Если кодер будет божиться, что все что можно уже оптимизировано. МОжет быть и так, мы же правды не знаем, обдумать вариант растянуть обновление по времени - чтобы не бахало всей массой, а порционно. Не за 15 минут, а за час.

baas, Так в чем проблема? Возьмите тот сервер, на котором сейчас всё крутится под БД. Отберите половину потоков у мускула (там это можно), пусть половину грузит БД, половину - сам сайт. Начальству - служебную записку, что мол система может тормозить тогда-то тогда-то по таким-то причинам (скрипт, который прогер не хочет оптимизировать). Всё...

---------- Добавлено 26.12.2019 в 21:39 ----------

Да, ещё момент. Если блокировок таблиц нет - ну и х с нагрузкой на ядра. Даже оптимизировать ничего не надо.

Да в том то и дело менеджеры бояться этот процесс автоматизировать, типа из яндекс-маркета могут вылететь при ошибке.

А так да, уменьшить шаг обновления товара и ночью поставить автоматом, я это предлагал тоже, не хотят.

Пока рассматриваю вариант с сервером я большим количеством физических ядер + потоки.

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

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

Или вы про thread_concurrency, ну тогда нагрузка еще больше по времени висеть будет.

baas, Я давно не пользуюсь MySQL, но вообще вот про это:

https://mariadb.com/kb/en/thread-pool-in-mariadb/

Еще цен не знаем на это железо, тез поддержка подбирает несколько примерных вариантов.

В штатном режиме, файловый сервер нагрузка на проц 2-3 ядра, база нагрузка так же 2-3 ядра.

Но как только начинается обновления товаров для маркета, то нагрузка в базе возрастает до 8 ядер, под потолок, на файлом чуть чуть поднимается до 4 ядер.

Оптимизировать это сотовым администрирование уже некуда, только править сам скрипт и запросы в базе, раньше было еще хуже, это я еще базу по софту оптимизировал, нагрузка в штатном режиме спала с 4х ядер до 2х.

Тоже нужный момент. Это для того, чтоб тяжёлые процессы не мешали выполняться более лёгким. Вообще Марийка мне нравится гораздо больше. Подозреваю, что если сунуться в MySQL - там есть что-то аналогичное.

Оно депрекейтед с 5.5 если верно помню.

Еще есть, версия мускула 5,6, thread_concurrency

Хмм, не использую этот параметр thread_pool_prio_kickup_timer, надо будет почитать о нем.