Походу была проблема в версии хрома 78, вернулся обратно на глючную версию 79, но чуть по лучше, но есть зависания все равно, об этих зависания как я понял разработчикам хрома уже известно.
Dram: Да, все очень быстро даже на больших логах. Плагин создает радом с логом еще один файл куда вероятно записывает время (я еще не смотрел) с котрого нужно следующий раз лог читать, поэтому сканирование идет очень быстро, почти мгновенно.
Единственное - плагин требует права на логи 655 вроде, а они по умолчанию создаются другие и он не может их читать.
Я не стал разбираться в проблеме и просто меняю права нужных логов через 5 минут после их создания по крону.
А если в мунине указать что этот график запускать от рута?
Dram: В общем всем рекомендую установить этот плагин, очень наглядно и информативно!
На скриншотах как один из сайтов сканируют поисковые боты, и еще (там где коричневые пики) те кто маскируются под поисковых ботов, но таковыми не является.
P.S. если хотите так же, нужно сперва разделить трафик на разные логи. Я себе наделал таких графиков на каждый сайт, теперь если что сразу будет понятно какой сайт долбят.
lonelywoolf: baas, Ну не знаю, что там за проект у вас, но 5.6-5.7 много не даст, хотя и тут могут быть подвижки. Озадачивайте начальство опять же той же служебной запиской. После того, как с сервером, естественно, разберётесь.
lonelywoolf: baas, Ну Thread_concurrency - фактически прямое указание в сколько потоков работать серверу БД. Собственно, настройка топорная и рабочая ЕМНИП. А вот если вы пользуетесь такой древней версией мускула... Я вам так скажу - сваливайте на мускул 8.0 или марийку 10.3. Так, не взначай, там движок InnoDB сильно переработан и лично у меня на проектах наблюдался вау-эффект. А потом ещё параметры покрутил и чудо случилось, выигрыш производительности от переезда в моём случае составил где-то 60% (!!!).
Переезд на мускул 8 только в планах, от меня не зависит, я предложил переезд, прогер молчит, а без него я не буду искать себе геморой, вдруг вся структура базы похерится.
lonelywoolf: Тоже нужный момент. Это для того, чтоб тяжёлые процессы не мешали выполняться более лёгким. Вообще Марийка мне нравится гораздо больше. Подозреваю, что если сунуться в MySQL - там есть что-то аналогичное.
Оно депрекейтед с 5.5 если верно помню.
Еще есть, версия мускула 5,6, thread_concurrency
Хмм, не использую этот параметр thread_pool_prio_kickup_timer, надо будет почитать о нем.
lonelywoolf: Ну и берите так. MySQL только число потоков ограничить, получится как на двух старых серверах. За одно и сетевых задержек не станет.
Еще цен не знаем на это железо, тез поддержка подбирает несколько примерных вариантов.
В штатном режиме, файловый сервер нагрузка на проц 2-3 ядра, база нагрузка так же 2-3 ядра.
Но как только начинается обновления товаров для маркета, то нагрузка в базе возрастает до 8 ядер, под потолок, на файлом чуть чуть поднимается до 4 ядер.
Оптимизировать это сотовым администрирование уже некуда, только править сам скрипт и запросы в базе, раньше было еще хуже, это я еще базу по софту оптимизировал, нагрузка в штатном режиме спала с 4х ядер до 2х.
lonelywoolf: baas, Так в чем проблема? Возьмите тот сервер, на котором сейчас всё крутится под БД. Отберите половину потоков у мускула (там это можно), пусть половину грузит БД, половину - сам сайт. Начальству - служебную записку, что мол система может тормозить тогда-то тогда-то по таким-то причинам (скрипт, который прогер не хочет оптимизировать). Всё...
---------- Добавлено 26.12.2019 в 21:39 ----------
Да, ещё момент. Если блокировок таблиц нет - ну и х с нагрузкой на ядра. Даже оптимизировать ничего не надо.
напомните пожалуйста, а как отобрать потоки у мускула, помоему можно только поставить ограничения на большие заропсы.
Или вы про thread_concurrency, ну тогда нагрузка еще больше по времени висеть будет.
Походу была проблема в версии хрома 78, вернулся обратно на глючную версию 79, но чуть по лучше, но есть зависания все равно, об этих зависания как я понял разработчикам хрома уже известно.
Вот тут созданы темы про глюки в 79 версии.
https://support.google.com/chrome/thread/23472435?hl=ru
https://support.google.com/chrome/thread/23283471?hl=en
С наступающим!
Обратите внимание на ;listen = 127.0.0.1:9000
Да, все очень быстро даже на больших логах. Плагин создает радом с логом еще один файл куда вероятно записывает время (я еще не смотрел) с котрого нужно следующий раз лог читать, поэтому сканирование идет очень быстро, почти мгновенно.
Единственное - плагин требует права на логи 655 вроде, а они по умолчанию создаются другие и он не может их читать.
Я не стал разбираться в проблеме и просто меняю права нужных логов через 5 минут после их создания по крону.
А если в мунине указать что этот график запускать от рута?
В общем всем рекомендую установить этот плагин, очень наглядно и информативно!
На скриншотах как один из сайтов сканируют поисковые боты, и еще (там где коричневые пики) те кто маскируются под поисковых ботов, но таковыми не является.
P.S. если хотите так же, нужно сперва разделить трафик на разные логи.
Я себе наделал таких графиков на каждый сайт, теперь если что сразу будет понятно какой сайт долбят.
А, нагрузка на мунин не возросла из-за этого?
мунин быстро обрабатывает задание?
Если сайт на UTF-8 то с php 7.4 у Битрикс могут (а могут и не быть) проблемы - просто на всякий случай.
сейчас php 7.2.
Кодировка сервера utf8
baas, Ну не знаю, что там за проект у вас, но 5.6-5.7 много не даст, хотя и тут могут быть подвижки. Озадачивайте начальство опять же той же служебной запиской. После того, как с сервером, естественно, разберётесь.
php7.4/mysql8 в планах.
baas, Ну Thread_concurrency - фактически прямое указание в сколько потоков работать серверу БД. Собственно, настройка топорная и рабочая ЕМНИП. А вот если вы пользуетесь такой древней версией мускула... Я вам так скажу - сваливайте на мускул 8.0 или марийку 10.3. Так, не взначай, там движок InnoDB сильно переработан и лично у меня на проектах наблюдался вау-эффект. А потом ещё параметры покрутил и чудо случилось, выигрыш производительности от переезда в моём случае составил где-то 60% (!!!).
Переезд на мускул 8 только в планах, от меня не зависит, я предложил переезд, прогер молчит, а без него я не буду искать себе геморой, вдруг вся структура базы похерится.
Пока хочу переехать с мускула 5,6 на мускул 5,7.
Тоже нужный момент. Это для того, чтоб тяжёлые процессы не мешали выполняться более лёгким. Вообще Марийка мне нравится гораздо больше. Подозреваю, что если сунуться в MySQL - там есть что-то аналогичное.
Оно депрекейтед с 5.5 если верно помню.
Еще есть, версия мускула 5,6, thread_concurrency
Хмм, не использую этот параметр thread_pool_prio_kickup_timer, надо будет почитать о нем.
Ну и берите так. MySQL только число потоков ограничить, получится как на двух старых серверах. За одно и сетевых задержек не станет.
Еще цен не знаем на это железо, тез поддержка подбирает несколько примерных вариантов.
В штатном режиме, файловый сервер нагрузка на проц 2-3 ядра, база нагрузка так же 2-3 ядра.
Но как только начинается обновления товаров для маркета, то нагрузка в базе возрастает до 8 ядер, под потолок, на файлом чуть чуть поднимается до 4 ядер.
Оптимизировать это сотовым администрирование уже некуда, только править сам скрипт и запросы в базе, раньше было еще хуже, это я еще базу по софту оптимизировал, нагрузка в штатном режиме спала с 4х ядер до 2х.
baas, Так в чем проблема? Возьмите тот сервер, на котором сейчас всё крутится под БД. Отберите половину потоков у мускула (там это можно), пусть половину грузит БД, половину - сам сайт. Начальству - служебную записку, что мол система может тормозить тогда-то тогда-то по таким-то причинам (скрипт, который прогер не хочет оптимизировать). Всё...
---------- Добавлено 26.12.2019 в 21:39 ----------
Да, ещё момент. Если блокировок таблиц нет - ну и х с нагрузкой на ядра. Даже оптимизировать ничего не надо.
напомните пожалуйста, а как отобрать потоки у мускула, помоему можно только поставить ограничения на большие заропсы.
Или вы про thread_concurrency, ну тогда нагрузка еще больше по времени висеть будет.