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

12
baas
На сайте с 17.09.2012
Offline
121
559

Добрый вечер.

Совет нужен.

Есть проект на битриксе.

Железо такое:

1й сервер проц. 8 потоков выделен под файлы сайта, бэкапы,

2й сервер проц. 8 потоков выделен под базу (структура innodb).

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

В штатном режиме все фурычит хорошо, без особых нагрузок, но вот как только запускается скрипт маркета для обновления товаров, то база забирает 100% процессора под себя, спасает что отдельный сервер под базу, запускают этот скрипт в ручном режиме(не знаю почему) 3-4 раза в неделю днем.

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

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

Спасибо за понимание.

Настройка BSD систем. (https://www.fryaha.ru) Знание сила, незнание Рабочая сила!
Likvik
На сайте с 29.07.2010
Offline
105
#1

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

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

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

Незнание порождает уверенность.
D
На сайте с 28.06.2008
Offline
976
#2

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

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

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#3

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

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

baas:
база забирает 100% процессора под себя

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

Платный и бесплатный хостинг с защитой от DDoS (http://aquinas.su)
baas
На сайте с 17.09.2012
Offline
121
#4
Dram:
По хорошему конечно дать %;"?**:%ей кодеру и заставить его переписать запросы.
+ после этого переехать на один сервер, двойная экономия.

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

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

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#5
baas:
Пока рассматриваю вариант с сервером я большим количеством физических ядер + потоки.

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

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

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


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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#7

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

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

baas
На сайте с 17.09.2012
Offline
121
#8
lonelywoolf:
Ну и берите так. MySQL только число потоков ограничить, получится как на двух старых серверах. За одно и сетевых задержек не станет.

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

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#9
There is also a mechanism in place to ensure that higher priority connections are not monopolizing the worker threads in the pool (which would cause indefinite delays for low priority connections). On Unix, low priority connections are put into the high priority queue after the timeout specified by the thread_pool_prio_kickup_timer system variable.

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

baas:
thread_concurrency,

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

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


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

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

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

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий