- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый вечер.
Посоветуйте, что лучше для сервера баз mysql количество ядер/потоков или тактовая частота?
Сервер баз мускула нагружен, сейчас на сервере с( Intel Xeon E3-1270v6) 4 ядра 8 потоков, нагрузка 100% процессора при обновлении товара, проходит не быстро пару часов.
Обновления товара 3-4 раза в неделю, в штатном режиме сервер использует процессор на 2-3ядра.
Понимаю что нужно оптимизировать запросы в базе и скрипты вэб проекта, прогер дорого обходится, решили попробовать взять новый сервер.
В базе очень много запросов select/insert.
База примерно 20-25гигов весом.
Если на уровне скриптов/запросов вопрос не решить, то ничего другого не остается кроме как дать ему делать что оно хочет так долго как хочет. Но постараться ограничить этот процесс обновления до пары ядер к примеру.
Как именно - надо смотреть предметно что конкретно там происходит. Если параллельно много скриптов долбят mysql - логично ограничить их количество. Сделать чтоб весь этот процесс проходил более однопоточно и оставались ненагруженные ядра для работы всего остального. Чисто железом, не меняя ничего программно, вопрос не решить - все равно будет все та же 100% загрузка, но просто другое количество времени. Можно лишь минимизировать ущерб (тормоза в других задачах помимо обновления) ограничив количество этих тяжелых потоков.
Конечно можно за ту же цену взять больше ядер/меньше частоту... и пусть даже пару часов обновления превратятся в час, но все остальное время ведь обычные запросы будут проходить медленней.
Есть процессоры 8-10-ядерные аналогичной 4+ггц частоты, но очевидно стоить это будет заметно дороже... и опять же, 2ч станут 1ч, но все равно моменты тормозов со 100% загрузкой никуда не уйдут.
Ну конечно :) райзен какой-то конкретный против зеона одного общего в целом.
Вопрос не в том. Если задача тяжелая многопоточная, то она на 100% загрузит абсолютно любой процессор. И в плане "летает" - все равно задача на несколько часов не станет за секунду выполняться ни на каком процессоре.
Тут только ускорять/оптимизировать саму задачу и/или ограничивать ее до количества ядер чуть меньшего чем все чтоб не ложить сервер наглухо.
Ну конечно :) райзен какой-то конкретный против зеона одного общего в целом.
Вопрос не в том. Если задача тяжелая многопоточная, то она на 100% загрузит абсолютно любой процессор. И в плане "летает" - все равно задача на несколько часов не станет за секунду выполняться ни на каком процессоре.
Тут только ускорять/оптимизировать саму задачу и/или ограничивать ее до количества ядер чуть меньшего чем все чтоб не ложить сервер наглухо.
my.cnf показать смысла нет, там все в порядке.
Оперативки 32 гига сейчас, пул innidb выделен 21гиг.
Два сервера под файлы и базы сейчас, файлы и базы лежат на дисках nvme 1TB Intel DC P4510, под сами системы диск ssd обычный.
Нагрузка базы только при обновлении товара, товара очень много.
Вижу ОЧЕНЬ много запросов join без индексов, вот они и создают нагрузку, прогер сказал что их оптимизировать не получится.
Пока есть план по смене сервера.
Думаю с начало взять сервер с камнем Intel® Xeon® E-2288G.
Если эффект будет мал, то поменяем сервер на двух процессорник 2x Xeon Silver 4210 его я думаю будет достаточно.
Яндекс облако
1 Данные должны быть на территории России.
2 Для наших нужд, дешевле взять сервер в аренду, чем использовать облако!
my.cnf показать смысла нет, там все в порядке.
Оперативки 32 гига сейчас, пул innidb выделен 21гиг.
Два сервера под файлы и базы сейчас, файлы и базы лежат на дисках nvme 1TB Intel DC P4510, под сами системы диск ssd обычный.
Нагрузка базы только при обновлении товара, товара очень много.
Вижу ОЧЕНЬ много запросов join без индексов, вот они и создают нагрузку, прогер сказал что их оптимизировать не получится.
Пока есть план по смене сервера.
Думаю с начало взять сервер с камнем Intel® Xeon® E-2288G.
Если эффект будет мал, то поменяем сервер на двух процессорник 2x Xeon Silver 4210 его я думаю будет достаточно.
Берите тогда новый сервак, да подороже, тему в корзину
Берите тогда новый сервак, да подороже, тему в корзину
Так ТС и спрашивает совета, какой лучше брать " количество ядер/потоков или тактовая частота?".
Посоветуйте, что лучше для сервера баз mysql количество ядер/потоков или тактовая частота?
Возьмите AMD EPYC 7402P или около того, памяти докиньте. Но, как выше заметили, проблем это особо не решит. Тут либо кардинально мощный сервер за 100500 руб в день, либо оптимизация запросов.